[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