Hi ... I see that you have managed to completely replace the stock boot loader for the E8450. I was wondering if the same can be done for the E5600 . I have a working build with excellent work from this thread Adding OpenWrt support for Linksys E5600 . The E5600 allows two firmwares (probably as a failsafe) but the free space ends up being very little. The chip is MT7621 based unlike the on here and the flash layout looks like this
root@HomeNetwork:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "factory"
mtd3: 00040000 00020000 "s_env"
mtd4: 00040000 00020000 "devinfo"
mtd5: 00400000 00020000 "kernel"
mtd6: 01a00000 00020000 "ubi"
mtd7: 01e00000 00020000 "alt_firmware"
mtd8: 04200000 00020000 "gdata"
I was wondering if its possible to achieve the same for the E5600 and possibly free up more space.
If you want to get started, first thing is to think about a way you can try your own build U-Boot without risking to brick the board.
I'm not aware of the BootROM of MT7621 providing any fall-back method (such as loading the bootloader via Xmodem or Kermit in case loading from flash fails or by pulling a boot configuration pin).
JTAG details are public for that SoC, so if the board got MIPS EJTAG pads somewhere that would be a way to go.
Once you got U-Boot running, recognizing the NAND flash and communicating on Ethernet, you can use a UBI layout similar to what I've done with the E8450.
Wow thanks. So unless I have a way to resolder the flash by restoring its contents I guess I only get one shot at it (which makes your flash all the more impressive). If anyone wants to buy this one and give me a working copy I would happy to test it out but with my skills I will likely brick mine if I try myself. Also the guide says you need a tftp/serial console, is that necessary if you have a working OpenWRT image.
Usually you don't need to unsolder the flash for that. You can dump and write it in-circuit using SOP8-clamp attached to USB-SPI adapter, like this:
If this is parallel NAND rather than SPI-NAND, JTAG would be the way to go (in my case the SPI-NAND chip is BGA package version, so I also opted for JTAG so I won't have to mess directly with the flash chip).
Sorry, May I know how to enable the AX Wi-Fi by the configure file? as it only has an AC option to select in the Web GUI.
Also, how to backup the full NAND before flash to the UBI version?
Thanks.
I'm afraid AX support didn't make it to LuCI yet, also support for that in hostapd is still pending. This will all get fixed within the next couple of weeks.
Regarding making a full backup before flashing:
The best way imho is to flash openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb (ie. the regular initramfs, not the installer) and use that. This gives you full access to the flash storage (see Save mtdblock contents in the System -> Backup / Flash Firmware tab of LuCI) while not making any changes by itself.
However, you can NOT use that to then directly flash the installer, you will have to use the vendor's dual-boot mechanism to return to the regular stock firmware before.
What are the main benefits of moving from the stock bootloader (TF-A 2.2, U-Boot 2020.10) to your new bootloader 2021.04-rc3 ? Looks like the new UBI bootloader allows a) a change from JFFS2 to UBIFS and b) a NAND layout that boots faster and has more free space.
Can I load standard snapshot images from OpenWRT if the new bootloader 2021.04-rc3 is installed or do I need to load the dangoWRT versions? Must use UBI versions of OpenWRT if bootloader is updated. ".BIN" images of OpenWRT are for stock bootloader and ."ITB" images for UBI bootloader.
What uboot updates are being thought about after 2021.04-rc3?
The vendor loader uses the SPI-NAND flash like if it was NOR flash (ie. without wear-leveling). Also the partitioning and dual-boot scheme is not exactly great when running OpenWrt.
The advantage of replacing the bootchain (U-Boot and ARM Trusted Firmware) by more recent versions built from source are:
UBI support for industry-proven wear-leveling, bad-block-management, ... of the NAND flash to avoid wearing out the flash, take notice of ECC errors, ... (we are still using MediaTek ECC engine, of course. Just dropping the vendor-specific software BBT/BMT stuff.)
robust recovery vs. production dual-boot scheme
after full installation (ie. recovery and production image on flash) there are still 80MB+ free for rootfs_data
ability to boot EFI/BOOT/BOOTAA64.EFI, e.g. memtest86
more freedom to customize the bootloader
By now, everything apart from the script generating the installer needed once for the initial flash went upstream to openwrt.org, ie. you find the matching images on the download server:
You are a really smart dude! Thanks for doing this!!! A number of open source firmware projects switched from JFFS to UBIFS due to better reliability and adaptation for NAND. In my own experience with several of these firmware projects, UBIFS has been very reliable. MediaTek seems to be very supportive of OpenWRT. I get my RT3200 in a couple days and will use your procedure to replace UBOOT and flash the new OpenWRT UBI based image. Thank you for your help!
Installed your latest 0.3. One odd thing I noticed is that the "on" LED does not illuminate for about 8 seconds after turning on the router. Is this a SW driven LED? Do you see the same thing on your router?
Yes, all LEDs are software driven. I deliberately switch on the power LED only when starting the Linux kernel, so in case of a bricked device the status of that LED would still give you some information (ie. you are able to distinguish hard-bricked bootloadero or bootloop/crashing kernel from OpenWrt being stuck or misconfigured)
Just ordered a very cheap Belkin RT3200 and want to give it a nice and shiny OpenWrt as soon as it arrives.
If I got it right, I can use your script to generate an image that is installable through the OEM interface, right?
After the initial OpenWrt installation, can I just compile an OpenWrt image by myself and flash it through sysupgrade or the luci flashing interface to upgrade?
Here is where you can generate an image online: https://chef.libremesh.org/ The site works very well, but the 5Ghz radio does not come up with the snapshot images I generated. Probably missing a package for the MediaTek MT7915E chip. If you use this select "snapshot" and "Linksys E8450". If you get an image to work with both radios, reach out.
If you have serial access, I added an option to update bl2 as well as bl3+uboot via TFTP using U-Boot's bootmenu.
If you do not have serial access setup, the most reliable way would be to re-run the installer, but then the flash gets re-formatted, ie. you loose production system and rootfs_data content, so you need to backup your data before that.
Yes, you just need to make sure to pick the UBI variant of the device, as otherwise your flash will get corrupted by overwriting UBI structures also used by the bootloader.
Imho we should remove the legacy (non-UBI) image as soon as enough people have tested the UBI variant, using JFFS2 on NAND flash is not a good idea, unreliable and wears out the flash faster than needed. It needs UBI (or something similar) to work well in the long run, which is what the installer is setting up for you.
Sorry, new to this device, how to boot to the secondary fireware? Need to configure by uboot?