Adding OpenWrt support for Linksys E5600

The AP firmware is still missing in the latest build commit but that’s easy to install. I will be building a new snapshot today on an x86 machine (as opposited to rpi I used for building the other image) that doesn’t come with luci such that I will install anything else directly from openwrt afterwards (probably a better way to do it). Anyway I will commit the new build in my repo. There seem to be some formal issues with the commit according to reviews but otherwise I hope it’s good to go so that I can stop building for it and rely on snapshots.

The master branch of my repository https://github.com/aashishkul/openwrt is now updated with lastest changes from openwrt/master. I have also pulled the development branch changes into master branch. I created a version of the firmware using master branch and found it to be very stable. Those who faced issues with the earlier firmware, may check using master branch.

I did built one from your branch merged into the official master. For now I cannot go back to stock anymore. Not sure why but I just can't manage it to boot from alternate version. I may have corrupted it or I have no way to find out which version is currently booted. Anyway my own build seems to be working fine (assuming I don't brick it due to corrupted alternate firmware). I think there is a NAND error like you mentioned the NAND is not used anywhere :

[ 22.634177] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.0
[ 22.641760] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.1
[ 22.646146] pppoe-wan: renamed from ppp0
[ 22.649258] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.2
[ 22.660325] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 512.3

I am wondering if there is a different NAND driver that must be used or if this is unrelated.

Also the new 5.10 kernel has mt76 driver improvements which apparently does have a testing flag for ramips so it could be interesting to test out the new driver on this device.

This message comes from s_env partition. You can format this partition and the error would go away.

See also Uncorrectable ECC error - #6 by aashishkul

1 Like

That's not relevant here. Both master and 21.02 branches are already on the 5.10 wireless stack, doesn't matter whether your kernel is 5.4 or 5.10.

Compare to 19.07, where you have a 4.14 kernel yet a 4.19 wireless stack.

I think I do remember seeing something like 'backported 5.10' something in dmesg which makes sense since the wireless drivers seem to work well. I can't find the post where someone explained the difference between 7613 and 7615 driver which was minor. I wonder if there will be a kernel module for 7613 soon.

MT76 already supports MT7613 but it's still a bit rough (no DFS e.g.). You also need some mt7663 firmware instead (which OpenWrt offers BTW). Look at the build profile of the EAP235-Wall e.g.

Also, mt76 doesn't follow mac80211 but is pulled from its own repository, so it is/will often be newer than the mac80211 backport OpenWrt uses.

I see. I guess so the drivers and the kernel are basically as good as it gets which is good to hear. Thank you.

Thank you. Seems like your pull request still has some minor modifications requested but I hope it is finally accepted soon.

I seem to have issues trying to boot from Stock too. Somehow, the router just hangs if I do the "3 time power-on/power-off" trick, instead of booting to stock.

I do have my router booting to OpenWrt successfully at the moment. Is there anything I can do to fix the stock firmware partition? Anything I can do to verify the partition? How can I tell which partition the router booted from?

This is exactly what happens to me. Can't find a way to know which one I am booting from. I did manage it to get it to boot from stock once but that was it. I do not plan on going to stock but it would be great to know that its there in case I messed up something.

Totally agree. It is a safety net which would catch when we fail, and I don't want to loose it. I think this might have started happening when I performed a sysupgrade. Can't really tell though.

Another symptom is - boot fails when router is cold-started. Need to turn it off once, and then it seems to make 3 attempts of boot(that fail) before the power LED starts flickering rapidly and OpenWRT fires up.

Almost makes me think we're booting off of alt_firmware. Too afraid to try re-flashing or performing sysupgrade now, for fear of bricking it.

Please check pull request #3957 on github. Is the dualboot OpenWRT functionality also possible on E5600 ? There is only a few lines that have changed. basically just allow two partitions to have two kernels (possibly as a fallback).

Yes. I have seen that pull request already. However, that doesn't make the dual boot functionality work. E5600 has similar firmware partitions and I tried it even before this pull request was created. But will give it a try and update if it works.

I have connection to on board debug UART and I will monitor what happens in a similar situation you described. On my router, boot from stock works if OpenWRT fails. I will see what we can do to make it work for others.

Oh i see. then i guess the only way would be to replace the uboot like for RT3200/E8450 but that is more effort and only upside would be a tftp server accessible from ethernet and freeing up more storage. however its quite risky since one wrong step will brick it but if the Uboot is replaced then only soft brick will be possible I am guessing.

Did you try performing sysupgrade, and see if that causes the issue?
Is it possible that we uploaded OpenWrt while the router booted from "firmware" partition?

Other than this, I can't think of anything I could have possibly done.

I don't know why you are having reboot issues honestly I have not see this issue once. Is it possible the hanging issue is because of your mesh package you are using? I am using the mainline Openwrt with only luci and E5600 patches and I haven't noticed that bug once. Rebooting works normally. Try compiling without any packages (other than the ones necessary in the pull request) and see if you still notice the bug.