Hi everyone,
I have just added the OpenWRT wiki page for Linksys EA8300 and began adding support for this device to LEDE. I am currently working on adding the device profile to the current LEDE GIT version. If anyone is interested, feel free to comment here.
Tech specs can be found here: https://openwrt.org/inbox/linksys/linksys_ea8300
Current status:
I am actually preparing the dts and dtsi files.
Firmware reports as ARM Linksys FIT (Flattened Image Tree) and the device as a
Linksys Dallas WiFi AP router based on Qualcomm AP DK07.1-c1
but seems to use qcom-ipq40xx-ap-dk04.1 what is a little confusing.
First I thought it is a good idea to import qcom-ipq40xx-ap-dk07.1-c1 dts files, but some things doesn't seem to fit (e.g. nand addressing).
For now, I am writing some Special qcom-ipq40xx-ea8300.dts and dtsi files, with the values the origin firmware reports and will try to build the image.
Especially FIT is making me some headaches...
well, let's hear it then. Any links to a preliminary git repo?
Yes, see: https://github.com/Bunkerschild/B-OS
I was unable to test the build on Hardware, because my EA8300 device has been destroyed in a thunderstorm. Anyone who wants to donate a device is welcome 
Yes, this is a start. It looks like you have stuck with the .dtsi from the stock firmware. So it looks like more work is required, since stuff like the "led controller" is not supported by OpenWrt or Upstream. (That said, the led-controller can be replaced by just gpio-leds with minimal overhead). etc.
rip 
.
Got a new device 
AND got it booting up via TFTP YEAH
You are right, I am struggeling around with the stock DTSI, but now it is clear: they used ap-dk07-c1. I am currently building an image with the new DTSI and drivers. Hopefully in an hour or so, I will get the switch ports online 
Hey Oliver, I am EXTREMELY interested in the progress of this support! I've used OpenWRT/DD-WRT in every router I've owned for the last 10 years or so, and regrettably I picked up this router for cheap as I thought it was a EA8500 (which currently has support for these CFW). So if there's anything I can do to test, let me know! Thank you
I am also very interested in enabling OpenWRT on EA8300. Not sure how I could help, but just raising interest 
I'm also interested
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