Keep in mind that
package/firmware/ipq-wifi is only a stop-gap method until the necessary board data files are accepted into the official linux-firmware tree (which means someone needs to submit the correct files).
Keep in mind that
Good to know -- I'll dig up that link in the source. Hopefully that means that "upstream" will handle detection of the proper variant from its options.
NAND up and running now, and at least some of the USB
Bus 002 Device 002: ID 0781:5580 SanDisk Corp. SDCZ80 Flash Drive
root@OpenWrt:~# mount -t ext4 /dev/sda1 /mnt
Is the chip not detected? Or is it just missing the partitions (in the DTS)?
(There is more than one way, the u-boot can pass a partition table to linux. Either via cmdline/bootargs , through editing the fdt before passing it on or through other means (i.e. leaving a table at a fixed address). It's also possible that linux detects the layout itself though, I don't remember if the qcom smem part was ever fully upstreamed or not)
But in any case: I recommend having a partition table (fixed-partition) in the the dts.
There are two steps you need to do in order get the wifis to be detected and working properly. However, you'll need to have access to the nand first. Since the crucial pre-cal data is located in the ART/wifi-cal/Factory/etc. partition.
extract the pre-cal from the ART partition
Based on the info, the EA8300 could be similiar to the OpenMesh A62 in case of offsets and sizes.
Prepare the board data files.
So far ipq-wifi is only providing a place for QCA4019. You would need to either add a new package, or extend the package so it can deal with QCA9888. That said, ath79's decided to simply put the pre-cal into the board-data file.
So far, this seems to be working. But no idea if it also will in the future, but it's fine for a stop-gap measure.
If you are located in the US go for FCC. If you are in the UK, Ireland, etc. go for EU. Canada is IC.
So, your board's DTS was based on the DK07, but the wifi requests the DK04 name .
View into what I've been up to is available at https://github.com/jeffsf/openwrt-ea8300
See the README.md (rendered on that link) for current status.
In short, I've got the main subsystems recognized and seemingly able to communicate with them. Several "small" issues to resolve, as well as getting the wireless to actually run and the switch to configure (there is connectivity for SSH, at least through LAN port 1).
The extract-and-write approach from @chunkeey's post above seems to be a good way to go, especially as the two IPQ4019 radios need different config files. The timing of execution of
target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata seems to be a little late as the files aren't present on first boot when the drivers look for them, but are later on. I've been booting initramfs images from U-Boot, so I don't have a persistent file system. Copying them from the running system and into
./files/lib/firmware/ath10k/ and incorporating them into a build is one way around this for now. Yes, the DK04 naming is "amusing", but that's what's in the OEM firmware image!
Getting the switch to configure (it answers meaningfully to
swconfig dev switch0 show) and getting the wireless to actually come up are on the top of my list. On the wireless, I see three
hostapd processes, but the
/bin/sh ./mac80211.sh mac80211 setup ... processes take long enough that they're easy to see in the output of
Edit: Logs showing some problems with
wifi enabling the wireless devices, as if restarting them has the interface hang
logread | fgrep wlan0
root@OpenWrt:~# logread | fgrep wlan0 Wed Feb 13 00:13:06 2019 kern.info kernel: [ 4883.567718] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4885.684314] br-lan: port 4(wlan0) entered blocking state Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4885.688256] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4885.694075] device wlan0 entered promiscuous mode Wed Feb 13 00:13:08 2019 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->HT_SCAN Wed Feb 13 00:13:08 2019 daemon.err hostapd: Using interface wlan0 with hwaddr 12:34:56:78:90:12 and ssid "OpenWrt" Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4886.472115] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4886.472419] br-lan: port 4(wlan0) entered blocking state Wed Feb 13 00:13:08 2019 kern.info kernel: [ 4886.477572] br-lan: port 4(wlan0) entered forwarding state Wed Feb 13 00:13:08 2019 daemon.notice hostapd: wlan0: interface state HT_SCAN->ENABLED Wed Feb 13 00:13:08 2019 daemon.notice hostapd: wlan0: AP-ENABLED Wed Feb 13 00:13:19 2019 daemon.notice hostapd: wlan0: interface state ENABLED->DISABLED Wed Feb 13 00:13:20 2019 daemon.notice hostapd: wlan0: AP-DISABLED Wed Feb 13 00:13:20 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING Wed Feb 13 00:13:20 2019 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0 Wed Feb 13 00:13:20 2019 kern.info kernel: [ 4898.246628] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:13:20 2019 kern.info kernel: [ 4898.391946] device wlan0 left promiscuous mode Wed Feb 13 00:13:20 2019 kern.info kernel: [ 4898.393241] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:13:21 2019 daemon.err hostapd: Could not read interface wlan0 flags: No such device Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.430054] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.455464] br-lan: port 4(wlan0) entered blocking state Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.459801] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.465612] device wlan0 entered promiscuous mode Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.470637] br-lan: port 4(wlan0) entered blocking state Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.475077] br-lan: port 4(wlan0) entered forwarding state Wed Feb 13 00:13:25 2019 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->HT_SCAN Wed Feb 13 00:13:25 2019 kern.info kernel: [ 4903.481595] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:13:26 2019 daemon.err hostapd: Using interface wlan0 with hwaddr 12:34:56:78:90:12 and ssid "OpenWrt" Wed Feb 13 00:13:26 2019 kern.info kernel: [ 4904.247869] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Wed Feb 13 00:13:26 2019 kern.info kernel: [ 4904.249802] br-lan: port 4(wlan0) entered blocking state Wed Feb 13 00:13:26 2019 kern.info kernel: [ 4904.253467] br-lan: port 4(wlan0) entered forwarding state Wed Feb 13 00:13:26 2019 daemon.notice hostapd: wlan0: interface state HT_SCAN->ENABLED Wed Feb 13 00:13:26 2019 daemon.notice hostapd: wlan0: AP-ENABLED Wed Feb 13 00:13:26 2019 daemon.notice netifd: Network device 'wlan0' link is up Wed Feb 13 00:14:10 2019 kern.warn kernel: [ 4947.670425] wlan0: Failed check-sdata-in-driver check, flags: 0x9 Wed Feb 13 00:14:10 2019 kern.warn kernel: [ 4947.983983] wlan0: Failed check-sdata-in-driver check, flags: 0x9 Wed Feb 13 00:14:10 2019 kern.warn kernel: [ 4948.283290] wlan0: Failed check-sdata-in-driver check, flags: 0x9 Wed Feb 13 00:14:11 2019 kern.warn kernel: [ 4948.621573] wlan0: Failed check-sdata-in-driver check, flags: 0x9 Wed Feb 13 00:14:14 2019 kern.warn kernel: [ 4952.340465] wlan0: Failed check-sdata-in-driver check, flags: 0x9 Wed Feb 13 00:14:15 2019 kern.info kernel: [ 4952.860974] br-lan: port 4(wlan0) entered disabled state Wed Feb 13 00:14:15 2019 daemon.notice netifd: Network device 'wlan0' link is down Wed Feb 13 00:14:15 2019 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Note: The second 5 GHz radio, QCA9888 on PCI 0000:01:00.0, is limited to ch. 100 (5.5 GHz) and above by the ART data and the data in the OEM firmware's cal data. This is perhaps due to RF design optimization and/or interoperation with 2.4 GHz, such as the two, shared antennas.
There's some funkiness with
wan_mac=$(mtd_get_mac_ascii devinfo hw_mac_addr) as/when called in
target/linux/ipq40xx/base-files/etc/board.d/02_network that the code fails to extract the proper MAC address during the boot sequence, but the same commands extract it when run from the command line. As a result, at least right now, only eth1 and wlan1 get a "real" MAC, the others get assigned the default 12:34:56:78:90:12.
Oh ok, this is a problem in the mac80211 stack. @hauke is working on a update (see his staging) maybe this fixes it?
Isn't the EA8300 sold as a "Triband" router? Because I think that's the reason why they decided to do it this way.
I remember Sven Eckelmann having a similar issue with the OpenMesh A62. Though, in his case the device listed the channels as supported, but the signal was very weak. If you are in this situation as well, you can find a solution in the A62 DTS there: Use the ieee80211-freq-limit property on the DTS node of your QCA9888 to limit the channels the device can use:
ieee80211-freq-limit = <5500000 5875000>;
(it's also possible to limit the qca4019 in the same way).
Ideally, the "fixup" mac code should be done by the preinit scripts:
This has the advantage that the MAC doesn't get recorded in the config files, which allows users with multiple devices to copy the configurations from one device to another without having to worry about
Much cleaner to do the MAC addresses in the preinit script!
Found a derp in the EA6350v3 code that I was leveraging for MAC assignment, reported there. I'd like to be "clean" about the wlan devices as well, so will dig into the
netifd creation of the interfaces later on. Right now I'm "cheating" by putting the MACs into my pre-installed
/etc/config/wireless so I can continue debugging the QCA9888 operation.
I'll probably look at moving ART extraction into preinit as well, as it seems to be "too late" in hotplug.d (where it was for ipq40xx), and really only needs to be done once per flash/reset of OpenWrt.
The ART declines the use of the lower channels. I'm not complaining at all about the frequency restriction, just pointing it out early on so that anyone trying this with the default channel of 36 doesn't wonder why the AP isn't coming up. Good to know about the DTS property -- a good "safety" even if the ART / board file rejects it.
I'll definitely look into hauke's staging tree -- I've got all three radios up, but the QCA9888 will take an initial configuration (and I can see/probe the AP with another device running
iw dev wlanN-M scan), then seems to loose communication with the driver.
Moving slowly with some "challenges" with the wireless, the QCA9888 in particular.
After much head scratching, just booted off a tftp-flashed image in NAND, thanks to
In this specific case, the first magic incantation was
set bootargs ubi.mtd=rootfs root=/dev/ubiblock0_0 nand read $loadaddr $prikern $kernsize && bootm $loadaddr
I've still got to look at how to deal with the dual-firmware, and have dug up
and, to enable it
(which isn't yet on the ipq40xx platform)
set bootargs ubi.mtd=11 root=/dev/ubiblock0_0
works as well, so that looks like a path forward.
This will should let me more quickly collect diagnostic information across more combinations that hopefully either reveals that I've made a mistake in my DTS, or get more assistance from the ath10k experts.
sysupgrade isn't working yet, but hey, I'll take this accomplishment for the day!
# # OpenWrt-2019-02-20_1653-0800-ipq40xx-generic # === WARNING! ===================================== There is no root password defined on this device! Use the "passwd" command to set up a new password in order to prevent unauthorized SSH logins. -------------------------------------------------- root@OpenWrt:/# mount /dev/root on /rom type squashfs (ro,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,noatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime) /dev/ubi0_1 on /overlay type ubifs (rw,noatime,ubi=0,vol=1) overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000) debugfs on /sys/kernel/debug type debugfs (rw,noatime)
Catching up, the long list of TODOs has gotten quite a bit shorter. Quick summary, with the warning that there are some caveats to this list
- Boots from NAND
- sysupgrade works
- Wireless is up and running
- Factory images can be flashed through OEM GUI
Lots of little details in there, but things are moving along (more details on the README.md in my GitHub repo)
The bigger gaps ahead to resolve include:
- Overriding OEM bootargs (for serial-less install and easier revert to OEM)
- Switch configuration -- operational, but not "taking" different config (Similar reported on EA6305v3)
- Need to (select and) package IPQ4019 board files and perhaps QCA9888 board file
firstbootisn't erasing the overlay
sysupgradedoesn't seem to want to switch from mtd11 to mtd13 the first time, but does the second, or some such silliness
Dealing with the bootargs is the most annoying right now.
The approach used in
0067-generic-Mangle-bootloader-s-kernel-arguments.patch doesn't seem to help as it doesn't seem that ATAGs are being passed, just the FDT. That this is done before the kernel is running in any meaningful way (still in assembly-code sections) makes it hard to debug. (
head.S branches to the entry point of
arch/arm/boot/compressed/atags_to_fdt.c) I've poked into early
init and may need to do it there.
If someone reading this knows how to assemble two IPQ4019 board files (from OEM firmware, of which there are AH, EU, IC, and FCC pairs) into
board-2.bin format, a PM would be appreciated. I've found the Swiss army knife, but haven't figured out which of the tools, if any, can perform that task.
Thanks perhaps to the patches on
master, the QCA9888 seems tamed. It looks like something between February 28th and March 1st resolved it; probably Felix's related to race conditions and resetting. I'm crossing my fingers that it didn't just fix itself because I posted the issue with upstream! Thanks to Ben for looking into things as well. The best and worst kind of issues -- they resolve themselves, yet you have no idea why. At least after spending so much time testing and documenting, it seems fixed one way or another.
- On Linux 4.19 using a handful of cherry-pick commits from @chunkeey's staging tree
- Now using DSA for the switch, so VLANs are "sensible" -- though
bridgeis required and there is no UCI integration
- Images will now boot without U-Boot environment modifications; install from OEM web interface without serial required.
Getting into the first moments of when Linux starts up to accomplish that last one was pretty ugly. Yes, you should start worrying when the comment begins
/* * OK... Let's do some funky business here.
Quite a journey, especially as there isn't anything even close to a console or message buffer when you're in
head.S assembly code, long before
init takes over.
The main remaining "wonkiness" is around
boot_part and U-Boot wanting to rewrite the environment for no good reason I can tell (checksum is good). At least now with OEM bootargs in U-Boot I've got a better test platform for this.
Still need to combine the two board.bin files for 2.4 and 5 GHz on the IPQ4019's radios into a board-2.bin form, and decide which of the pairs makes sense to submit upstream.
At least one of these commits or a variant appear to be in
master at this time.
jeff@deb-devel:~/devel/openwrt-ea8300$ git log --pretty=oneline --abbrev-commit master-cp ^master 1db1612bbc (master-cp) ipq40xx: include ipq40xx-ized qca8k version 2db429cf34 ipq40xx: fix NPE related to bogus use of fixed phy 505cfcfb1c ipq40xx: extend DT mdio node to be more accessible abf050221c ipq40xx: add ipqess ethernet driver 2d6352f8b1 ipq40xx: add resets for individual MAC1-5 and PSGMII fce445b243 ipq40xx: decouple mdio-ipq40xx and ar40xx 99e74d2e90 phytool: add phytool utility c83b9fec9e ipq40xx: fix phy interrupt setting
Commit c83b9fec9e appears to have the same "title" as commit 784f2e73df on
2019-04-10 -- Pull Request On 4.14 Submitted
After poking at DSA under Linux 4.19 for quite a while, I decided that it is still too "experimental" to wait for.
Thanks to all that have provided both technical and non-technical support, here, on the mailing list, and on IRC.