Unfortunately I do not own one. Or else I'd be more than happy to build OpenWrt for it.
Hi,
Still getting timeout errors (error 21) when trying to upload the TRX from the local TFTP.
Tried 2 different computers .
Please advise?
Thanks!
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
Hi,
I'm using windows 10.
Is it a problem?
Thanks
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.
Edit:
Thank you! I've managed to make it work..
great job.
1 Like
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 
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
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 @@
/dts-v1/;#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 
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
1 Like
Instructions for flashing May 3rd build:
- Enter CFE prompt and use Serial cable to flash and reboot
flash -noheader 192.168.1.10:/openwrt.trx nflash0.trx - You will see a lot of ECC errors, don't worry, let the router do it's thing until you see log stop moving.
- Reboot the router and enter CFE prompt.
- Flash using serial cable again and reboot.
- When the log stops moving. Run this:
cat /dev/mtd1 > /tmp/nvram && mtd write /tmp/nvram /dev/mtd1 - Reboot and you should be all set.
2 Likes
I did it no problems so far just followed your instructions.
1 Like
For building from source is the change to the file:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -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.
1 Like
Just want to ask, we got our router RMA'd recently, and we got given a V2 unit 
am I correct when i say it's not supported by this ROM?
Thanks!