UBI vs NO-UBI

[ErnyTech]

From OpenWRT-Wiki:

Due to the not exactly advantageous layout and management of the SPI Flash, the best way to use the device is to replace everything rather than trying to stay compatible with the vendor firmware. If you just want to try OpenWrt and still plan to go back to the vendor firmware, use the non-UBI version of the firmware which can be flashed using the vendor's web interface. In this case, download the non-UBI variant of the device firmware openwrt-mediatek-mt7622-linksys_e8450-squashfs-sysupgrade.bin and upload it in the vendor firmware Web UI upgrade page.

If you do want to use OpenWrt permanently, the easiest is to create an installation image using github.com/dangowrt/linksys-e8450-openwrt-installer and use that once to convert the device to UBI layout.

Could you explain to me what the disadvantages are if I use openwrt-mediatek-mt7622-linksys_e8450-squashfs-sysupgrade.bin instead of this method that creates UBI?

[dangowrt]

• stock layout doesn't do any wear-leveling on the NAND flash, has "hot" blocks (physical blocks which are frequently written to) and uses JFFS2 filesystem, just like if it was NOR flash. If using the device with OpenWrt, you are likely to update it much more frequently compared to the vendor firmware which is probably not going to have more than 3-4 release within the warranty time... By allocating most of the flash (125MB out of the total available 128MB) to UBI (which takes care of wear-leveling) the expected lifetime of the device is much higher.
• stock layout uses A/B dualboot scheme and allocates 30MB to each image. In this way, available free space for rootfs_data (ie. space to install additional packages, store settings, etc.) is limited to around 20MB. With the UBI layout, a production vs. recovery dual-boot scheme is used. And as storage is allocated dynamically by UBI instead of having statically defined physical offsets for flash partitions, around 75MB are available for rootfs_data.
  • Using UBI, users can easily allocate space for additional persistent storage volumes for all sorts of things, e.g. container images, customization/localization/internationalization, read/write volumes for persistent logs/stats (has to be done carefully to not exhaust NAND writes!), ... Volumes can be read-only (eg. additional squashfs) or read-write, managed e.g. using uvol.
  • fully-featured U-Boot 2021.04 is much more powerful than U-Boot 2014.04-rc1, allows (among many other things) to make the dual-boot decision based on the cause of the previous reboot (crash/oops or normal reboot) using PSTORE/ramoops, ie. without storing any state on the flash. As a useful side-effect, users can now use echo c > /proc/sysrq-trigger to reboot into recovery deliberately, once in recovery you can clear PSTORE by rm /sys/fs/pstore/*, so U-Boot goes back to boot production image at the next reboot.

[BarryHuffman]

A few examples of flash devices which lack dedicated wear leveling hardware controllers are micro/SD, CompactFlash, USB flash drives, eMMC modules.

These "hot blocks" or zones that dangowrt mentioned will wear out prematurely due to the constant re-writing.

In modern SSDs and NVMes you hear of the term TRIM or garbage collection, the controller can also reallocate dead zones into unprovisioned areas which is not always transparent to the operating system.

In embedded devices (like routers) it's less common to see wear leveling due to costs of scale.

In those instances it can be mitigated through software with a copy on write filesystem or directly handled in OS drivers.

In the future we should hope all OpenWRT devices utilize UBI.

[robhancock]

A few examples of flash devices which lack dedicated wear leveling hardware controllers are micro/SD, CompactFlash, USB flash drives, eMMC modules.

All of those devices have wear levelling. The raw NOR or NAND flash in most routers does not and this needs to be done through software.

[BarryHuffman]

All of those devices have wear levelling.

They majorly utilize software based wear leveling on the OS.

There is few exceptions I've seen for SD/mSD/eMMC that are industrial non consumer.

For flashdrives "wear leveling" is not always equal and generally dynamic type.

I do see Corsair referenced that their older voyager used static while the rest of their devices are using dynamic type.

It doesn't look common place or advertised in the consumer space.

[robhancock]

Software wear levelling is almost never used with such devices such as SD, eMMC, USB flash. They are generally used with file systems such as FAT or ext4 and cannot assume that the OS will do any wear levelling. In some cases there is a pretty cheesy wear levelling strategy but there is always something, otherwise commonly written areas like the FAT tables would be quickly destroyed.

[chinmaythosar]

Is it possible to have the same UBI image for the E5600 if you happen to have one?

[dangowrt]

@chinmaythosar The E5600 is based on MT7621 (unlike the E8450/RT3200 which is based on MT7622). There is a series to add support for this SoC to U-Boot https://patchwork.ozlabs.org/project/uboot/list/?series=272786 and technically it's even a bit easier to handle compared to MT7622 because the Ethernet switch is built-into the SoC (hence always the same for all devices) and it's MIPS32, so no ARM Trusted Firmware. And no secretive stuff to calibrate the DRAM.

So it's thinkable to do similar things for MT7621-based devices as well, it's just a bit of work...

Update: Now that @mtk-openwrt patches for MT7621 are part of U-Boot, I added builds for the MIPS-based reference boards (mt7620, mt7621 and mt76x8): https://github.com/openwrt/openwrt/commit/2f7fb57c12d7afe5be7747611bceec92a4c0c834 Hacking up support for modern U-Boot with UBI support on any MT7621 board hence just became much easier.