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).
1 Like
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
working
1 Like
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.
https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata -
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.
https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata#L167
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 
. 
1 Like
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 ps aux.
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.
2 Likes
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
MAC conflicts.
1 Like
Thanks!
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
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE=y
and, to enable it
ipq806x/patches-4.14/0067-generic-Mangle-bootloader-s-kernel-arguments.patch
(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)
3 Likes
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.
2019-03-14
Quick update:
- 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 master
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.
Accepted for merge, thanks to all that helped. Please open a new thread if you have any questions about the device running on official snapshots or future releases.
7 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.