If you're reading this, I'm assuming you've got a challenge in front of you, so here's a table of contents
The U-Boot environment variable
boot_part is what primarily determines which of the two firmware sections will be used for boot.
sysupgrade (either over the command line or LuCI) or the OEM firmware flashes a new image, it flashes the "other" one and changes
boot_part to boot from the new image next.
After three "failed" boots, U-Boot will try the "other" one from what it was without user action.
This is one way to switch firmware, especially from a box that is hanging before a console is responding. Powering-off the EA8300 before the LINKSYS light goes on solid white (will usually work even before the "failsafe" flashing starts) will almost always go against the "three, bad boots" counter.
With SSH access to the device,
fw_setenv boot_part 1 or the like can be used.
shows which MTD partition is associated with /dev/ubi0, which should be
There is a LuCI module for switching, but at this time it does not support the EA8300.
It might be a good "first project" to add the EA8300 to
The IPQ40xx chips have a unique take on things. "Normal" VLAN config will be seemingly ignored by the device.
On my list to determine the scope of what does work with these devices.
Prior to July, 2019, the OpenWrt EA8300 firmware would fail to sysupgrade (or through LuCI) over existing OEM firmware.
First, get back to the "good" version of OpenWrt. Powering off the "hung" boot three times should get you there.
For now, instructions are at
This looks like a good thread to tag on my issue and resolution - apologies if this isn't the appropriate place though...
Wifi issue on flashing new device:
I've just received a BNIB Linksys EA8300 (in fact, two, as there is someone on eBay UK selling a large amount of them) and flashed it to Openwrt (22.03.3 (r20028-43d71ad93e)). The wifi refused to start.
Having looked at the syslog and read a few pieces on the forum it looked like the issue was to do with invalid channel selection.
In /etc/config/wireless I changed each config wifi-device entry from e.g.
option channel '100'
option channel 'auto'
...restarted, then enabled each SSID, and the wifi came up successfully.
Hopefully that's useful to anyone else in the same position - if it would be helpful to reconstruct that in more detail, provide logs etc. I would be happy to do so.
I don't know the project well enough to know if that's a change that could / should be rolled into the default device config...
Just be aware, that not all of these appear to be new (even if they were in plastic sealed boxes), I ordered two, and while one worked fine, the other had an old Chaos Chalmer snapshot on both partitions and has proved to be frustratingly difficult to upgrade (won't accept newer images, flashing the stock image seemingly does nothing, and I'm now going to have to build a 17.X snapshot image for it to see if I can upgrade gradually).
The wiki has been updated with the instructions to fully support the newer OpenWRT stable and snapshot releases, since January 1st 2023: https://openwrt.org/toh/linksys/ea8300#upgrading_openwrt_from_22035_into_23xx_or_snapshot_images
I am getting repeating following lines in dmesg after fresh install of Openwrt 23.05 and enabling wifi:
ath10k_ahb a800000.wifi: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Could this be a glitch as this seems like a debug info?
The wifi functionality seems not to be affected.