Linksys EA6300 V1 is no longer available in bcm53xx/generic/?

Hello,

I have a Linksys EA6350 and in the past I am using the Linksys EA6300 V1 firmware.

But now I found that it is disappear in the bcm53xx/generic/ repo.

I don't know why. Could you add it back? Otherwise this device will be stopped at the 17.01-SNAPSHOT r3022 version, very sad.

Thank you.

Reason: https://git.lede-project.org/?p=source.git;a=commit;h=55ff15cfd50927c393300c372efe55ccbc41ad6d

1 Like

I've a EA6900 lying around here that I'd like to try and install LEDE on. I've a working serial connection to it and have managed to boot the ramdisk image on it.

Can I be of any help in getting support back for EA6300 (which looks like it's very similar to 6900) and perhaps support for EA6900 added?

Hello,
Is it planned to add this device back?
I may help devs.I've got a EA6300_V1.

The link @tmomas posted seems to indicate it's more of a Linux issue than a LEDE issue...

I don't know how Rafał came to that conclusion. CFE always boots nflash0.os2 first. As long as you flash to nflash1.trx2, you should be fine. I have a working EA6300v1. I'd be willing to test whatever you have.

What was the problem originally? Is there a bug report somewhere? I've installed this version

https://archive.openwrt.org/snapshots/trunk/bcm53xx/generic/openwrt-bcm53xx-linksys-ea6300-v1-squashfs.trx

without any problems. It says in the console it is Designated Driver build 50072 bleeding edge. I used the trx2 partition—the one starting at 0x1f00000. I flashed it using the serial port, the CFE interface and tftp:

flash -erase nflash1.trx
flash -erase nflash1.trx2
flash -erase nflash1.brcmnand
flash -noheader 192.168.1.2:openwrt nflash1.trx2
go

This thread is over a year old...you may wish to make a new thread.

:open_mouth:

WOW...Designated Driver was the working name for most recent development of the OLD OpenWRT circa 2016...i.e. OpenWrt 17 (as we know, it was actually LEDE 17).

Someone else mentioned something similar (e.g. device was de-supported in the OpenWrt/LEDE shuffle)...I'll have to search the threads.

I never know the policy with a new forum. Some are all like "DOANT NEKROOOOOOO!!!~!!1" and others are like "DUPLIKIT POAAAAST!!121!!". So yeah.

Anyway, I figured out the problem. The openwrt nand flash layout is:

0x00 00000 deep magic
0x02 00000 fallback image aka nflash0.trx, nflash1.trx
0x1f 00000 main image aka nflash0.trx2, nflash1.trx2
0x23 00000 ubifs overlay

(I use five zeros in groups because that's exactly 1MiB, so you can tell that the deep magic is 2 MiB long.)

CFE keeps a count of the number of failed boots somewhere in the deep magic, incrementing on every failed boot. The stock firmware resets that count somewhere to tell the CFE the boot had succeeded, and openwrt does not. So, every third boot, the CFE switches to the backup firmware and things explode from there.

The real solution is to find the relevant piece of deep magic and zero it on successful boot, just like the stock images do. But as a workaround, it is also sufficient to nuke the entire fallback image partition in the CFE:

CFE> flash -erase nflash1.trx

Then, CFE will do the following:

CFE> go
Invalid boot block on disk
Loader:raw Filesys:tftp Dev:eth0 File:: Options:(null)
Loading: Failed.
Could not load :: Timeout occured
Changed to the other image 0 (maxpartialboots exceeded)
Invalid boot block on disk
nflash1.trx CRC check failed!
Changed to the other image 1
Loader:raw Filesys:raw Dev:nflash0.os2 File: Options:(null)
Loading: ... 1816764 bytes read
Entry at 0x00008000
Closing network.
Starting program at 0x00008000
*** openwrt boots normally starting from here. ***

The fallback image fails its CRC check and the main image boots instead. Score one for the good guys.

I just finished building and flashing the git master head: OpenWrt SNAPSHOT, r7404-7ec931b7f0

It works fine with the workaround I described in the previous post.

1 Like

If you made a patch you should make a bug report, or make a post in the Developer thread.

What I did still shouldn't actually be done without the CFE workaround I described. Somewhere, it would have to be made clear that extra steps are required in the installation.

I should be able to replicate the effect with an extra line in the first-run script. Something like

# dd if=/dev/zero of=/dev/mtd2 bs=1024 count=31744

That shouldn't be done either, though, without other modifications, because openwrt's partition table is wrong. I get

# dmesg |less
. . .
[    2.113569] 4 bcm47xxpart partitions found on MTD device brcmnand.0
[    2.119811] Creating 4 MTD partitions on "brcmnand.0":
[    2.124947] 0x000000000000-0x000000080000 : "boot"
[    2.130605] 0x000000080000-0x000000180000 : "nvram"
[    2.136175] 0x000000180000-0x000001f00000 : "nvram"
[    2.141982] 0x000001f00000-0x000008000000 : "firmware"
[    2.149270] 2 trx partitions found on MTD device firmware
[    2.154705] Creating 2 MTD partitions on "firmware":
[    2.159659] 0x00000000001c-0x000000400000 : "linux"
[    2.165346] 0x000000400000-0x000006100000 : "ubi"
. . .

The first nvram is supposed to end at 0x2 00000, and the second nvram isn't nvram at all. It's the fallback image. Until that is fixed, the workaround really should not be attempted anywhere except in the CFE. So, I'd say, not a workaround accessible to the typical user, who would assume if the image is in /releases, would also assume it can be flashed using the router's own firmware upgrade mechanism.

So, I'm not done yet.

But I guess I can still make the flyspray issue.

Thanks for moving it to "For Developers" for me.

Oh my god, this is madness! I'm reading drivers/mtd/bcm47xxpart.c and it's total madness. The partition table isn't static at all. It's built up by a series of wild-ass guesses judging by the current contents of the flash, and could change at any time. If there's a stray header anywhere in the junk that often appears in the stock flash, spurious partitions will be made.

The only sane way to handle the cases where the parsing fails is to use static partition tables for the affected models, including the ea6300v1. In fact, I'd seriously consider using static partition tables for all models.

After all this time, it turns out Rafał was right. The ea6300v1 really doesn't have a predictable boot sequence, in a sense. It doesn't always try trx first, then trx2 second. It tries whatever it did last time first, then tries the other one if that doesn't work. So not only can the boot sequence be changed in a manner that persists on the next boot. The boot sequence is changed persistently by the boot loader itself if there's an error.

It actually gets worse than that. The stock firmware comes with a button in its web UI that changes the boot sequence. So, a user may never have even installed custom firmware and the boot sequence might not be the same as what had come from the factory.

Anyway, this and one other thing has caused me to revise my original workaround slightly. Now that I know I can use trx just as easily or as correctly as trx2, I use trx instead, giving more space for the UBIFS overlay. The other thing is it turns out you can tell CFE to act as the tftp server by specifying : as the image source.

new workaround:

CFE> flash -erase nflash1.trx
CFE> flash -erase nflash1.trx2
CFE> flash -erase nflash1.brcmnand
CFE> flash -noheader : nflash1.trx
(client-side:) # atftp -p -l openwrt-bcm53xx-linksys-ea6300-v1-squashfs.trx 192.168.1.1
CFE> go

I also found out why openwrt's partition table was wrong. After I erased trx to force CFE to boot to trx2, I had of course also erased the header, which is how openwrt finds partitions on these models.

I'm still experimenting with the stock firmware's ability to modify the boot sequence. I'll keep you apprised.

If somebody has an ea6300v1 that is in its factory state (or at least that hasn't ever had any kind of custom firmware installed on it), I'd like you to check to see what version of the stock firmware resides on trx and trx2. Ideally, you'd use CFE and a serial port, but you can also use the boot sequence switching button in the web UI, which can be found in troubleshooting > switch to backup firmware, or something close to that. Check the firmware version before and after hitting that button. If you need help, just let me know.

It's a pity you didn't help us design a proper solution & develop clean code. It took YEARS for a few experienced Linux developers to sort out partitioning problem. Even thought it's still incomplete.
It seems we could do that in a month (avoiding madness as the same time) with your little help.

I'm pretty sure it does and it's called bootpartition. See 89a0d9a9f194 ("mtd: bcm47xxpart: support layouts with multiple TRX partitions"). The remaining problem is that above code doesn't work due to bcm47xx_nvram_getenv failing at that early stage (NVRAM partition doesn't exist yet).

Current version 1.1.40.176337
after Restore previous firmware version:
Current version 1.1.40.160989
after Restore previous firmware version again:
Current version 1.1.40.176337

the button works exactly as described...

Hello,
Any news?