[PLUG] FOLLOWUP: Portland Linux/Unix Group General Meeting: OpenWrt Clinic, Part 2

Russell Senior russell at pdxlinux.org
Fri Jan 3 17:09:57 UTC 2025


U-boot is replaced by the installer, and I think it was specifically in 
order to be ubi aware.

bootloader 1 is in silicon
bootloader 2 is "mt7622-snand-ubi-1ddr-bl2.img" in /dev/mtd0
bootloader 3 is actually "U-Boot 2024.07-OpenWrt-r27137-f51cb74473 (Aug 
12 2024 - 22:48:06 +0000)" in /dev/ubi0_0 (fip)

When I was debugging the warm boot problem, I confirmed (with sha256sum) 
that I had the same bootloader 2 and bootloader 3 as another working 
flashed device. The ubootenv was identical except for a MAC address and 
ubootenv2 was exactly identical. The "factory" partition is different 
between devices, because of calibration data and such, and the writable 
filesystems were different (to sha256sum).

Here's the installation script:

https://github.com/dangowrt/owrt-ubi-installer/blob/main/files/installer/install.sh

Once the u-boot is installed, it's left alone during sysupgrades. To 
some approximation, a sysupgrade on ubi deletes the rootfs_data ubi 
volume (the writable filesystem), replaces the "fit" ubi volume, which 
is the kernel + squashfs, and then whatever is left over is allocated 
back to a new, empty "rootfs_data" ubi volume for use as the writable 
filesystem overlay. Additional shenanigans preserve configurations 
across sysupgrades. I am not sure exactly how that works on NAND, but 
for NOR flash devices, a tarball is created in tmpfs of registered 
"important" files, the new firmware is written to flash, followed by the 
tarball, and on first boot, that tarball is copied back to a tmpfs, the 
writable filesystem is created, scripts run and then the tarball is 
unpacked back into the writable filesystem.

It could be that the warm boot hang was confounding the normal boot up 
to "production" firmware. That part is still unclear to me. But once I 
got the correct ubi firmware flashed, cold boots were booting the 
production firmware automatically, and then it was down to someone 
remembering the two or three comments in a 6000-plus comment forum 
thread that was the clue about the two line "fix". It apparently only 
affects RAM on early production models, which is maybe why I hadn't seen 
it before in the other 8 or so E8450's I've flashed.

-- 
Russell Senior
russell at pdxlinux.org

On 1/3/25 08:20, Ted Mittelstaedt wrote:
> Cool!  So then, is the uboot version on your device, which came from the factory with the older 1.1 factory firmware, different than the
> Uboot version on your other devices, which came from the factory with the newer 1.2 firmware?
>
> Does any jump of the factory firmware from version to version rewrite uboot with a newer version?
>
> Is your uboot ubi aware or not?  Or does that even matter with uboot?
>
> I noticed when you ran your report on your device, it said no NAND blocks were bad.  So I'm assuming the ubi and non-ubi firmware would both run fine on it - and would do so until a block failed in which case the non-ubi firmware would crash.
>
> Interesting about the voltages.
>
> Ted
>


More information about the PLUG mailing list