Seems similar to the one I just finished porting (EA6350v3)
Am happy to port onto openwrt directly if someone can help with providing hardware.
Don't forget to provide the board.bin (you will need to extract this from the stock firmware) and add an override in package/firmware/ipq-wifi and build the image with ipq-wifi in the device_packages section.
very interested as well!
How’s the progress?
I can not wait. I am waiting very much.
Any news on that?
LOL @chunkeey -- Rick Rolled me on that one!
Yes, I'm working on this as time permits with one on the bench here. GPL sources in hand, as well as /proc/device-tree/, full file system contents, and sysinfo.cgi. I'll be leveraging some of the great work done by several members, partially described in this thread, as well as at Add support for Linksys EA6350 v3
Has anyone gotten an image built off https://github.com/Bunkerschild/openwrt to boot?
I've been trying with tftp and not getting past "Starting kernel ..."
Suggestions (other than "the kernel doesn't boot") are welcome
lrwxrwxrwx 1 root root 55 Feb 9 09:06 C0A80101.img -> openwrt-ipq40xx-linksys_ea8300-initramfs-fit-uImage.itb
lrwxrwxrwx 1 root root 55 Feb 9 09:05 dallas.img -> openwrt-ipq40xx-linksys_ea8300-initramfs-fit-uImage.itb
-rw-r--r-- 1 root root 7450000 Feb 9 08:43 openwrt-ipq40xx-linksys_ea8300-initramfs-fit-uImage.itb
(IPQ40xx) # printenv
altkern=5f80000
auto_recovery=yes
baudrate=115200
boot_part=1
boot_part_ready=3
boot_ver=1.2.9
bootcmd=if test $auto_recovery = no; then bootipq; elif test $boot_part = 1; then run bootpart1; else run bootpart2; fi
bootdelay=2
bootpart1=set bootargs $partbootargs && nand read $loadaddr $prikern $kernsize && bootm $loadaddr
bootpart2=set bootargs $partbootargs2 && nand read $loadaddr $altkern $kernsize && bootm $loadaddr
ethact=eth0
ethaddr=00:03:7f:ba:db:ad
flash_type=2
flashimg=tftp $loadaddr $image && nand erase $prikern $imgsize && nand write $loadaddr $prikern $filesize
flashimg2=tftp $loadaddr $image && nand erase $altkern $imgsize && nand write $loadaddr $altkern $filesize
image=dallas.img
imgsize=5800000
ipaddr=192.168.1.1
kernsize=300000
loadaddr=84000000
machid=8010006
netmask=255.255.255.0
partbootargs=init=/sbin/init rootfstype=ubifs ubi.mtd=11,2048 root=ubi0:ubifs rootwait rw
partbootargs2=init=/sbin/init rootfstype=ubifs ubi.mtd=13,2048 root=ubi0:ubifs rootwait rw
prikern=780000
serverip=192.168.1.254
stderr=serial
stdin=serial
stdout=serial
Environment size: 1130/262140 bytes
(IPQ40xx) # tftp
eth0 PHY0 up Speed :1000 Full duplex
eth0 PHY1 Down Speed :10 Half duplex
eth0 PHY2 Down Speed :10 Half duplex
eth0 PHY3 Down Speed :10 Half duplex
eth0 PHY4 Down Speed :10 Half duplex
*** Warning: no boot file name; using 'C0A80101.img'
Using eth0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.1
Filename 'C0A80101.img'.
Load address: 0x84000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#####################################################
done
Bytes transferred = 7450000 (71ad90 hex)
(IPQ40xx) # bootm
## Booting kernel from FIT Image at 84000000 ...
Using 'config@1' configuration
Trying 'kernel@1' kernel subimage
Description: ARM OpenWrt Linux-4.14.59
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x840000e4
Data Size: 7428549 Bytes = 7.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80208000
Entry Point: 0x80208000
Hash algo: crc32
Hash value: e99b68a9
Hash algo: sha1
Hash value: 1f8120a6ef2371d9c583fdb5752498f1767b4ae2
Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at 84000000
Using 'config@1' configuration
Trying 'fdt@1' FDT blob subimage
Description: ARM OpenWrt linksys_ea8300 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x84715be4
Data Size: 19579 Bytes = 19.1 KiB
Architecture: ARM
Hash algo: crc32
Hash value: ec1c0ee3
Hash algo: sha1
Hash value: 4709dd074325a04baac54808e2095cce55c8645f
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x84715be4
Uncompressing Kernel Image ... OK
Loading Device Tree to 871e7000, end 871eec7a ... OK
Device nand2 not found!
eth0 MAC Address from ART is not valid
eth1 MAC Address from ART is not valid
Using machid 0x8010006 from environment
Starting kernel ...
The bootlog tells me that the device-tree dtb gets put into the reserved-memory and hence the kernel won't access and it will not boot.
There's also sort of a (soft) limit to the size of a initramfs image. Big images are more likely to crash during extraction or shortly thereafter. If possible enable the INITRAMFS LZMA compression or remove packages.
As for the DTS: The best place to start would be the Meraki MR33. Although, please don't boot the MR33's initramfs image directly, because non-matching partition entries can end up corrupting / bricking the device.
Edit: Working on my own kernel now with a "from scratch" DTS and seems like it's booting. No serial output, which may be the cause of the symptoms discussed previously in this post. I suspect it's booting as the light that I configured for led-failsafe flashed reasonably quickly for a couple seconds, then a bit slower for a couple. And shoot -- now I've got my selected led-running lit. So either the gremlins are messing with me, or there's something alive in there.
At least for now, I'm past the issues described below. tftp and bootm seem to be doing their thing with the builds from my local WIP.
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.14.97 (jeff@deb-devel) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9272+4-26fcc937f7)) #0 SMP Sun Feb 10 02:56:38 2019
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[...]
root@OpenWrt:/#
From eariler:
Booting from memory is kicking my butt today. I'm hesitant to flash the device until I've got a nanddump of it and, of course, nandwrite is on the OEM firmware, but not nanddump.
[...]
checkout /dev/mtd[0..x]ro .
# cp /dev/mtd0ro /tmp/sbl.bin
or
# cat /dev/mtd0ro > /tmp/sbl.bin
or
# dd if=/dev/mtd0ro of=/tmp/sbl.bin
Make sure to record the bootlog from the firmware and watch for the entries when the mtd partitions are created. This will tell you where the "start offset" and "end offset" of a particular partition will be. It should look something like (This is from the RT-AC58U - so the values and names will probably different in your case):
[ 0.578810] 8 fixed-partitions partitions found on MTD device spi0.0
[ 0.583393] Creating 8 MTD partitions on "spi0.0":
[ 0.589961] 0x000000000000-0x000000040000 : "SBL1"
[ 0.595259] 0x000000040000-0x000000060000 : "MIBIB"
[...]
[ 1.880239] 1 fixed-partitions partitions found on MTD device spi0.1
[ 1.880708] Creating 1 MTD partitions on "spi0.1":
[ 1.886140] 0x000000000000-0x000008000000 : "UBI_DEV"
Please note: The DTS partition nodes "reg" property uses the same "start offset" but the second values encodes the "size" and not the "end offset). But you can easily calculate the size = "end offset" - "start offset".
check your kernel's cmdline. See if there's a console parameter .
Thanks -- enabling the serial node in the DTS was the problem. Right now, I'm enjoying the comparatively quick speed of testing with tftp and bootm, as well as the (illusion of) safety of not writing to flash. On my list to at least be able to read from NAND, as it seems I'm still missing some things either in the DTS overrides or in lower-level definitions or drivers.
Since at least one of the wireless cards is being seen, I thought I'd tackle the board files first. I see package/firmware/ipq-wifi, but at least as it exists today, it looks like it supports a single board file per chip type, per board instance.
I could use some suggestions as to how to handle two QCA4019s on the same board (along with a QCA9888).
(I'll also poke the mailing list later on this.)
From the OEM boot sequence:
/lib/firmware # dmesg | fgrep board
[ 25.110738] wifi0: Selecting board data file name boardData_1_0_IPQ4019_DK04_2G.bin
[ 25.110756] ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=IPQ4019/hw.1/boardData_1_0_IPQ4019_DK04_2G.bin
[ 26.532357] wifi1: Selecting board data file name boardData_1_0_IPQ4019_DK04_5G.bin
[ 26.532376] ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=IPQ4019/hw.1/boardData_1_0_IPQ4019_DK04_5G.bin
[ 28.217240] wifi2: Selecting board data file name boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
[ 28.217260] ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=QCA9888/hw.2/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
(yes, they all have different contents)
There's also some kind of "OTP" being done by the OEM drivers, but for starters I'll be happy to get the chips running and recognized 
Quite a few "interesting" files in /lib/firmware/, including AH, EU, IC, and FCC directories.
/lib/firmware # find .
.
./QCA9888
./QCA9888/AH
./QCA9888/AH/boarddata_0.bin
./QCA9888/AH/boarddata_1.bin
./QCA9888/AH/boarddata_2.bin
./QCA9888/AH/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
./QCA9888/AP
./QCA9888/AP/deleteme.bin
./QCA9888/AU
./QCA9888/AU/deleteme.bin
./QCA9888/EU
./QCA9888/EU/boarddata_0.bin
./QCA9888/EU/boarddata_1.bin
./QCA9888/EU/boarddata_2.bin
./QCA9888/EU/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
./QCA9888/IC
./QCA9888/IC/boarddata_0.bin
./QCA9888/IC/boarddata_1.bin
./QCA9888/IC/boarddata_2.bin
./QCA9888/IC/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
./QCA9888/PH
./QCA9888/PH/deleteme.bin
./QCA9888/FCC
./QCA9888/FCC/boarddata_0.bin
./QCA9888/FCC/boarddata_1.bin
./QCA9888/FCC/boarddata_2.bin
./QCA9888/FCC/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
./QCA9888/hw.2
./QCA9888/hw_2
./QCA9888/hw_2/boarddata_0.bin
./QCA9888/hw_2/boarddata_1.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_Y9484.bin
./QCA9888/hw_2/utf.codeswap.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_Y9690.bin
./QCA9888/hw_2/otp.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_YA105.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_Y9690_SBS_HB.bin
./QCA9888/hw_2/athwlan.codeswap.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_Y9582.bin
./QCA9888/hw_2/boardData_2_0_QCA9888_5G_YA841.bin
./QCA9888/hw_2/athwlan.bin
./QCA9888/hw_2/utf.bin
./IPQ4019
./IPQ4019/AH
./IPQ4019/AH/boarddata_0.bin
./IPQ4019/AH/boarddata_1.bin
./IPQ4019/AH/boardData_1_0_IPQ4019_DK04_2G.bin
./IPQ4019/AH/boardData_1_0_IPQ4019_DK04_5G.bin
./IPQ4019/AP
./IPQ4019/AP/deleteme.bin
./IPQ4019/AU
./IPQ4019/AU/deleteme.bin
./IPQ4019/EU
./IPQ4019/EU/boarddata_0.bin
./IPQ4019/EU/boarddata_1.bin
./IPQ4019/EU/boardData_1_0_IPQ4019_DK04_2G.bin
./IPQ4019/EU/boardData_1_0_IPQ4019_DK04_5G.bin
./IPQ4019/IC
./IPQ4019/IC/boarddata_0.bin
./IPQ4019/IC/boarddata_1.bin
./IPQ4019/IC/boardData_1_0_IPQ4019_DK04_2G.bin
./IPQ4019/IC/boardData_1_0_IPQ4019_DK04_5G.bin
./IPQ4019/PH
./IPQ4019/PH/deleteme.bin
./IPQ4019/FCC
./IPQ4019/FCC/boarddata_0.bin
./IPQ4019/FCC/boarddata_1.bin
./IPQ4019/FCC/boardData_1_0_IPQ4019_DK04_2G.bin
./IPQ4019/FCC/boardData_1_0_IPQ4019_DK04_5G.bin
./IPQ4019/hw.1
./IPQ4019/hw_1
./IPQ4019/hw_1/boarddata_0.bin
./IPQ4019/hw_1/boarddata_1.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK06_2G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK01_2G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK07_wifi0_5G_HB.bin
./IPQ4019/hw_1/utf.codeswap.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK06_5G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK04_5G_neg_pwr.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK01_5G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK07_wifi1_5G_LB.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK04_2G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK04_2G_neg_pwr.bin
./IPQ4019/hw_1/otp.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_Y9803_wifi0.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_Y9803_wifi1.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK07_wifi0_2G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK04_5G.bin
./IPQ4019/hw_1/athwlan.codeswap.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK05_2G.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK03_wifi0.bin
./IPQ4019/hw_1/athwlan.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK03_wifi1.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_YA131_wifi0.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_YA131_wifi1.bin
./IPQ4019/hw_1/utf.bin
./IPQ4019/hw_1/boardData_1_0_IPQ4019_DK05_5G.bin
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).
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
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 
. 
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
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
MAC conflicts.
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)
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
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:
firstboot isn't erasing the overlaysysupgrade doesn't seem to want to switch from mtd11 to mtd13 the first time, but does the second, or some such sillinessDealing 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.
Quick update:
bridge is required and there is no UCI integrationGetting 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
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.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.