Hi @daniel, that's a great news! 
I have to confess that I was following the irc channel so I already knew that great news were coming... But I didn't expect an image that replace the U-boot automatically! That's very cool! 
I think I will start to test it very soon also because I probably filled up the BMT pool due to the "fake" bad block problem I had in the previous weeks.
However I have a question for you: Can I use your "UBI version" even if I have a bad block somewhere before the "factory" partition? I am sure of this, because if I don't use the BMT the rest of the flash is shifted of a block and so it can't load the calibration data, while if I use the BMT it works correctly.
(Sorry for the double post, I hit CTRL-Enter and it got posted automatically)
Sounds dangerous... BMT is switched off for UBI, as UBI is handling bad blocks for us. Having offsets changing because of bad blocks is a very wrong design and cannot work with UBI.
Hence you will have to make sure that factory starts at the right offset when BMT is switched off, ie. backup it with BMT switched on and write it back to the correct offset with BMT switched off (the new U-Boot acquired it's ethaddr from factory partition as well)...
So you have to make sure the following area on flash do not have any bad blocks on them (ie. BBT switched off)
0x00000000 - 0x00020000 (Preloader)
0x00080000 - 0x00160000 (BL31+U-Boot)
0x001c0000 - 0x002c0000 (Factory)
Ie. you may be lucky and the bad block resides somewhere between 0x20000 - 0x80000 or 0x160000 - 0x1c0000. If not, you will have to wait for me porting UBI SPL for TF-A...
Try booting non-BMT Linux with initramfs and carefully try erasing, writing and reading back the 128kB blocks in those unused areas -- if you win the lottery, you find the bad block there and it's all good, all needed will be making backup of factory with BBT switched on and then writing it back to the right offset with BBT switched off.
1 Like
Update: I've improved the installer to be able to detect if something happened to factory and in that case about and let the user decide what to do.
3 Likes
Update 2: I've implemented relocation of the eeprom-data block and mac-adresses block in factory partition when running the installer, ie. if BBT/BMT did some mess there before, this is detected and fixed, so offsets are then correct without BBT/BMT running.
See
2 Likes
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.
You'd have to start building U-Boot for MT7621.
https://github.com/gnubee-git/GnuBee-MT7621-uboot
Edit: hackpascal posted patch for upstream U-Boot https://patchwork.ozlabs.org/project/uboot/list/?series=270363
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.
1 Like
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).
1 Like
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.
1 Like
Thank you so much for your help 
Sorry, new to this device, how to boot to the secondary fireware? Need to configure by uboot?
Found your info on: https://openwrt.org/toh/linksys/linksys_e8450 and filled in some of the answers.
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:
linksys_e8450-ubi-bl31-uboot.fip
linksys_e8450-ubi-initramfs-recovery.itb
linksys_e8450-ubi-preloader.bin
linksys_e8450-ubi-squashfs-sysupgrade.itb
The installer generator script by now only uses the images generated by the buildbots and re-wraps the initramfs to, well, contain the installer.
3 Likes
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!
Will send an update after I flash today to share results.
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)
Thank you! If there are any updates in the UBOOT, how do I flash a UBOOT update?
very nice work.
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?