[LEDE-DEV] Fritzbox 4040 notes
Hopefully this will save someone some time. The serial port is next to the MXIC chip. It needs a TTL to USB converter. Counting from the pin near the MXIC chip, as seen from the top, my addapter needed to be connected as follows: pin 0: Disconnected pin 1: green lead (TX or RX, dunno which) pin 2: white lead (TX or RX, dunno which) pin 3: black (ground) When updating the u-boot, I cloned the repo: g...@github.com:chunkeey/FritzBox-4040-UBOOT.git The upload-tof4040.sh seems to want the fritzbox booted into it's boot loader (not all the way into its OS). And, the -4 option to ping and ftp doesn't work on Fedora 22. Even once I removed the -4 options, the script does not work. The upload script fails, but this below worked on an Ubuntu based system: greearb@odroid-b64:~/git/FritzBox-4040-UBOOT/fritz$ ftp -n 192.168.178.1 Connected to 192.168.178.1. 220 ADAM2 FTP Server ready ftp> quote USER adam2 331 Password required for adam2 ftp> quote PASS adam2 230 User adam2 successfully logged in ftp> quote MEDIA FLSH 200 Media set to MEDIA_FLASH ftp> binary 200 Type set to BINARY ftp> passive Passive mode on. ftp> quote PASV 227 Entering Passive Mode (192,168,178,1,12,0) ftp> put uboot-fritz4040.bin mtd1 local: uboot-fritz4040.bin remote: mtd1 227 Entering Passive Mode (192,168,178,1,12,0) 150 Opening BINARY data connection 226 Transfer complete 524288 bytes sent in 1.96 secs (260.9572 kB/s) ftp> quit 221 Thank you for using the FTP service on ADAM2 Reboot the fritzbox at this point, wait a bit, and the boot loader will launch tftpd and wait for you to send it a file. Compile your OpenWRT image...select the Fritzbox in menuconfig after using this as your initial .config: https://downloads.lede-project.org/snapshots/targets/ipq40xx/generic/config.seed make -j8 # wait a while Copy the .itb image to your tftp server directory and then load it from uboot on the fritzbox: You probably need to run: setenv serverip [your-tftp-server-ip] # Tell the fritzbox to boot over tftp: (FRITZ4040) # tftpboot openwrt-ipq40xx-avm_fritzbox-4040-initramfs-fit-uImage.itb eth0 PHY0 Down Speed :10 Half duplex eth0 PHY1 Down Speed :10 Half duplex eth0 PHY2 Down Speed :10 Half duplex eth0 PHY3 up Speed :1000 Full duplex eth0 PHY4 Down Speed :10 Half duplex Using eth0 device TFTP from server 192.168.1.234; our IP address is 192.168.1.1 Filename 'openwrt-ipq40xx-avm_fritzbox-4040-initramfs-fit-uImage.itb'. Load address: 0x8500 Loading: Got ARP REPLY, set eth addr (80:ee:73:36:fd:10) # # # # ### done Bytes transferred = 4555248 (4581f0 hex) NetBootFileXferSize= 004581f0 (FRITZ4040) # bootm 0x8500 ## Booting kernel from FIT Image at 8500 ... Log into OpenWRT on the Fritzbox, and copy over the sysupgrade image: scp greearb@192.168.1.234:git/lede-acrh13-ct/bin/targets/ipq40xx /generic/openwrt-ipq40xx-avm_fritzbox-4040-squashfs-sysupgrade.bin /tmp/ And run it: sysupgrade /tmp/openwrt-ipq40xx-avm_fritzbox-4040-squashfs-sysupgrade.bin After this, it seems the system boots into uboot which then waits for TFTP transfer. If I ctrl-C that, and then type 'bootm', it seems to boot. I assume this should work automatically, but not sure how to make that happen yet. Maybe I just need to wait a long time? Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 1/7] Update to latest ath10k-ct driver, enable AHB.
On 04/13/2018 03:17 PM, Matthias Schiffer wrote:
On 04/14/2018 12:05 AM, Ben Greear wrote:
On 04/13/2018 02:59 PM, Matthias Schiffer wrote:
On 03/21/2018 06:28 PM, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear <gree...@candelatech.com>
---
The following build log was sent to me. Admittedly, building ath10k is
probably not really useful on the brcm2708 (RasPi) target, but it is
currently breaking an ALL_KMODS build for this platform unless package
build errors are ignored.
Maybe that platform has no pcie support in the kernel?
Correct, brcm2708 does not set CONFIG_PCI_SUPPORT (in OpenWrt .config).
d0f3dd5b9 ("ath10k-ct: update to latest version, enable AHB.") removed the
@PCI_SUPPORT dependency from ath10k-ct, so an ALL_KMODS build will now
attempt to build the package.
Hmm, the AHB stuff doesn't require PCI afaik, but maybe I need some
additional #ifdefs somewhere to not try building the pci logic in
ath10k-ct for platforms that don't define PCI.
I don't have time to work on that today, but will try to look at it
early next week if no one beats me to it.
Thanks,
Ben
Thanks,
Ben
Regards,
Matthias
make[5]: Entering directory
'/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/linux-4.9.91'
CC [M]
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.o
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:
In function 'ath10k_pci_hif_start':
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:1964:2:
error: implicit declaration of function 'pcie_capability_write_word'
[-Werror=implicit-function-declaration]
pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL,
^~
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:
In function 'ath10k_pci_hif_power_up':
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:2835:2:
error: implicit declaration of function 'pcie_capability_read_word'; did
you mean 'has_capability_noaudit'? [-Werror=implicit-function-declaration]
pcie_capability_read_word(ar_pci->pdev, PCI_EXP_LNKCTL,
^
has_capability_noaudit
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:
In function 'ath10k_pci_init_irq':
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3246:9:
error: implicit declaration of function 'pci_enable_msi'; did you mean
'pci_enable_sriov'? [-Werror=implicit-function-declaration]
ret = pci_enable_msi(ar_pci->pdev);
^~
pci_enable_sriov
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:
In function 'ath10k_pci_deinit_irq':
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3285:3:
error: implicit declaration of function 'pci_disable_msi'; did you mean
'pci_disable_sriov'? [-Werror=implicit-function-declaration]
pci_disable_msi(ar_pci->pdev);
^~~
pci_disable_sriov
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:
In function 'ath10k_pci_claim':
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3398:8:
error: implicit declaration of function 'pci_request_region'; did you
mean 'pci_request_regions'? [-Werror=implicit-function-declaration]
ret = pci_request_region(pdev, BAR_NUM, "ath");
^~
pci_request_regions
/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3434:2:
error: implicit declaration of function 'pci_clear_master'; did you mean
'pci_set_mas
Re: [LEDE-DEV] [PATCH v3 1/7] Update to latest ath10k-ct driver, enable AHB.
On 04/13/2018 02:59 PM, Matthias Schiffer wrote: On 03/21/2018 06:28 PM, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> The driver updates include: ath10k driver backport to fix WPA 'pn' related security bugs (4.13 based driver only currently), a fix for off-channel TX for CT wave-1 firmware, a likely fix for napi related crashes, and a backport of the firmware fetch patch. AHB is needed for the IPQ4019 platform radios. Signed-off-by: Ben Greear <gree...@candelatech.com> --- The following build log was sent to me. Admittedly, building ath10k is probably not really useful on the brcm2708 (RasPi) target, but it is currently breaking an ALL_KMODS build for this platform unless package build errors are ignored. Maybe that platform has no pcie support in the kernel? Thanks, Ben Regards, Matthias make[5]: Entering directory '/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/linux-4.9.91' CC [M] /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.o /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c: In function 'ath10k_pci_hif_start': /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:1964:2: error: implicit declaration of function 'pcie_capability_write_word' [-Werror=implicit-function-declaration] pcie_capability_write_word(ar_pci->pdev, PCI_EXP_LNKCTL, ^~ /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c: In function 'ath10k_pci_hif_power_up': /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:2835:2: error: implicit declaration of function 'pcie_capability_read_word'; did you mean 'has_capability_noaudit'? [-Werror=implicit-function-declaration] pcie_capability_read_word(ar_pci->pdev, PCI_EXP_LNKCTL, ^ has_capability_noaudit /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c: In function 'ath10k_pci_init_irq': /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3246:9: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'? [-Werror=implicit-function-declaration] ret = pci_enable_msi(ar_pci->pdev); ^~ pci_enable_sriov /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c: In function 'ath10k_pci_deinit_irq': /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3285:3: error: implicit declaration of function 'pci_disable_msi'; did you mean 'pci_disable_sriov'? [-Werror=implicit-function-declaration] pci_disable_msi(ar_pci->pdev); ^~~ pci_disable_sriov /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c: In function 'ath10k_pci_claim': /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3398:8: error: implicit declaration of function 'pci_request_region'; did you mean 'pci_request_regions'? [-Werror=implicit-function-declaration] ret = pci_request_region(pdev, BAR_NUM, "ath"); ^~ pci_request_regions /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3434:2: error: implicit declaration of function 'pci_clear_master'; did you mean 'pci_set_master'? [-Werror=implicit-function-declaration] pci_clear_master(pdev); ^~~~ pci_set_master /scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/ath10k-ct-2018-03-16-30827f7d/ath10k-4.13/pci.c:3437:2: error: implicit declaration of function 'pci_release_region'; did you mean 'pci_release_regions'? [-Werror=implicit-function-declaration] pci_release_region(pdev, BAR_NUM); ^~ pci_release_regions cc1: some warnings being treated as errors scripts/Makefile.build:293: recipe for target '/scratch/hexa/build/gluon/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_musl_eab
Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"
On 03/16/2018 04:06 AM, Koen Vandeputte wrote: On 2018-03-16 00:49, Ben Greear wrote: On 03/15/2018 04:44 PM, Rosen Penev wrote: On Sun, Mar 4, 2018 at 3:05 PM, Stefan Lippers-Hollmann <s@gmx.de> wrote: Hi On 2018-03-04, Hauke Mehrtens wrote: On 03/04/2018 06:40 PM, Rosen Penev wrote: [...] On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <ros...@gmail.com> wrote: [...] I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the ath10k wifi was just not available after some time. I am now trying the FW 10.2.4-1.0-00037, see this commit: https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd 10.2.4-1.0-00037 has been fine for me on the BT Business Hub 5 Type A for the last couple of days, however my uptimes haven't been much higher than 3-4 days each (for unrelated reasons). I tested again. It seems while 29 is more stable, I've gotten the uptime to as low as 20 hours. It seems one of my devices is wrecking the firmware. I have since updated to ath10k-ct with its corresponding firmware and currently have an uptime of 20 hours. Besides the incessant debug span in dmesg, it seems to be working well. You can get rid of that spam: See the first entry here: http://www.candelatech.com/ath10k-ug.php If you find any crashes, let me know, or open a bug on the ath10k-ct github project that I run Thanks, Ben Hi Ben, Slightly offtopic, but: Any reason why this is on by default? I also noticed this while testing IBSS capability some time ago and my 1st thought was: "Is something wrong now??" As the dmesg buffer is circular, all the debug prints start overwriting the early bootprints after some time. When another component fails, it gets difficult fetching a full bootlog containing kernel version etc due to this. It can be turned off easily, but reversing that logic also suggest it could be turned on easily should any issues be noticed :) Yeah, I think it is probably time to disable the logging by default. I'll do that some time soon. Thanks, Ben Thanks, Koen -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Revert "firmware: ath10k-firmware: update QCA988x firmware to 10.2.4-1.0-00033"
On 03/15/2018 04:44 PM, Rosen Penev wrote: On Sun, Mar 4, 2018 at 3:05 PM, Stefan Lippers-Hollmann <s@gmx.de> wrote: Hi On 2018-03-04, Hauke Mehrtens wrote: On 03/04/2018 06:40 PM, Rosen Penev wrote: [...] On Sun, Mar 4, 2018 at 9:31 AM, Rosen Penev <ros...@gmail.com> wrote: [...] I also saw problems with the 10.2.4-1.0-00033 FW on my BT HH5, the ath10k wifi was just not available after some time. I am now trying the FW 10.2.4-1.0-00037, see this commit: https://github.com/kvalo/ath10k-firmware/commit/31695fbc77f81391f579747bb8e51c50a581c3cd 10.2.4-1.0-00037 has been fine for me on the BT Business Hub 5 Type A for the last couple of days, however my uptimes haven't been much higher than 3-4 days each (for unrelated reasons). I tested again. It seems while 29 is more stable, I've gotten the uptime to as low as 20 hours. It seems one of my devices is wrecking the firmware. I have since updated to ath10k-ct with its corresponding firmware and currently have an uptime of 20 hours. Besides the incessant debug span in dmesg, it seems to be working well. You can get rid of that spam: See the first entry here: http://www.candelatech.com/ath10k-ug.php If you find any crashes, let me know, or open a bug on the ath10k-ct github project that I run Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH-v2 1/3] Update to latest ath10k-ct driver, enable AHB.
On 02/13/2018 12:03 PM, John Crispin wrote:
On 13/02/18 19:27, Ben Greear wrote:
What is the status on this?
I have some new firmware/driver changes I'd like to get upstream
as well, but this series is stuck in limbo. The first two patches
should should be useful for anyone using my ath10k-ct stuff, and the
third will at least help IPQ4019 have a better chance at running my
code, even if they cannot currently select the options w/out applying
a few patches to relax some of the REQUIRES stuff that the 4019
platforms may currently have.
Thanks,
Ben
Hi Ben,
was going to send an email, ... what happened to patch 3/3 ?
Well, it was sent to the list, if that is what you mean?
There was also some disagreement about it, and some platforms
cannot select the IPQ4019 firmware it provides because of package dependencies.
I do not know
what is a good way to resolve it, and the quick fix of just removing
the hard dependency was not welcomed. I'd prefer the patch applied,
as then users have to do only a small and simple tweak to make the firmware
usable, and it should not hurt anyone else since they can just stick with
the stock firmware.
If the 3/3 patch is just not wanted, then users that want my firmware can
manually download it to their system. The first two patches could
still be applied.
Thanks,
Ben
John
On 01/19/2018 04:27 PM, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear <gree...@candelatech.com>
---
v2: Don't remove stock 4019 firmware from 4019 platform depends.
Add ability to load ct-firmware-[52].bin before other firmware.
Add ath10k-ct driver specific firmware option for 4019.
Verified driver loads on Jalapeno board.
package/kernel/ath10k-ct/Makefile | 14 +
...ctivate-user-space-firmware-loading-again.patch | 36 --
2 files changed, 8 insertions(+), 42 deletions(-)
delete mode 100644
package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index fe094e7..83d3a05 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -9,8 +9,8 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2017-06-13
-PKG_SOURCE_VERSION:=bded1823912549017d819d1796273b3134c3de20
-PKG_MIRROR_HASH:=616174650e12a82edb6b6bd18ac186e2c6a48fdad0082df9d2011ab20940814b
+PKG_SOURCE_VERSION:=e1edd74d5f0c5291b0be72c81033e74e267929d4
+PKG_MIRROR_HASH:=945dc7110017a80c33cac20d9d2a9beda0a6a98b50178319403568098534e60a
PKG_MAINTAINER:=Ben Greear <gree...@candelatech.com>
PKG_BUILD_PARALLEL:=1
@@ -29,7 +29,7 @@ include $(INCLUDE_DIR)/package.mk
define KernelPackage/ath10k-ct
SUBMENU:=Wireless Drivers
TITLE:=ath10k-ct driver optimized for CT ath10k firmware
- DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
@PCI_SUPPORT +kmod-hwmon-core
+ DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
+@DRIVER_11W_SUPPORT +kmod-hwmon-core
FILES:=\
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_pci.ko \
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
@@ -50,9 +50,11 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
endif
CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
-# No AHB support enabled yet. Could conditionally enable it later.
-#CT_MAKEDEFS += CONFIG_ATH10K_AHB=y
-#NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
+# This AHB logic is needed for IPQ4019 radios
+CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
NOSTDINC_FLAGS += -DSTANDALONE_CT
ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
diff --git
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
b/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
deleted file mode 100644
index dc02a9d..000
---
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens <ha...@hauke-m.de>
-Date: Thu, 24 Aug 2017 23:06:41 +0200
-Subject: [PATCH] ath10k: activate user space firmware loading again
-
-In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
-warnings") the firmware loading was changed from request_firmware() to
-request_firmware_direct() to silence some warnings in case it fails.
-request_firmware_direct() directly searches in the file system only and
-does not send a h
Re: [LEDE-DEV] [PATCH-v2 1/3] Update to latest ath10k-ct driver, enable AHB.
What is the status on this?
I have some new firmware/driver changes I'd like to get upstream
as well, but this series is stuck in limbo. The first two patches
should should be useful for anyone using my ath10k-ct stuff, and the
third will at least help IPQ4019 have a better chance at running my
code, even if they cannot currently select the options w/out applying
a few patches to relax some of the REQUIRES stuff that the 4019
platforms may currently have.
Thanks,
Ben
On 01/19/2018 04:27 PM, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
The driver updates include:
ath10k driver backport to fix WPA 'pn' related security bugs
(4.13 based driver only currently),
a fix for off-channel TX for CT wave-1 firmware, a likely
fix for napi related crashes, and a backport of the firmware fetch
patch.
AHB is needed for the IPQ4019 platform radios.
Signed-off-by: Ben Greear <gree...@candelatech.com>
---
v2: Don't remove stock 4019 firmware from 4019 platform depends.
Add ability to load ct-firmware-[52].bin before other firmware.
Add ath10k-ct driver specific firmware option for 4019.
Verified driver loads on Jalapeno board.
package/kernel/ath10k-ct/Makefile | 14 +
...ctivate-user-space-firmware-loading-again.patch | 36 --
2 files changed, 8 insertions(+), 42 deletions(-)
delete mode 100644
package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index fe094e7..83d3a05 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -9,8 +9,8 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
PKG_SOURCE_DATE:=2017-06-13
-PKG_SOURCE_VERSION:=bded1823912549017d819d1796273b3134c3de20
-PKG_MIRROR_HASH:=616174650e12a82edb6b6bd18ac186e2c6a48fdad0082df9d2011ab20940814b
+PKG_SOURCE_VERSION:=e1edd74d5f0c5291b0be72c81033e74e267929d4
+PKG_MIRROR_HASH:=945dc7110017a80c33cac20d9d2a9beda0a6a98b50178319403568098534e60a
PKG_MAINTAINER:=Ben Greear <gree...@candelatech.com>
PKG_BUILD_PARALLEL:=1
@@ -29,7 +29,7 @@ include $(INCLUDE_DIR)/package.mk
define KernelPackage/ath10k-ct
SUBMENU:=Wireless Drivers
TITLE:=ath10k-ct driver optimized for CT ath10k firmware
- DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
@PCI_SUPPORT +kmod-hwmon-core
+ DEPENDS:=+kmod-mac80211 +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11AC_SUPPORT
+@DRIVER_11W_SUPPORT +kmod-hwmon-core
FILES:=\
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_pci.ko \
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
@@ -50,9 +50,11 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
endif
CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
-# No AHB support enabled yet. Could conditionally enable it later.
-#CT_MAKEDEFS += CONFIG_ATH10K_AHB=y
-#NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
+# This AHB logic is needed for IPQ4019 radios
+CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_AHB
+
NOSTDINC_FLAGS += -DSTANDALONE_CT
ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
diff --git
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
b/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
deleted file mode 100644
index dc02a9d..000
---
a/package/kernel/ath10k-ct/patches/130-ath10k-activate-user-space-firmware-loading-again.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens <ha...@hauke-m.de>
-Date: Thu, 24 Aug 2017 23:06:41 +0200
-Subject: [PATCH] ath10k: activate user space firmware loading again
-
-In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
-warnings") the firmware loading was changed from request_firmware() to
-request_firmware_direct() to silence some warnings in case it fails.
-request_firmware_direct() directly searches in the file system only and
-does not send a hotplug event to user space in case it could not find
-the firmware directly.
-In LEDE we use a user space script to extract the calibration data from
-the flash memory which gets triggered by the hotplug event. This way the
-firmware gets extracted from some vendor specific partition when the
-driver requests this firmware. This mechanism does not work any more
-after this change.
-
-Fixes: 9f5bcfe93315 ("ath10k: silence firmware file probing warnings")
-Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
-Cc: Michal Kazior <michal.kaz...@tieto.com>
-Signed-off-by: Kalle Valo <kv...@qca.qualcomm.com>
- ath10k-4.13/core.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
a/ath10k-4.13/core.c
-+++ b/ath10k-4.13/core.c
-@@ -556,7 +556,7 @@ static const struct firmware *ath10k_fet
- dir = ".&
Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.
On 01/20/2018 02:56 AM, Hauke Mehrtens wrote: On 01/20/2018 11:15 AM, Christian Lamparter wrote: On Friday, January 19, 2018 10:06:50 PM CET Ben Greear wrote: On 01/19/2018 01:03 PM, Christian Lamparter wrote: On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index 519e8c9..6690248 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x TITLE:=Custom Board endef Wait! I remember talking about this here in the RFC thread: <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html> |Hm, this would break the WIFI in the default configuration for the |FritzBox 4040 image. Currently it only has a dependency on the |ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose? Of course I'm not trying to break anything. But, I am not sure how to fix this properly. I remember writing about this too. It's in the reply. <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09626.html> |I think there's a another way to do this. But it will require to break with |the existing convention of adding the board-2.bin that comes with the |firmware repository to the ath10k-firmware-qca4019 file. | |This way, the custom board-2.bin will stay in place when you switch/update |the firmware-5.bin. | |(The board-2.bin for the reference boards can simply be packaged just like |one of the ipq-wifi board firmwares). And furhtermore, you could provide a |"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently |host on your webside. Of course, if you have a better idea let's hear it too. You could look into making virtual packages (Don't know, if that's a thing with opkg, or not. So watch out!) or go a different route. I'm sure there's plenty of ways to do it. If you come up with something, I'll be happy to test it. Does each platform need to specifically enable a firmware target instead of depending on a DEPENDS statement to make it work? From what I know, the platform (ipq806x) does not add any firmware packages to DEFAULT_PACKAGES in the target/linux/ipq806x/Makefile. It's all "per-device". (That said, you might want to talk to Sven Eckelmann too. As he has added the ath10k-firmware-qca4019 package to the OpenMesh a42's DEVICE_PACKAGES. So, if ath10k-ct is selected on a a42 it will also include the (now useless) ath10k-firmware-qca4019, right?) Is there some other way I can provide an option for two different firmware binaries? The firmware binaries (i.e. firmware-X.bin) are not the problem. It's the "board-2.bin" files that are shipped by the ath10k-firmware-qca4019/9984/.. packages. Regards, Christian Why don't you just select the default non -ct firmware in the DEVICE_PACKAGES for each board in target/linux/ipq806x/image/Makefile and remove this dependency. Then the default images generated by build bot will still contain them, but when you manually build an image or use the image builder you can replace this FW with your own -ct version. DEVICE_PACKAGES is just a default selection and not a hard dependency. Christian, how about this option? I think this is how the rest of the ath10k devices work, or no one would ever have been able to select ath10k-ct firmware to begin with? I'd like to go ahead and get my 3 patches in, and can work on splitting out the board-2.bin options later? Thanks, Ben Hauke -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH-v2 3/3] ath10k-firmware: Support CT IPQ4019 firmware.
On 01/21/2018 07:54 AM, Christian Lamparter wrote: On Saturday, January 20, 2018 1:27:04 AM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> Initial beta release of the CT IPQ4019 firmware. Features are similar to the CT 9984 firmware +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct-htt)) +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct)) $(eval $(call BuildPackage,ath10k-firmware-qca9888-ct)) --- I applied the full series on top of the r5904 (see attached diffconfig). But I ran into issues when selecting ath10k-ct and ath10k-firmware-qca4019-ct during image creation. So what's the recommended way to install these? Are you able to un-select the default firmware? In that case, there should be no issue with the board-2.bin? I expect the use case is to install exactly one of the firmware targets. If we take the board-2.bin out of the firmware install target, then users would somehow have to know to install some sort of board-2.bin or similar file, otherwise the driver still will not load. Since some boards have their own custom board-2.bin, I'm not sure how to automate this properly. But, if we just assume users will select the right thing, then splitting board-2.bin out of the FW install target should be OK I guess? Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.
On 01/20/2018 02:15 AM, Christian Lamparter wrote: On Friday, January 19, 2018 10:06:50 PM CET Ben Greear wrote: On 01/19/2018 01:03 PM, Christian Lamparter wrote: On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index 519e8c9..6690248 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x TITLE:=Custom Board endef Wait! I remember talking about this here in the RFC thread: <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html> |Hm, this would break the WIFI in the default configuration for the |FritzBox 4040 image. Currently it only has a dependency on the |ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose? Of course I'm not trying to break anything. But, I am not sure how to fix this properly. I remember writing about this too. It's in the reply. <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09626.html> |I think there's a another way to do this. But it will require to break with |the existing convention of adding the board-2.bin that comes with the |firmware repository to the ath10k-firmware-qca4019 file. | |This way, the custom board-2.bin will stay in place when you switch/update |the firmware-5.bin. | |(The board-2.bin for the reference boards can simply be packaged just like |one of the ipq-wifi board firmwares). And furhtermore, you could provide a |"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently |host on your webside. Of course, if you have a better idea let's hear it too. You could look into making virtual packages (Don't know, if that's a thing with opkg, or not. So watch out!) or go a different route. I'm sure there's plenty of ways to do it. If you come up with something, I'll be happy to test it. Does each platform need to specifically enable a firmware target instead of depending on a DEPENDS statement to make it work? From what I know, the platform (ipq806x) does not add any firmware packages to DEFAULT_PACKAGES in the target/linux/ipq806x/Makefile. It's all "per-device". (That said, you might want to talk to Sven Eckelmann too. As he has added the ath10k-firmware-qca4019 package to the OpenMesh a42's DEVICE_PACKAGES. So, if ath10k-ct is selected on a a42 it will also include the (now useless) ath10k-firmware-qca4019, right?) Is there some other way I can provide an option for two different firmware binaries? The firmware binaries (i.e. firmware-X.bin) are not the problem. It's the "board-2.bin" files that are shipped by the ath10k-firmware-qca4019/9984/.. packages. I was testing on a semi-private Jalepeno v2 tree yesterday, and I did not need the 2/4 patch to select -ct firmware. So, maybe the original issue I faced is actually not an issue any more. Or, maybe that private tree already had some hacks in it that made it work. Maybe you could test the 3 -v2 patches I posted on your 4019 device and see if you can select -ct firmware? The board.bin issue would be the same with -ct or stock 4019 firmware AFAIK, so if that is still an issue, it is a separate one. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/4] ipq: Don't force selection of the IPQ4019 firmware.
On 01/19/2018 01:03 PM, Christian Lamparter wrote: On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index 519e8c9..6690248 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x TITLE:=Custom Board endef Wait! I remember talking about this here in the RFC thread: <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html> |Hm, this would break the WIFI in the default configuration for the |FritzBox 4040 image. Currently it only has a dependency on the |ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose? Of course I'm not trying to break anything. But, I am not sure how to fix this properly. Does each platform need to specifically enable a firmware target instead of depending on a DEPENDS statement to make it work? Is there some other way I can provide an option for two different firmware binaries? Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.
I don't have the energy to try to push something like this to the upstream kernel, and little hope it would be accepted if I were to try. I think modifying LEDE is more possible, but I have not made any effort on this. My interest is mainly with the firmware and driver, and I hope that someone else can deal with the infrastructure in LEDE to load the proper board file. Thanks, Ben On 11/14/2017 04:35 PM, Matthew McClintock wrote: What ever came of this? Did something upstream or in LEDE/OpenWrt resolve what files should be loaded from where? -M On Sat, Nov 4, 2017 at 11:38 AM, Ben Greear <gree...@candelatech.com> wrote: On 11/04/2017 08:14 AM, Christian Lamparter wrote: On Friday, November 3, 2017 8:15:00 PM CET Ben Greear wrote: On 11/03/2017 05:58 PM, Christian Lamparter wrote: On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index aec8bf2..31d0fbf 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x Hm, this would break the WIFI in the default configuration for the FritzBox 4040 image. Currently it only has a dependency on the ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) Please also note that the ipq-wifi boards need to overwrite the board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages. So switching (or up-/downgrading) these wifi-firmwares will always require the (manual) reinstallation of the ipq-wifi board (if available). Maybe have the custom board.data file named slightly differently and then have an early fixup script to copy it into the proper place on first boot? And, we could hack the driver to look for a custom board-2.bin first and just install both board-x.bin images. Depends, can you convince the ath10k upstream to do that? Upstream is unlikely to accept such a patch, but I can at least patch my driver, and we can patch lede's 'upstream' driver too if we need to. We can also have a ath10k-pre-startup.sh that copies a custom board file into place when starting LEDE, with no driver modifications needed at all. I think several targets do something like this already by grabbing the board file from a flash location on the AP, for instance. And, can we have the IPQ boards select the stock 4019 firmware by default but still allow it to be de-selected so CT firmware can be selected? Or if not, then I can call my firmware something different, and have my driver look for it before the firmware-5.bin. I think there's a another way to do this. But it will require to break with the existing convention of adding the board-2.bin that comes with the firmware repository to the ath10k-firmware-qca4019 file. This way, the custom board-2.bin will stay in place when you switch/update the firmware-5.bin. That seems fine to me. Then targets could select a custom board file or a stock board file, independent of the firmware and driver. (The board-2.bin for the reference boards can simply be packaged just like one of the ipq-wifi board firmwares). And furhtermore, you could provide a "easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently host on your webside. The only board-2.bin that I (might?) have on my web site is one modified for some newer 9984 NICs from Compex. The 'ath10k-ct' firmware target just uses the default board-2.bin file from upstream. I guess someone could host/build ath10k-ct firmware ipks, but I think that might be more useful for some more standard LEDE build-farm to host since the goal is to have all of this in LEDE anyway. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.
On 11/04/2017 08:14 AM, Christian Lamparter wrote: On Friday, November 3, 2017 8:15:00 PM CET Ben Greear wrote: On 11/03/2017 05:58 PM, Christian Lamparter wrote: On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index aec8bf2..31d0fbf 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x Hm, this would break the WIFI in the default configuration for the FritzBox 4040 image. Currently it only has a dependency on the ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) Please also note that the ipq-wifi boards need to overwrite the board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages. So switching (or up-/downgrading) these wifi-firmwares will always require the (manual) reinstallation of the ipq-wifi board (if available). Maybe have the custom board.data file named slightly differently and then have an early fixup script to copy it into the proper place on first boot? And, we could hack the driver to look for a custom board-2.bin first and just install both board-x.bin images. Depends, can you convince the ath10k upstream to do that? Upstream is unlikely to accept such a patch, but I can at least patch my driver, and we can patch lede's 'upstream' driver too if we need to. We can also have a ath10k-pre-startup.sh that copies a custom board file into place when starting LEDE, with no driver modifications needed at all. I think several targets do something like this already by grabbing the board file from a flash location on the AP, for instance. And, can we have the IPQ boards select the stock 4019 firmware by default but still allow it to be de-selected so CT firmware can be selected? Or if not, then I can call my firmware something different, and have my driver look for it before the firmware-5.bin. I think there's a another way to do this. But it will require to break with the existing convention of adding the board-2.bin that comes with the firmware repository to the ath10k-firmware-qca4019 file. This way, the custom board-2.bin will stay in place when you switch/update the firmware-5.bin. That seems fine to me. Then targets could select a custom board file or a stock board file, independent of the firmware and driver. (The board-2.bin for the reference boards can simply be packaged just like one of the ipq-wifi board firmwares). And furhtermore, you could provide a "easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently host on your webside. The only board-2.bin that I (might?) have on my web site is one modified for some newer 9984 NICs from Compex. The 'ath10k-ct' firmware target just uses the default board-2.bin file from upstream. I guess someone could host/build ath10k-ct firmware ipks, but I think that might be more useful for some more standard LEDE build-farm to host since the goal is to have all of this in LEDE anyway. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 2/3] ipq: Don't force selection of the IPQ4019 firmware.
On 11/03/2017 05:58 PM, Christian Lamparter wrote: On Friday, November 3, 2017 5:05:39 PM CET gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This will allow us to select the CT IPQ4019 firmware instead if desired. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ipq-wifi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-wifi/Makefile index aec8bf2..31d0fbf 100644 --- a/package/firmware/ipq-wifi/Makefile +++ b/package/firmware/ipq-wifi/Makefile @@ -20,7 +20,7 @@ define Package/ipq-wifi-default SUBMENU:=ath10k IPQ4019 Boarddata SECTION:=firmware CATEGORY:=Firmware - DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019 + DEPENDS:=@TARGET_ipq806x Hm, this would break the WIFI in the default configuration for the FritzBox 4040 image. Currently it only has a dependency on the ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin) Please also note that the ipq-wifi boards need to overwrite the board-2.bin provided by the ath10k-firmware-qca4019(-ct) packages. So switching (or up-/downgrading) these wifi-firmwares will always require the (manual) reinstallation of the ipq-wifi board (if available). Maybe have the custom board.data file named slightly differently and then have an early fixup script to copy it into the proper place on first boot? And, we could hack the driver to look for a custom board-2.bin first and just install both board-x.bin images. And, can we have the IPQ boards select the stock 4019 firmware by default but still allow it to be de-selected so CT firmware can be selected? Or if not, then I can call my firmware something different, and have my driver look for it before the firmware-5.bin. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ath10k-ct driver: use dma_alloc_coherent, 4.13 based driver
On 10/12/2017 01:46 PM, Hauke Mehrtens wrote: I fixed this by backporting this commit from kernel 4.14: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0cc00f250e19c717fc9cdbdb7f55aaa569c7498 Thanks for testing and for the fix. I'll pull this into my 4.13 driver when I'm back from vacation...that way you can drop the external patch when I update LEDE with latest again... Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] mac80211: Add patch to re-enable setting a single rate.
On 10/12/2017 12:36 PM, Hauke Mehrtens wrote:
On 10/11/2017 12:18 AM, gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
This lets one use 'iw' to set individual rates on ath10k again.
Signed-off-by: Ben Greear <gree...@candelatech.com>
---
.../111-mac80211_allow_single_tx_rate_again.patch | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
package/kernel/mac80211/patches/111-mac80211_allow_single_tx_rate_again.patch
diff --git
a/package/kernel/mac80211/patches/111-mac80211_allow_single_tx_rate_again.patch
b/package/kernel/mac80211/patches/111-mac80211_allow_single_tx_rate_again.patch
new file mode 100644
index 000..c88ab2b
--- /dev/null
+++
b/package/kernel/mac80211/patches/111-mac80211_allow_single_tx_rate_again.patch
@@ -0,0 +1,33 @@
+From f1f0375f67622c4f5c2faeb03c0275e4f7e8191a Mon Sep 17 00:00:00 2001
+From: Ben Greear <gree...@candelatech.com>
+Date: Tue, 10 Oct 2017 13:56:29 -0700
+Subject: [PATCH] mac80211: Revert some of e8e4f5, fixes setting single rate
+ in ath10k.
+
+This lets us successfully set a single rate in ath10k again.
+
+Signed-off-by: Ben Greear <gree...@candelatech.com>
+---
+ net/mac80211/cfg.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
+index d4c2511..087d33a 100644
+--- a/net/mac80211/cfg.c
b/net/mac80211/cfg.c
+@@ -2756,8 +2756,10 @@ static int ieee80211_set_bitrate_mask(struct wiphy
*wiphy,
+ u32 basic_rates = sdata->vif.bss_conf.basic_rates;
+ enum nl80211_band band = sdata->vif.bss_conf.chandef.chan->band;
+
+- if (!(mask->control[band].legacy & basic_rates))
+- return -EINVAL;
++ if (!(mask->control[band].legacy & basic_rates)) {
++ pr_err("%s: WARNING: no legacy rates for band[%d] in
set-bitrate-mask.\n",
++ sdata->dev->name, band);
++ }
+ }
+
+ for (i = 0; i < NUM_NL80211_BANDS; i++) {
+--
+2.4.11
+
Will you also send this upstream or is this only a hack?
As written, this is a bit of a hack (probably should only pr_err once,
maybe not at all?)...I am discussing a fix for upstream.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] ath10k-ct firmware: Tx-hang and EAPOL handling fixes for wave-2 firmware.
Any feedback on this? I've been testing this off and on for a few days and it seems to work fine, so it would be nice to get it upstream... Thanks, Ben On 10/02/2017 12:57 PM, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> Changes since last LEDE release include: * Fix key-setting bug that broke sending the EAPOL 2/4 in some cases. This was a bug I introduced some time back while trying to fix .11r and simplify the key handling logic. (Patch to wpa_supplicant fixed the race with sending the 4/4 and setting the key...un-patched supplicant will still have this race and the 4-way auth will not work as reliably.) * Increase amount of active-tids that can be scheduled. This fixes a tx-stall seen with many station vdevs. * Fix bug in upstream code that would cause the maximum peer to never be scheduled for tx. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/firmware/ath10k-firmware/Makefile | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 1a23f9f..b8e1265 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -57,38 +57,38 @@ define Download/ct-firmware URL_FILE:=$($(1)_FIRMWARE_FILE_CT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community.bin-19-rc5-lede +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-19.bin.lede define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=556d6a4df50cd94a229a240d6d1d108ed5910069902f1e0cbb57b02ede27690f + HASH:=bff98f028062dae9fc638c7596aec3c79bf9eddaff65cfacba067f6d72f217cd endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community.bin-19-rc5-lede +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-19.bin.lede define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=725982694156e0b891dcd1b1b18ba5318fbbe173f4ec9603ff7acbd08f7c4050 + HASH:=95dc106f98672bd9c7d3fe6881ed79ab079cb49b0a995650991b1beaff2b0101 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.002 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.004 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4) - HASH:=e3c77077b47d55219f90816a51bf046f5b40c32be5e96bf629b083d873a879ad + HASH:=993c29fd64bb2a59b86d34f58601a1a48b83b541750bc511f78cc17152829b4d endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.002 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.004 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4) - HASH:=610f7747db6b101f4fc21431b776ac640b5977357e5be9aece2349447b9b1d85 + HASH:=d997eed9a8bc6809c01d367759ba8545c10e3be93ea1f33d6d753127ef0f7c5e endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9888_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.002 +QCA9888_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.004 define Download/ath10k-firmware-qca9888-ct $(call Download/ct-firmware,QCA9888,ath10k-9888-10-4) - HASH:=f92e7d7968698af7c6f2d76b31b3645589e03839e15838010ce457c635e5aae6 + HASH:=bbaa71bc7dcaa264c5875e86639f174908fed09fbace975e325959d42f3754ff endef $(eval $(call Download,ath10k-firmware-qca9888-ct)) -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Compile failure after pulling today: rpcd-mod-rrdns dependency
Any idea what might be causing this? Configuring kmod-i2c-algo-bit. Configuring kmod-igb. Configuring ath10k-firmware-qca6174. Configuring ppp-mod-pppoe. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci: * rpcd-mod-rrdns * * opkg_install_cmd: Cannot install package luci. package/Makefile:64: recipe for target 'package/install' failed make[2]: *** [package/install] Error 255 make[2]: Leaving directory '/home/greearb/git/lede-apu2-dev' package/Makefile:106: recipe for target '/home/greearb/git/lede-apu2-dev/staging_dir/target-x86_64_musl/stamp/.package_install' failed make[1]: *** [/home/greearb/git/lede-apu2-dev/staging_dir/target-x86_64_musl/stamp/.package_install] Error 2 make[1]: Leaving directory '/home/greearb/git/lede-apu2-dev' /home/greearb/git/lede-apu2-dev/include/toplevel.mk:207: recipe for target 'world' failed make: *** [world] Error 2 [greearb@ben-dt3 lede-apu2-dev]$ Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ath10k-ct fw 10.1, QCA988X hw, iw dev type IBSS, SET_SPECIAL_ID_ACK_CTS value > 0 => no traffic.
On 08/02/2017 02:22 PM, Nick Dennis wrote:
Radio Card and Firmware:
root@njdrlk2:/sys/kernel/debug/ieee80211/phy0/ath10k# cat firmware_info
directory: ath10k/QCA988X/hw2.0
firmware: firmware-2.bin
fwcfg: fwcfg-pci-:00:00.0.txt
bus: :00:00.0
features:
wmi-10.x,has-wmi-mgmt-tx,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT
version: 10.1-ct-8x-__fW-019-f466004
hw_rev:988x
I added the line
echo 0x3FFF > /sys/kernel/debug/ieee80211/phy0/ath10k/ct_special
towards the end of /lib/netifd/wireless/mac80211.sh for long-distance (10kM)
links.
This works fine for MAC types AP and client.
When the type is set to IBSS (for Batman mesh) on 2 devices, they each show an
association to the other in iwinfo and a neighbour in batctl n. But, neither
can ping the other, either ICMP or batctl p {mac address}.
When the line is changed to:
echo 0x > /sys/kernel/debug/ieee80211/phy0/ath10k/ct_special
and the devices rebooted, ICMP and batctl pings get responses.
Are the ID and values for this ct special OK?
Does anyone know what the ath10k clock rate for the ACK timeout counter is so
the ct special value can be calculated from a distance setting?
There were some patches posted some time back on the ath10k mailing list with a
big nasty
hack to manually set the ack timeout register. The clock rate should be
described in it.
The CT firmware just sets the register with the specified value, and makes sure
that the
value is (re)set when the NIC logic is reset, so it is up to user-space to use
the correct
value. I never actually tested that the values work at long distances, but I
did confirm
that the register was set accordingly.
I don't know why IBSS would act differently. One weird thing about IBSS is that
it cannot do AMSDU properly, so that is disabled by default, but I don't see
why that would matter
for ACK timeout logic.
If you do get it working or understand it better, I'd be happy to apply a patch
with some
notes on how to make it work at various distances (either comments or maybe a
few lines to
the ct_special debugfs read text.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ATH10K-CT debug messages
On 06/04/2017 03:40 AM, Kevin Darbyshire-Bryant wrote: FAO that nice Mr Greer, I'm getting (for free) a nice selection of ath10 debug messages when using the Ath10K-ct firmware & driver in LEDE. A small collection reproduced below. Are they of any interest/use? If you want to disable this, set the debug-mask bit 0x1000 to 1. [root@ben-ota-1 ~]# cat /debug/ieee80211/wiphy0/ath10k/debug_level Current debug level: 0xc030 To change debug level, set value adding up desired flags: PCI:0x1 WMI:0x2 HTC:0x4 HTT:0x8 MAC: 0x10 BOOT: 0x20 PCI-DUMP: 0x40 HTT-DUMP: 0x80 MGMT: 0x100 DATA: 0x200 BMI: 0x400 REGULATORY: 0x800 TESTMODE:0x1000 WMI-PRINT: 0x2000 PCI-PS: 0x4000 AHB: 0x8000 NO-FW-DBGLOG:0x1000 MAC2:0x2000 INFO-AS-DBG: 0x4000 FW: 0x8000 ALL: 0x Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ATH10K-CT debug messages
F4864400 18009600 F00F [ 1744.989008] ath10k: [0056]: 74571B00 0128FC17 80881071 08000100 F4864400 18009600 FF00 74571B00 [ 1744.998195] ath10k: [0064]: 0128FC17 80881071 08000200 F4864400 18009600 FF00 74571B00 0128FC17 [ 1745.007376] ath10k: [0072]: 80881071 0300 F4864400 18009600 74571B00 0128FC17 80881071 [ 1745.016559] ath10k: [0080]: 0400 F4864400 18009600 74571B00 0128FC17 80881071 0500 [ 1745.025747] ath10k: [0088]: F4864400 18009600 76571B00 564C0014 44804300 B0D09B00 0600 [ 1745.034935] ath10k: [0096]: 0C00 003D 7C571B00 1C4C0010 44804300 0600 C000 [ 1745.044110] ath10k: [0104]: 7C571B00 524C0014 44804300 E000 0100 0200 0842 [ 1745.052500] ath10k_pci :01:00.0: ATH10K_END [ 1779.920800] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 1779.927110] ath10k: []: 14E41B00 0128FC17 070B1071 03000601 0330 FF00 14E41B00 [ 1779.936303] ath10k: [0008]: 0128FC17 80881071 0800 A42A4400 18009600 F00F 14E41B00 0128FC17 [ 1779.945493] ath10k: [0016]: 80881071 08000100 A42A4400 18009600 FF00 14E41B00 0128FC17 80881071 [ 1779.954679] ath10k: [0024]: 08000200 A42A4400 18009600 FF00 14E41B00 0128FC17 80881071 0300 [ 1779.963855] ath10k: [0032]: A42A4400 18009600 14E41B00 0128FC17 80881071 0400 A42A4400 [ 1779.973036] ath10k: [0040]: 18009600 14E41B00 0128FC17 80881071 0500 A42A4400 18009600 [ 1779.982217] ath10k: [0048]: [ 1779.985849] ath10k_pci :01:00.0: ATH10K_END [ 1787.921357] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 1787.927655] ath10k: []: AB051C00 244C0010 44804300 0100 1000 AC051C00 0128FC17 [ 1787.936850] ath10k: [0008]: 070B1071 03000601 0330 FF00 AC051C00 0128FC17 80881071 [ 1787.946042] ath10k: [0016]: 0800 342C4400 18009600 F00F AC051C00 0128FC17 80881071 08000100 [ 1787.955226] ath10k: [0024]: 342C4400 18009600 FF00 AC051C00 0128FC17 80881071 08000200 342C4400 [ 1787.964403] ath10k: [0032]: 18009600 FF00 AC051C00 0128FC17 80881071 0300 342C4400 18009600 [ 1787.973592] ath10k: [0040]: AC051C00 0128FC17 80881071 0400 342C4400 18009600 [ 1787.982779] ath10k: [0048]: AC051C00 0128FC17 80881071 0500 342C4400 18009600 [ 1787.991170] ath10k_pci :01:00.0: ATH10K_END [ 1801.922290] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 1801.928624] ath10k: []: 3F3C1C00 244C0010 44804300 0106 0200 1000 [ 1801.936235] ath10k_pci :01:00.0: ATH10K_END [ 1921.930199] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 1921.936526] ath10k: []: 841C1E00 1D4C0410 947E4300 0200 4001 841C1E00 1D4C0410 [ 1921.945719] ath10k: [0008]: 947E4300 0200 0600 4001 [ 1921.951725] ath10k_pci :01:00.0: ATH10K_END [ 1922.930270] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 1922.936588] ath10k: []: E31F1E00 1D4C0010 747D4300 0200 4001 E41F1E00 1D4C0010 [ 1922.945782] ath10k: [0008]: 747D4300 0200 0600 4001 [ 1922.951782] ath10k_pci :01:00.0: ATH10K_END [ 2311.957658] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 2311.963975] ath10k: []: 2E352400 244C0010 247F4300 0100 0600 1000 [ 2311.971581] ath10k_pci :01:00.0: ATH10K_END [ 2505.970956] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 2505.977251] ath10k: []: C53C2700 244C0010 B47F4300 0106 0300 4000 [ 2505.984859] ath10k_pci :01:00.0: ATH10K_END [ 2521.972122] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 2521.978442] ath10k: []: 0E7C2700 1D4C0010 747D4300 0100 4001 0E7C2700 1D4C0010 [ 2521.987634] ath10k: [0008]: 747D4300 0100 0600 4001 7B7C2700 1D4C0410 947E4300 0100 [ 2521.996812] ath10k: [0016]: 4001 7C7C2700 1D4C0410 947E4300 0100 0600 4001 [ 2522.005998] ath10k_pci :01:00.0: ATH10K_END Cheers, Kevin ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ath10k ct ack timeout/coverage class
The settings should stick in the firmware, but they have to be set each time the
firmware starts (the ath10k-ct driver should do that now, I think).
I haven't tested this feature though, so let me know if you find any issues.
Thanks,
Ben
On 04/24/2017 05:17 PM, Nick Dennis wrote:
Thanks. i did see something in mail-archive (don't know what source)
https://www.mail-archive.com/search?l=ath...@lists.infradead.org=subject:%22request%5C%3A+ACK+timing+setting+required%22=newest=1
Does the debugfs setting get overwritten by the ini settings during resets and
have to be re-done ?
In the past, I just set the ack timeout register without adjusting any others
and it worked, so I'll try that first.
Nick
On 24/04/2017 4:58 PM, Ben Greear wrote:
There are some un-documented hacks using the ct_special debugfs file.
Very unlikely they are hooked into LEDE.
See this code in wmi.h:
/* CT firmware only, and only builds after June 26, 2015 */
struct wmi_pdev_set_special_cmd {
#define SET_SPECIAL_ID_ACK_CTS 0 /* set ack-cts-timeout register */
#define SET_SPECIAL_ID_SLOT1 /* set slot-duration register */
#define SET_SPECIAL_ID_SIFS2 /* set sifs-duration register */
and the set_special logic in debugfs.
Thanks,
Ben
On 04/24/2017 03:36 PM, Nick Dennis wrote:
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA 9882 radios
that work fine at a couple of hundred Meters. I recently tried a link at 1.2 Kilometers,
but only got <1Mbps throughput. Does anyone know if coverage class/ack timeout is
implemented in the ath10k-ct driver+firmware? Thanks
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ath10k ct ack timeout/coverage class
There are some un-documented hacks using the ct_special debugfs file.
Very unlikely they are hooked into LEDE.
See this code in wmi.h:
/* CT firmware only, and only builds after June 26, 2015 */
struct wmi_pdev_set_special_cmd {
#define SET_SPECIAL_ID_ACK_CTS 0 /* set ack-cts-timeout register */
#define SET_SPECIAL_ID_SLOT1 /* set slot-duration register */
#define SET_SPECIAL_ID_SIFS2 /* set sifs-duration register */
and the set_special logic in debugfs.
Thanks,
Ben
On 04/24/2017 03:36 PM, Nick Dennis wrote:
I have AP <-> Client links on the ath10k-ct driver+ firmware on QCA 9882 radios
that work fine at a couple of hundred Meters. I recently tried a link at 1.2 Kilometers,
but only got <1Mbps throughput. Does anyone know if coverage class/ack timeout is
implemented in the ath10k-ct driver+firmware? Thanks
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
On 04/24/2017 12:39 AM, Y.B. Lu wrote: Hi John, Thank you very much. But I still feel it's strange the crash didn't happen if used brctl to configure instead of /etc/config/network. Much memory(about 700MB) was consumed in UDP throughput test only when used /etc/config/network. As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe ethernet driver had this issue. I think maybe I should focus on deep studying in /etc/config/network. But we had a deadline by this month to resolve it. Is there any possibility the issue was caused by OpenWrt? Thanks again. Best regards, Yangbo Lu -Original Message- From: John Crispin [mailto:j...@phrozen.org] Sent: Monday, April 24, 2017 12:31 PM To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io Cc: Wes Li; Xiaobo Xie Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network Hi, this is most certainly a bug in the kernel. either the ethernet driver blows up under load or some other memory allocation related bug. it is very common for ethernet to kill boards under load by triggering bugs. John On 24/04/17 05:49, Y.B. Lu wrote: Hi John and Jo-Philipp, Have you ever got similar problem, or known any possible reason about this, or known anyone who probably know this? I just found much memory would be consumed if I configured board as bridge mode in /etc/config/network and did UDP throughput test. But using brctl to configure bridge mode didn't consume memory. Thank you very much. Best regards, Yangbo Lu -Original Message- From: Y.B. Lu Sent: Thursday, April 13, 2017 1:24 PM To: 'lede-dev@lists.infradead.org' Subject: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network Hi all, Recently I got below kernel panic when did UDP throughput test on NXP LS1043ARDB board. I configured the bridge mode in /etc/config/network. But if I used 'brctl' to configure the bridge mode, this issue would not happen. I also noticed almost all memory was consumed(about 700MB) when kernel crashed. Anyone have any idea about this? Thank you very much. root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page allocation failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: This looks like just a warning...did the system really panic and stop working? Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a location for utility scripts?
On 02/01/2017 08:44 PM, Rich Brown wrote: On Feb 1, 2017, at 12:25 PM, Ben Greear <gree...@candelatech.com> wrote: On 02/01/2017 09:13 AM, Rich Brown wrote: A multi-part question: 1) Does the LEDE community have any favorite scripts that might be included in the basic LEDE distribution? For example, I wrote a "getstats.sh" script (https://github.com/richb-hanover/OpenWrtScripts/blob/master/getstats.sh) that collects a consistent set of information to be included in trouble reports. I did this to avoid multiple back-and-forths with people reporting a problem, asking for this info, then that info, then still more... Would this script be useful to have as a "standard tool" in LEDE? (If the script is pre-installed, then it's simple to ask the person to include that information in a bug report.) 2) Are there other similar scripts that would make your life easier? 3) If so, where should such scripts live? I started putting some debug logic in package/utils/ct-bugcheck, but it is mostly ath10k specific at this point. Would be nice if someone wanted to improve it for more general use... I think I'm asking a somewhat different question: a) Whether the getstats.sh script would be useful (see FS #455 and #457 to see it used in bug reports) b) If so, does it make sense to bundle it into the LEDE initial file system so that it's available at the moment people have a problem (instead of asking them to find it, copy it to their LEDE system, then run it...) I think you would have to make a new LEDE package to allow users to choose your script to be included at compile time so that it is available on the FS. Or possibly, it is worth extending ct-bugcheck to have your tool in it and make ct-bugcheck a more general bug-reporting package. Thanks, Ben Thanks, Rich Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a location for utility scripts?
On 02/01/2017 09:13 AM, Rich Brown wrote: A multi-part question: 1) Does the LEDE community have any favorite scripts that might be included in the basic LEDE distribution? For example, I wrote a "getstats.sh" script (https://github.com/richb-hanover/OpenWrtScripts/blob/master/getstats.sh) that collects a consistent set of information to be included in trouble reports. I did this to avoid multiple back-and-forths with people reporting a problem, asking for this info, then that info, then still more... Would this script be useful to have as a "standard tool" in LEDE? (If the script is pre-installed, then it's simple to ask the person to include that information in a bug report.) 2) Are there other similar scripts that would make your life easier? 3) If so, where should such scripts live? I started putting some debug logic in package/utils/ct-bugcheck, but it is mostly ath10k specific at this point. Would be nice if someone wanted to improve it for more general use... Thanks, Ben Thanks. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ath10k-ct: Support ath10k CT firmware for 9887 chipsets.
My firmware does not appear to work well at all on 9887, so might as well skip this commit for now. Maybe I will find time to work on this in the future Thanks, Ben On 01/20/2017 03:20 PM, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> Signed-off-by: Ben Greear <gree...@candelatech.com> --- Build tested, but the board I was trying to test it on appears busted and does not even show an ath10k device on the bus, so not sure if this firmware actually works. package/firmware/ath10k-firmware/Makefile | 38 +++ 1 file changed, 38 insertions(+) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index fa026e4..301dcbd 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -32,6 +32,11 @@ $(Package/ath10k-firmware-default) TITLE:=ath10k firmware for QCA9887 devices endef +define Package/ath10k-firmware-qca9887-ct +$(Package/ath10k-firmware-default) + TITLE:=ath10k-CT firmware for QCA9887 devices +endef + QCA9887_REV:=3cce88e245f2d685e49411c4f80998f94baf67b8 QCA9887_FIRMWARE_FILE:=firmware-5.bin_10.2.4-1.0-00013 QCA9887_FIRMWARE_FILE_HASH:=5966408bd41f309edb595344b8dd088c0fed212debfd91e5f3e8a55ea119c16d @@ -79,6 +84,13 @@ define Download/ath10k-firmware-qca988x-ct endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community.bin-19-rc1-lede +define Download/ath10k-firmware-qca9887-ct + $(call Download/ct-firmware,QCA9887,ath10k-9887) + HASH:=622deb6996dd70b83d9a42c742254137fbc4afcc59134f60bf8f3e97aac17c6e +endef +$(eval $(call Download,ath10k-firmware-qca9887-ct)) + QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-9.bin-lede.001 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4) @@ -107,6 +119,13 @@ $(Package/ath10k-firmware-default) CATEGORY:=Firmware endef +define Package/ath10k-firmware-qca9887-ct +$(Package/ath10k-firmware-default) + TITLE:=ath10k CT 10.1 firmware for QCA9887 devices + SECTION:=firmware + CATEGORY:=Firmware +endef + define Package/ath10k-firmware-qca988x-ct/description Alternative ath10k firmware for QCA988X from Candela Technologies. Enables IBSS and other features. See: @@ -116,6 +135,14 @@ is un-selected since the driver will try to load firmware-5.bin before firmware-2.bin endef +define Package/ath10k-firmware-qca9887-ct/description +Alternative ath10k firmware for QCA9887 from Candela Technologies. +Enables IBSS and other features. See: +http://www.candelatech.com/ath10k-10.1.php +This firmware conflicts with the standard 9887 firmware, so select only +one. +endef + define Package/ath10k-firmware-qca99x0-ct/description Alternative ath10k firmware for QCA99x0 from Candela Technologies. Enables IBSS and other features. See: @@ -224,6 +251,16 @@ define Package/ath10k-firmware-qca988x/install $(1)/lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin endef +define Package/ath10k-firmware-qca9887-ct/install + $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA9887/hw1.0 + $(INSTALL_DATA) \ + $(DL_DIR)/$(call CT_FIRMWARE_FILE,QCA9887) \ + $(1)/lib/firmware/ath10k/QCA9887/hw1.0/firmware-2.bin + $(INSTALL_DATA) \ + $(DL_DIR)/$(QCA9887_BOARD_FILE_DL) \ + $(1)/lib/firmware/ath10k/QCA9887/hw1.0/board.bin +endef + define Package/ath10k-firmware-qca988x-ct/install $(INSTALL_DIR) $(1)/lib/firmware/ath10k/QCA988X/hw2.0 $(INSTALL_DATA) \ @@ -297,6 +334,7 @@ $(eval $(call BuildPackage,ath10k-firmware-qca99x0)) $(eval $(call BuildPackage,ath10k-firmware-qca6174)) $(eval $(call BuildPackage,ath10k-firmware-qca9984)) +$(eval $(call BuildPackage,ath10k-firmware-qca9887-ct)) $(eval $(call BuildPackage,ath10k-firmware-qca988x-ct)) $(eval $(call BuildPackage,ath10k-firmware-qca99x0-ct)) $(eval $(call BuildPackage,ath10k-firmware-qca9984-ct)) -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] ath10k-ct: Fix performance of 2x2 hardware running 3x3 firmware.
Please do not apply this, it has issues. I will send a v2 patch. Thanks, Ben On 01/19/2017 03:08 PM, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> The driver had a bug when calculating the rateset. This resolves that and allows full VHT mcs rates on 2x2 hardware. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/kernel/ath10k-ct/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index 3c31e11..629978e 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -8,8 +8,8 @@ PKG_LICENSE_FILES:= PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git PKG_SOURCE_PROTO:=git -PKG_SOURCE_DATE:=2017-01-10 -PKG_SOURCE_VERSION:=f5bacb83baf95e887c50c286606f4f565ef71d86 +PKG_SOURCE_DATE:=2017-01-19 +PKG_SOURCE_VERSION:=e2fb92f23623d22353042b178d6fb65644ab9ef0 PKG_MIRROR_HASH:=845950a177ed6dd7ad3f645df79403e9980f089a09b66e74a9b88abe58dfe5e6 PKG_MAINTAINER:=Ben Greear <gree...@candelatech.com> -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] QCA Dakota support
Have you tried the ath10k-ct driver? I think it should at least support the radios if you put on the right firmware. Not sure about the rest of the board. Thanks, Ben On 11/12/2016 09:42 AM, Matthew McClintock wrote: On Fri, Nov 11, 2016 at 5:03 PM, Christian Mehlis <christ...@m3hlis.de> wrote: Hi Matthew, I took your patches to my tree. They are for Linux 4.7, so I tried to make Lede build with that Linux version. I ran into some trouble with musl+netifd (fixed it). Now compat-wireless seems to expect an older Kernel: compat-wireless-2016-10-08/backport-include/linux/netdevice.h:337:5: error: 'struct net_device' has no member named 'trans_start' dev->trans_start = jiffies; The member was kicked in 4.7. In case someone is willing to help, I'm open for code. I can't help much, since QCA declined to give me a board. Did you try regenerating the compat-wireless against the newer kernel? I never did much on the wifi side, was alway doing everything else. If you compare the ChromeOS tree I shared it's a backport to 3.18, so some subset of patches in that list will backport to 4.4 pretty easily. -M ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] New CT ath10k firmware is available
I don't really have time to work specifically on LEDE much. But, if someone else takes care of the rest, then my firmware can hopefully work well on its radio. Thanks, Ben On 11/03/2016 07:48 PM, liudengf...@kunteng.org wrote: thx for your kindly reply. by the way, do u plan to support R7800, if plan, I think its a good idea. -- liudengf...@kunteng.org *From:* Ben Greear <mailto:gree...@candelatech.com> *Date:* 2016-11-04 10:39 *To:* liudengf...@kunteng.org <mailto:liudengf...@kunteng.org>; LEDE Development List <mailto:lede-dev@lists.infradead.org> *Subject:* Re: [LEDE-DEV] New CT ath10k firmware is available The 10.4 firmware supports 9984. It is one of the chips I test against. But, I am using it as a NIC in an x86-64 platform, not R7800 specifically. Thanks, Ben On 11/03/2016 07:24 PM, liudengf...@kunteng.org wrote: > Does this version support QCA9984? I have tested ct ath10k in R7800 before, but it can not run in LEDE. > > -- > liudengf...@kunteng.org > > *From:* Ben Greear <mailto:gree...@candelatech.com> > *Date:* 2016-11-04 09:12 > *To:* LEDE Development List <mailto:lede-dev@lists.infradead.org> > *Subject:* [LEDE-DEV] New CT ath10k firmware is available > For those of you using my 10.1 or 10.4 CT ath10k firmware in LEDE, I have pushed new beta > builds for all of the various images I build. > For those with capability and time, it would help me out if you could do a bit of > testing of these firmware on LEDE. If I can get some successful reports, I will > post a LEDE patch to update to these latest firmwares. > http://www.candelatech.com/ath10k.php > In particular, I have no 9887 hardware, so if someone tests that image I > am interested to know how it goes. > Thanks, > Ben > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] New CT ath10k firmware is available
For those of you using my 10.1 or 10.4 CT ath10k firmware in LEDE, I have pushed new beta builds for all of the various images I build. For those with capability and time, it would help me out if you could do a bit of testing of these firmware on LEDE. If I can get some successful reports, I will post a LEDE patch to update to these latest firmwares. http://www.candelatech.com/ath10k.php In particular, I have no 9887 hardware, so if someone tests that image I am interested to know how it goes. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] uImage too big for Netgear R7800
ory '/home/greearb/git/lede-r7800/target/linux/ipq806x' Makefile:13: recipe for target 'install' failed make[3]: *** [install] Error 2 make[3]: Leaving directory '/home/greearb/git/lede-r7800/target/linux' target/Makefile:21: recipe for target 'target/linux/install' failed make[2]: *** [target/linux/install] Error 2 make[2]: Leaving directory '/home/greearb/git/lede-r7800' target/Makefile:17: recipe for target '/home/greearb/git/lede-r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl-1.1.15_eabi/stamp/.target_install' failed make[1]: *** [/home/greearb/git/lede-r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl-1.1.15_eabi/stamp/.target_install] Error 2 make[1]: Leaving directory '/home/greearb/git/lede-r7800' /home/greearb/git/lede-r7800/include/toplevel.mk:194: recipe for target 'world' failed Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
On 10/16/2016 08:30 AM, STR . wrote: BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on ethernet cards. It also works if you have hardware flow control on the the ethernet. It can't do anything on downloads. If your connection is not at line rate or the download is overbuffered (looks like 20Mbit here), you need a soft shaper like the ones in sqm-scripts (htb + fq_codel or cake) set 5-15% below the observed rate to win. So I was misreading it. Thanks for clearing that up, this was tested on an 8M down ADSL, I'll check out the sqm-scripts. Do you know of someone making a bigger better case for it? I'd like one with 6 antenna slots for just that reason - and better heat management. This has been a gripe for everyone owning an APU2 it seems. 6 holes for antenna? I know none. You can find $30 hand punches on Amazon/Ebay and their largest punch size is typically perfect for SMA connectors. The APU2 case is easily punched since it is aluminum. https://www.amazon.com/Neiko-02612A-Multi-Purpose-Power-Punch/dp/B0002T87CW/ref=sr_1_3?ie=UTF8=1476634765=8-3=metal+punch Also, I've run these systems at full load (500Mbps+) for 24 hours and though the case gets warm, system has remained stable. A warm case actually means it is transferring heat... Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board
On 10/14/2016 10:19 AM, Chris Blake wrote: This is an RFC to port the PC Engines APU2 board to LEDE. Currently this is based on my unofficial repo at https://github.com/riptidewave93/LEDE-APU2 and after a discussion on the lede-dev IRC on the best plan of action, which was to move this device to a profile under x86_64. Things Working: - board detection - USB ports - LED/Button support - ath9k and ath10k - to support both wireless cards sold via PC Engines - SP5100 Watchdog - NCT5104D GPIO Driver Not Working: - AES-NI CPU Acceleration I have a patch that enables AES-NI for appropriate x86-64 CPUs. You are welcome to try getting it upstream and/or into LEDE: http://dmz2.candelatech.com/?p=linux-4.7.dev.y/.git;a=commit;h=abd4e4982a674ab469916f0a50e01e69b739ce71 Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ct-bugcheck: fix globbing, word splitting and change formatting
On 10/14/2016 08:58 AM, Jan-Tarek Butt wrote: Double quote to prevent globbing and word splitting. Use short syntax to enhance reading quallity. I disagree that the short syntax helps reading quality, but if others like it then I guess that change is fine with me. Thanks, Ben Signed-off-by: Jan-Tarek Butt <ta...@ring0.de> --- package/utils/ct-bugcheck/src/bugchecker.sh | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/package/utils/ct-bugcheck/src/bugchecker.sh b/package/utils/ct-bugcheck/src/bugchecker.sh index be305af..eb221db 100755 --- a/package/utils/ct-bugcheck/src/bugchecker.sh +++ b/package/utils/ct-bugcheck/src/bugchecker.sh @@ -12,18 +12,10 @@ DO_BUGCHECK=0 # DO_BUGCHECK=1 # export DO_BUGCHECK -if [ -f /etc/config/bugcheck ] -then -. /etc/config/bugcheck -fi +[ -f /etc/config/bugcheck ] && . /etc/config/bugcheck +[ "$DO_BUGCHECK" -eq "0" ] && exit 0 -if [ $DO_BUGCHECK == 0 ] -then -exit 0 -fi - -while true - do +while true; do $CHECKER sleep $SLEEPFOR done -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] kernel: remove switch driver kmod packages
On 09/01/2016 09:00 AM, Felix Fietkau wrote: On 2016-09-01 17:00, Tim Harvey wrote: Felix, In a5c32a1f1996f4f75504c4a9abd1c99eaa598df1 you removed kernel/linux/modules/dsa.mk claiming that targets needing switch drivers should select them in their kernel configs thus preventing bloat creeping into targets that don't need switchdev/dsa. Right. What that implies is that every target board of a given target arch gets bloated. For example, for the imx6 targets there are wandboard and ventana. Ventana can benefit from switchdev/dsa (if the user is using a GW16083 expansion card I might add - the switch is 'not' on the baseboards) but for Wandboard including switchdev/dsa in the kernel config is bloat. In my opinion, nobody really cares about a tiny bit of kernel bloat for the Wandboard. That device is not exactly space constrained. Is there some way that I'm not aware of to per-target kernel config or do you have any thoughts to support such a thing? Since we build all devices of a subtarget with the same kernel image, a per-device kernel config is not going to happen. Tim, you might take a look at my 'buildme' scripts. It provides a way to create custom configurations and build from them fairly easily. So far, it does not seem like something that is wanted upstream, but perhaps some day that will change. https://github.com/greearb/lede-source-ct I haven't synced up with upstream in a few days so that repo is a bit behind... Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] ath10k-ct: Remove useless WARNING for 10.4 firmware.
On 08/25/2016 02:48 AM, Felix Fietkau wrote: On 2016-08-25 02:19, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> Removes a useless splat in ath10k, and adds some safety code around setting keys in the firmware. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/kernel/ath10k-ct/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/kernel/ath10k-ct/Makefile b/package/kernel/ath10k-ct/Makefile index f0b2f5d..8e292ac 100644 --- a/package/kernel/ath10k-ct/Makefile +++ b/package/kernel/ath10k-ct/Makefile @@ -1,7 +1,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ath10k-ct -PKG_VERSION:=2016-08-11 +PKG_VERSION:=2016-08-24-1 Why did you add -1? I removed it in the commit to my staging tree. It was my second try of the day..the first one was missing a patch. Won't hurt to remove it. Thanks, Ben - Felix -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/4] bugcheck: Add tools to poll for and report certain bugs.
On 07/27/2016 10:13 PM, John Crispin wrote: On 22/07/2016 01:52, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This first release is all about checking for ath10k firmware crashes. Could be extended later for other modules/bugs/etc. the description could be a little more verbose explaining roughly what the tool does Ok. Signed-off-by: Ben Greear <gree...@candelatech.com> --- package/utils/bugcheck/Makefile | 46 package/utils/bugcheck/src/bugcheck.initd | 16 + package/utils/bugcheck/src/bugcheck.sh| 116 ++ package/utils/bugcheck/src/bugchecker.sh | 29 why not use cron instead of running a wrapper script ? I want 1-minute (or maybe even less in future) intervals, and evidently this is difficult to automatically make work with LEDE cron? Also, I was asked to rename this project to 'ct-bugcheck', which I have done, but have not yet posted a patch. And, I was asked to ensure that the tool did not run by default, which this patch accomplishes by requiring the user to edit an /etc/config/bugcheck fle. Been spending time trying to get a linksys with QCA9980 hardware to be stable under load...firmware is crapping itself currently. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Routing two interfaces on same subnet
On 07/05/2016 08:13 AM, Baptiste Clenet wrote: Thanks Ben for your answer. How to use arp-flter? Could you suggest a configuration which solve the problem? I don't have time to dig into your specific issue, but google for arp_filter and you should find some useful information. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k out-of-tree driver.
On 06/26/2016 03:52 AM, Felix Fietkau wrote: On 2016-06-22 00:00, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This lets one use the ath9k and ath10k driver instead of the built-in ath10k/ath9k driver from the upstream kernel (or backports). For ath10k, this should be a drop-in replacement, as well as enabling better CT firmware support. For ath9k, this enables some 5Mhz channel and 4.9Ghz support, but may loose some existing patches that LEDE carries for ath9k. Signed-off-by: Ben Greear <gree...@candelatech.com> I would really like to have this use kmod-ath from the main mac80211 patches in order to support using ath9k from the main package along with ath10k-ct. The packagea at least it needs a split between the ath9k and ath10k parts. That sounds good to me. I'm mostly interested in ath10k at this point...probably any ath9k changes could just be applied as patches instead of a fully external driver. I guess I need to change any 'include "../foo.h" to and then somehow fix the make command to point to the backports tree? Any suggestions on how to better sync with kernel compile options? Seems ath10k has a lot of different CONFIG* options. I hard-coded some in the make-file, but I am guessing that is fragile at best. If you have time to help with a bit of whatever is needed to get it properly linking/compiling against the proper code, I can work on making the build actually work. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k out-of-tree driver.
On 06/21/2016 03:15 PM, David Lang wrote: On Tue, 21 Jun 2016, Ben Greear wrote: On 06/21/2016 03:04 PM, David Lang wrote: I'll point out that there is a lot of work being done on these drivers right now in terms of making significant changes to how they do buffering that in increasing network speed as well as reducing latency search the follwoing lists for [make-wifi-fast] to see the details and benchmarks make-wifi-f...@lists.bufferbloat.net, ath9k-de...@venema.h4ckr.net,linux-wirel...@vger.kernel.org Yes, and I will pull that stuff into my tree as it becomes stable and/or as I have time. It seems I have little chance to ever get my ath10k patches in the upsteam kernel, so this is the best I can think of for now. It might be best to entirely decouple my ath10k from ath9k so folks can use stock (LEDE) ath9k but my ath10k. Maybe I simply had some typo in my first attempt at this. I figure Felix will know better how to make this all work, so this patch should probably wait for him to comment on and/or fix. One more thing that I didn't really see in the patch (but I may have skimmed over it) What is the difference/improvement between the stock driver and the Candela-Tech driver? (i.e. as someone configuring LEDE, why would I pick your driver?) David Lang The main reason is that it better supports CT ath10k firmware: http://www.candelatech.com/ath10k-10.1.php http://www.candelatech.com/ath10k-10.4.php See the features list down this page a bit. It is at least mostly up to date. If you are not using my firmware, then I am not sure my driver will give you much benefit over stock. Firmware (10.1) release notes here: http://www.candelatech.com/downloads/ath10k-fw-beta/release_notes.txt One of the nice features for me is that I can get much better 'core' dumps out of my firmware when using this driver, so I expect I can debug firmware crashes more thoroughly. For folks on this list, the IBSS support and capturing more frames in monitor mode might be a key benefit. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] apu2 + Candela firmware/driver LEDE tree is available.
On 06/21/2016 03:45 PM, Ben Greear wrote: In case someone wants to try out my patches by just cloning a tree: https://github.com/greearb/lede-source-ct The README has some notes on how to easily build for the 'apu2' platform, and normal build infrastructure is supported as well. I am likely to rebase this often as I have time to sync with upstream. Oh, and if someone happens to like the buildme.sh logic, I'll be happy to accept patches for other targets and/or general improvements to the buildme.sh script or other features only in this particular fork of the lede tree. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] apu2 + Candela firmware/driver LEDE tree is available.
In case someone wants to try out my patches by just cloning a tree: https://github.com/greearb/lede-source-ct The README has some notes on how to easily build for the 'apu2' platform, and normal build infrastructure is supported as well. I am likely to rebase this often as I have time to sync with upstream. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k out-of-tree driver.
On 06/21/2016 03:04 PM, David Lang wrote: I'll point out that there is a lot of work being done on these drivers right now in terms of making significant changes to how they do buffering that in increasing network speed as well as reducing latency search the follwoing lists for [make-wifi-fast] to see the details and benchmarks make-wifi-f...@lists.bufferbloat.net, ath9k-de...@venema.h4ckr.net,linux-wirel...@vger.kernel.org Yes, and I will pull that stuff into my tree as it becomes stable and/or as I have time. It seems I have little chance to ever get my ath10k patches in the upsteam kernel, so this is the best I can think of for now. It might be best to entirely decouple my ath10k from ath9k so folks can use stock (LEDE) ath9k but my ath10k. Maybe I simply had some typo in my first attempt at this. I figure Felix will know better how to make this all work, so this patch should probably wait for him to comment on and/or fix. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 06/03/2016 09:19 AM, Karl Palsson wrote: Maybe some of it, but for more generic platforms, I am not sure sub-targets make sense, and in general, it is more difficult to edit those than to change a diffconfig as far as I can tell. For who? I'm pretty sure I can use "make menuconfig" _far_ more reliably than I can edit a diffconfig file to use a "buildme" script. If I don't know anything, and _need_ to build a custom image that can't be built with image builder, or post install config, then menuconfig at least makes sure that dependencies get pulled in properly. Adding line items to file that you then "defoncfig" and hope you got perfectt seems fraught with danger, and for what? To avoid showing someone how to use menuconfig? Which they'll need to use anyway? Because I don't believe for a _second_ that somehow you're going to have "buildme" magic that automatically solves all the configs someone needs. First of all, any time you try to add a new module, someone will bitch about how it bloats their beautiful image and makes it impure. Adding more sub-targets almost cannot by definition be any less likely to rot or be un-maintained than the buildme targets I am proposing. To create (or update) the diffconfig, you can run menuconfig, twiddle as you like, and then save the new diffconfig. And commit changes (assuming you are maintaining this buildme profile). If the diffconfig profiles are really that un-cool, then maybe just add the buildme script with ability to use URL for the diffconfig profile and let folks host them elsewhere. That is less user-friendly (it would be hard to show user all available options), but at least it is still one command to build an image. And anyway, no one is proposing to remove menuconfig logic, I just want to add some wrappers to make it easier for newbies that may initially be bewildered by all of the menuconfig options (and lack of options if you haven't installed the proper feeds already). Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 06/03/2016 05:37 AM, Conor O'Gorman wrote: On 03/06/16 13:27, Ben Greear wrote: On 06/03/2016 02:17 AM, John Crispin wrote: On 01/06/2016 20:21, Ben Greear wrote: On 06/01/2016 11:07 AM, John Crispin wrote: Hi Ben, also inclined to reject this one. it will open up the pandoras box and we will end up maintaining piles of diffconfig files. it would make morse sense to document what the script does inside web.git as a "how to build" or "getting started" page I do not have much history with LEDE/WRT, but is the diffconfig output really that fragile? I will be willing to maintain the x86-64 and probably Ventana diffconfigs, and even if it totally fails, you have not lost any functionality since the main infrastructure is unchanged. for how long and will all the other people submitting these files also provide LTS ? normally activism fades after a few months. we can see this will board support and package maintenance. i think this will be a burden. Anything that makes it more easy for others to build images should help bring in more newbies faster, which might keep the activism going, especially for common platforms that will constantly be getting new hardware (like x86-64). Currently, a newbie with an x86-64 board is going to have a slow and frustrating time trying to get any sort of useful 'AP' built from LEDE. I think I can help to fix that problem if you will let me. So, how about you accept a small number of diffconfig recipes, and the buildme script, and then see how that works for a while. I can update buildme.sh to grab a diffconfig from a URL (using curl, or something) and then folks wanting to provide out-of-tree diffconfigs need only put their config in a public place and tell users how to use it: ./buildme.sh -T http://my.funkyplatform.com/board1 Thanks, Ben This seems to duplicate the functionality of the sub-targets and profiles mechanism? Maybe some of it, but for more generic platforms, I am not sure sub-targets make sense, and in general, it is more difficult to edit those than to change a diffconfig as far as I can tell. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 06/03/2016 02:17 AM, John Crispin wrote: On 01/06/2016 20:21, Ben Greear wrote: On 06/01/2016 11:07 AM, John Crispin wrote: Hi Ben, also inclined to reject this one. it will open up the pandoras box and we will end up maintaining piles of diffconfig files. it would make morse sense to document what the script does inside web.git as a "how to build" or "getting started" page I do not have much history with LEDE/WRT, but is the diffconfig output really that fragile? I will be willing to maintain the x86-64 and probably Ventana diffconfigs, and even if it totally fails, you have not lost any functionality since the main infrastructure is unchanged. for how long and will all the other people submitting these files also provide LTS ? normally activism fades after a few months. we can see this will board support and package maintenance. i think this will be a burden. Anything that makes it more easy for others to build images should help bring in more newbies faster, which might keep the activism going, especially for common platforms that will constantly be getting new hardware (like x86-64). Currently, a newbie with an x86-64 board is going to have a slow and frustrating time trying to get any sort of useful 'AP' built from LEDE. I think I can help to fix that problem if you will let me. So, how about you accept a small number of diffconfig recipes, and the buildme script, and then see how that works for a while. I can update buildme.sh to grab a diffconfig from a URL (using curl, or something) and then folks wanting to provide out-of-tree diffconfigs need only put their config in a public place and tell users how to use it: ./buildme.sh -T http://my.funkyplatform.com/board1 Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 06/01/2016 11:07 AM, John Crispin wrote: Hi Ben, also inclined to reject this one. it will open up the pandoras box and we will end up maintaining piles of diffconfig files. it would make morse sense to document what the script does inside web.git as a "how to build" or "getting started" page I do not have much history with LEDE/WRT, but is the diffconfig output really that fragile? I will be willing to maintain the x86-64 and probably Ventana diffconfigs, and even if it totally fails, you have not lost any functionality since the main infrastructure is unchanged. I think I could further improve the buildme.sh to automatically pull in the feeds based on the packages in the diffconfig too, which should further automate building and make the buildme.sh more generic for different platforms. For jow's idea, putting it in a web page may be better than nothing, but then it just means anyone wanting to use this type of thing has more work to do, and for newbies, that can be all the difference between success and failure. I still think you should consider letting this patch in. I can re-do it based on removing the 1/2 patch, so the diffconfig gets bigger, but we can still build usable apu2 images out of the box. Either way, thanks for considering the patch. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64 target.
On 05/26/2016 07:05 PM, Daniel Curran-Dickinson wrote: Hi, On Thu, 2016-05-26 at 16:57 -0700, gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> This should make x86-64 targets more useable out of the box. The assumption is that most x86-64 users have adequate storage, and those that do not can still config away the options they do not need. Although I agree x86-64 is normally big, I'm not sure that it makes sense to make the default install so different from other devices. One thing you might want to look is that patch series I've got as URFC's for doing things like preferring full vs. busybox and see if you could implement this as something that could be added via a single package install (or from imagebuilder baked into the image by specifying a single package). I'm not sure that making big/extra/different stuff part of snapshot and release images is a good idea (although including more drivers is different IMO, because that is about hardware support out of the box, rather than about different choices about what's in the OS (unlike full bzip2, getopt, different busybox options, etc)). I think the user should consciously decide they're looking for something other than a standard LEDE system. So maybe getopt is not needed, but here is my reasoning for some of the others: tcpdump: Grab pkt captures, especially in monitor mode for debugging. Pkt capture is pretty much required for debugging tricky things, especially with something like ath10k that has thick firmware. ethtool: Low level stats, firmware version, etc. Automated bug reporting. lspci: Automated bug reporting, figure out what driver is missing from random hardware. curl: Download scripts and other things from the web, including in automated fashion. iw: Automated bug reporting, manual debugging. iperf3: Easy way to do performance testing. Could be part of automated performance testing. I think if space allows, these should be added to all or most images, but I wanted to start with a platform that I use and can test, and which has no space constraints in most cases. So, this more full image could start being more the 'standard LEDE' system. I can do this all with the buildme logic in my 2/2 patch too, so maybe that is the way to go. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 05/28/2016 05:02 AM, Bastian Bittorf wrote: * David Lang <da...@lang.hm> [28.05.2016 13:48]: rather than making a bunch of scripts for specific models, how about some scripts that will let you build from a downloaded .config (yes, you can do this manually, but it could be greatly simplified) but for this, you cont need a script at all. its just: cp $download_config .config make defconfig make is'n it? You also need to install feeds as far as I understand. Having full .configs are likely to rot faster than just diff-configs, so that is why I like just storing the diffconfigs. And, having them local and tracked in git and such just makes everything easier. With regards to feeds, the feeds to use might can be automatically determined by the diffconfig file, or maybe just another meta-data file in the buildme dir. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 05/27/2016 11:10 PM, David Lang wrote: On Fri, 27 May 2016, Ben Greear wrote: On 05/27/2016 02:46 AM, Karl Palsson wrote: gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> The idea is to be able to allow newbies to easily build images for common hardware. These images should be user-friendly, including luci and other tools that may aid debugging and use of the platform. Signed-off-by: Ben Greear <gree...@candelatech.com> --- buildme.sh| 76 +++ buildme_targets/x86_64/diffconfig.txt | 26 2 files changed, 102 insertions(+) create mode 100755 buildme.sh create mode 100644 buildme_targets/x86_64/diffconfig.txt While I've written similar scripts for helping colleagues bootstrap a build, I'm not entirely convinced that adding more piles of shell script to the build tree is necessarily an improvement, if the goal is helping people build an image that suits them. My goal is more to have an easy way to build a useful image that should work for most people. Lots of people and organizations have their own forks and scripts, and it seems much of the changes are just tweaks how to the core project is built. If we can bring some of this into the main tree maybe that will help everyone work closer to upstream code. rather than making a bunch of scripts for specific models, how about some scripts that will let you build from a downloaded .config (yes, you can do this manually, but it could be greatly simplified) Then people can build the latest code from a much larger set of configs, and tweak a config and then use it over time to build newer versions. My idea was to store these configs in the git repo and have an easy way for users to find and use them. The x86_64 is just a starting point. I think there could be a large amount of different configs, for different boards, different needs, etc. Basically, everyone using openwrt has a unique config...I think a lot of that could be re-used and shared. Thanks, Ben David Lang -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 1/2] Add some common packages for x86-64 target.
On 05/26/2016 11:33 PM, Bastian Bittorf wrote: * gree...@candelatech.com <gree...@candelatech.com> [27.05.2016 08:12]: From: Ben Greear <gree...@candelatech.com> This should make x86-64 targets more useable out of the box. The assumption is that most x86-64 users have adequate storage, please dont. I understand your issues, but better define another profile like e.g. "bloated" (please search for a better name). this is the var "DEVICE_TYPE" - see 'git grep DEVICE_TYPE'. I can just bake everything into the 2/2 'buildme.sh' logic with a bigger diffconfig result file if there is no desire to tweak the core packages for this platform. Truth is, I couldn't get 'igb' be selected with this patch anyway, so the 2/2 logic is still needed anyway. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
On 05/27/2016 02:46 AM, Karl Palsson wrote: gree...@candelatech.com wrote: From: Ben Greear <gree...@candelatech.com> The idea is to be able to allow newbies to easily build images for common hardware. These images should be user-friendly, including luci and other tools that may aid debugging and use of the platform. Signed-off-by: Ben Greear <gree...@candelatech.com> --- buildme.sh| 76 +++ buildme_targets/x86_64/diffconfig.txt | 26 2 files changed, 102 insertions(+) create mode 100755 buildme.sh create mode 100644 buildme_targets/x86_64/diffconfig.txt While I've written similar scripts for helping colleagues bootstrap a build, I'm not entirely convinced that adding more piles of shell script to the build tree is necessarily an improvement, if the goal is helping people build an image that suits them. My goal is more to have an easy way to build a useful image that should work for most people. Lots of people and organizations have their own forks and scripts, and it seems much of the changes are just tweaks how to the core project is built. If we can bring some of this into the main tree maybe that will help everyone work closer to upstream code. Extending the README would help, but I don't think a beginner should have to go through menuconfig at all. It can be overwhelming even for those of us who have seen similar things before. (Try to select 'igb' as 'y' for instance, it takes manually enabling multiple obscure other features before it will even work). lede, like openwrt before it, still has large piles of undocumented usage methods, only uncovered by digging through script after script. Adding more scripts to hide the complexity/flexibility/power of some of those other scripts doesn't seem like a net gain. A well commented buildme.sh would be a good place to start understanding the build process. At least for me, just finding the other scripts is often the hardest part...so if buildme.sh is adding a package with a feeds cmd, then that is a very useful piece of knowledge. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Need help with apu2 system
I'm trying to install LEDE on an apu2 system. My first attempt is not working: I see grub menu, then it hangs as soon as it tries to boot. If someone has a working .config and/or other hints on how to go about this, I'd appreciate some pointers. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A request not making IRC necessary to be part of the action
On 05/16/2016 03:42 PM, Aaron Z wrote: On Mon, May 16, 2016 at 5:21 PM, Ben Greear <gree...@candelatech.com> wrote: Maybe get an IRC bot to dump irc logs to the mailing list every few hours? Might be a bit spammy though IMO, trying to follow IRC when its not realtime (ie: reading a log) makes it somewhat difficult to follow threads of conversations (which email does quite well) and it can be confusing unless there is some way to put a "this post goes in this thread" for each post (and at that point, you might as well use email). Yes, I like email too. But IRC has its uses, and maybe better to have it spammed to the mailing list that just plain lost/ignored. Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A request not making IRC necessary to be part of the action
Maybe get an IRC bot to dump irc logs to the mailing list every few hours? Might be a bit spammy though Ben On 05/16/2016 12:08 PM, Dave Taht wrote: znc and bitlbee are godsends when using irc asynchronously. In particular I feed all irc convos into bitlbee and then into erc on emacs (so I am not hurt when my connection goes away). On Mon, May 16, 2016 at 5:00 AM, David Woodhouse <dw...@infradead.org> wrote: On Mon, 2016-05-16 at 12:46 +0100, Bruno Randolf wrote: On 15/05/16 05:53, Daniel Dickinson wrote: I'd really appreciate if we could actually use the mailing list for the main communications venue rather than shutting out people not in the European timezones, which is what happens if IRC is the main way to participate in the community. I have been told that to really be part of the OpenWrt action I should have been on IRC; but I'm not in European timezone so that is not actually a useful suggestion, since most of the most people most relevant to decision-making are in Europe, and I would hope LEDE has a more *inter-continental focus than OpenWrt had. Agreed! I don't have time to hang out in IRC channels, usually. Or maybe a different working style... (it distracts me too much). Anyhow I think all important things and all things which don't need real-time interaction should go thru the mailing list, please. FWIW, IRC doesn't have to have real-time behaviour, and doesn't have to be constantly distracting. It's perfectly possible to have IRC conversations with people who are never awake at the same time as you. You say something, they respond when they wake up... and you respond when *you* wake up. Just like email, in fact. IRC gives you the *option* of real-time conversation, if you happen to be awake at the same time. And you don't have to pay attention to the channel all the time; an IRC client should highlight if your nick is mentioned because someone is talking you to specifically. IRC is great for conversations which are more ephemeral, and don't need to be archived for posterity. -- dwmw2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Cannot compile latest code.
I did a pull, ./scripts/feeds update, make clean, and make V=s -j 1, and it blows up as below: find /home/greearb/git/lede/build_dir/target-arm_cortex-a9+neon_musl-1.1.14_eabi/util-linux-2.28/ipkg-arm_cortex-a9_neon/dmesg -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf Package dmesg is missing dependencies for the following libraries: libtinfow.so.5 Makefile:660: recipe for target '/home/greearb/git/lede/bin/packages/arm_cortex-a9_neon/base/dmesg_2.28-1_arm_cortex-a9_neon.ipk' failed make[3]: *** [/home/greearb/git/lede/bin/packages/arm_cortex-a9_neon/base/dmesg_2.28-1_arm_cortex-a9_neon.ipk] Error 1 make[3]: Leaving directory '/home/greearb/git/lede/package/utils/util-linux' package/Makefile:187: recipe for target 'package/utils/util-linux/compile' failed make[2]: *** [package/utils/util-linux/compile] Error 2 make[2]: Leaving directory '/home/greearb/git/lede' package/Makefile:184: recipe for target '/home/greearb/git/lede/staging_dir/target-arm_cortex-a9+neon_musl-1.1.14_eabi/stamp/.package_compile' failed make[1]: *** [/home/greearb/git/lede/staging_dir/target-arm_cortex-a9+neon_musl-1.1.14_eabi/stamp/.package_compile] Error 2 make[1]: Leaving directory '/home/greearb/git/lede' Do I need to do some other build steps, or is the tree just broken currently? Thanks, Ben -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Script to gather system info for bug reports and similar.
Here is an initial pass at a script to gather pertinent info about a LEDE (or similar) system. Suggestions for improvement are welcome. If someone could add a way to put the git commit ID(s) into the file system somewhere, I think that would be an excellent addition. And once the script is in place, a way to call it through the web UI would be most welcome. [root@ben-dt3 linux-wt.x64]# cat ~/verinfo.sh #!/bin/sh echo "System Information" uname -a echo echo "lspci:" lspci echo echo "CPU Info" cat /proc/cpuinfo echo echo "Banner:" cat /etc/banner echo echo "Network Devices:" ip addr show echo echo "Routing information:" ip route show echo echo "Qdisc information:" tc qdisc show echo echo "WiFi Information" if [ -f /sys/class/net/wlan0/address ] then iw dev wlan0 info fi if [ -f /sys/class/net/wlan1/address ] then iw dev wlan1 info fi echo echo "dmesg output" dmesg -- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
