Build for Linksys EA9500


Unfortunately I do not own one. Or else I'd be more than happy to build OpenWrt for it.


Just wanted to say --- a BIG THANK YOU to @npcomplete - I was using your build since March 2018 (I think I've used as first the 19-02-2018 build).
Btw -- for anyone upgrading from 19-02-2018 to 21-03-2018 I strongly recommend to (at least) reset to default settings... I didn't and I needed to clean-flash it over again (Router nearly overheated, has lost all connections etc. after the upgrade from GUI).

@npcomplete --- keep up the good work!


Still getting timeout errors (error 21) when trying to upload the TRX from the local TFTP.
Tried 2 different computers .
Please advise?



Can you ping the tftp server from the router?
What are the commands you are using?

I had some issues with the rights to the file I had to chmod 0777 to make it accessable

Good luck


I'm using windows 10.
Is it a problem?


Not necessary,
But you should still be able to ping the TFTP server. Can you? Thank your connection works. Just to start somewhere wit the troubleshooting.


Thank you! I've managed to make it work..


great job.



Ok it looks like we have a "fix" for the errors wrt mtdblock6. I had the ECC settings for this router wrong and this is not good if you are going to use the router for long term. The fix will involve everyone re-flashing their routers using serial cable unfortunately :frowning_face: :man_facepalming:

How many would like the firmware to do the right thing and fix the ECC? If so, I'll release a new build with detailed instructions. Thanks!

  • Yes, let's fix the ECC so that once EA9500 becomes part of OpenWrt regular releases, it won't brick my router
  • No, I just want to bury my head in the sand :chicken:

0 voters

i reported the bug


Good find!
How do you set this settings in the source code for compilation?, or is this something you need to do prior to flashing from the command prompt?


You have to edit the dts patch and remove the BCH section.


Is this the change?

diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index b6750f70dffb..ea1b3f5eff29 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -7,7 +7,7 @@

#include "bcm47094.dtsi"
-#include "bcm5301x-nand-cs0-bch8.dtsi"
+#include "bcm5301x-nand-cs0-bch1.dtsi"

/ {
compatible = "linksys,panamera", "brcm,bcm47094", "brcm,bcm4708";

Could I just change the 8 with 1 and recompile?


Correct, that's what you want to get rid of.


@npcomplete - since each and every one of us has already passed the "flash from scratch" I would suggest everything possible to bring your commits to the official community build branches -- even if we need to flash it again. I already love how the device behaves under a clean OS, started to get addicted to the freedom.
Let's call your next build "phoenix" that rises from ashes to redevelop itself :slight_smile:
How high are the chances that Lede/OpenWRT will incorporate the changes and start to build some official builds?


Thanks for your message and I agree to what you say. People using these builds have already flashed using serial cable. However, it's been over a year of smooth updates and the new build will break the norm people have been used to. Hence my hesitation and need to get everyone's approval.

I have been sending patches that should be accepted upstream. Mind you this is a slow process and I will try to create these builds till the patches are merged into OpenWrt.

That being said, I will wait for people to vote and plan to release a build on Cinco de Mayo :slight_smile:


Instructions for flashing May 3rd build:

  1. Enter CFE prompt and use Serial cable to flash and reboot
    flash -noheader nflash0.trx
  2. You will see a lot of ECC errors, don't worry, let the router do it's thing until you see log stop moving.
  3. Reboot the router and enter CFE prompt.
  4. Flash using serial cable again and reboot.
  5. When the log stops moving. Run this:
    cat /dev/mtd1 > /tmp/nvram && mtd write /tmp/nvram /dev/mtd1
  6. Reboot and you should be all set.


I did it no problems so far just followed your instructions.



For building from source is the change to the file:


@@ -7,7 +7,7 @@
-#include “bcm5301x-nand-cs0-bch8.dtsi”

+#include “bcm5301x-nand-cs0-bch1.dtsi”

The only change you did? Does this create the new /dev/mtd1 file?

what does this command really do?

cat /dev/mtd1 > /tmp/nvram && mtd write /tmp/nvram /dev/mtd1

It saves the /dev/mtd1 file into /tmp/nvram and then writes it back into /dev/mtd1 ? what do I misunderstand here? if I read the values from one location and than save it back isn't it just the same values again? I probably don't know what mtd exactly does.

Thanks for all the work you do here.


@linbox delete these exact lines from the patch:

+@@ -7,7 +7,7 @@
+ /dts-v1/;
+ #include "bcm47094.dtsi"
+-#include "bcm5301x-nand-cs0-bch8.dtsi"
++#include "bcm5301x-nand-cs0-bch1.dtsi"
+ / {
+   compatible = "linksys,panamera", "brcm,bcm47094", "brcm,bcm4708";

Using wrong ECC i.e BCH-1 caused two mtd partitions, nvram and firmware to incorrectly store ECC checksum for blocks of data stored on flash chip. This hardware supports 8 bit ECC checksum which is more error tolerant and we must be using that instead.

nvram partition corresponds to mtd1 partition while firmware corresponds to mtd3. CFE environment works in ECC BCH-8 mode as intended by the manufacturer while our previous firmware was BCH-1. Hence the only way to correctly write the flash is using software that talks BCH-8 i.e. CFE or serial port method.

Now, once we have the BCH-8 firmware on the router, we can fix the nvram partition. To do this we have to re-write the nvram in BCH-8 mode.

cat /dev/mtd1 > /tmp/nvram && mtd write /tmp/nvram /dev/mtd1

All we are doing here is reading nvram to ram and re-writing it in BCH-8 mode where the ECC checksum is recalculated correctly.


A post was split to a new topic: Power supply for Linksys EA9500