@Lexeyko Thanks anyway for the support!
It would be helpful if someone else here in the forum would try to update u-boot with the same steps to see where the problem lies...
You need to clean up volumes 0_1 and 0_2, so the environment is read from the u-boot image and written back on the first boot.
This means that, before flashing BL2 and FIP with mtd write, I have to execute step 3 of the Wiki as follows?
3. Format ubi and create new ubootenv volume
ubidetach -p /dev/mtd8; ubiformat /dev/mtd8 -y; ubiattach -p /dev/mtd8
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
No, you just need to wipe ubi0_0 and ubi0_1 so that environment variables are read from the image (RAM), rather than the disk.
When that happens, the environment instructions are set to first boot, which then sets up the correct environment and u-boot writes that to your disk.
ubiupdatevol /dev/ubi0_0 -t
ubiupdatevol /dev/ubi0_1 -t
reboot
This can be done at any time to reset your boot environment, not just after installing a new version of u-boot.
2 Likes
What is the correct output for fw_printenv?
Mines looks like this. I have no ver= or bootmenu_title
p:~# fw_printenv
CountryCode=CN
Router_unconfigured=0
SN=xxxx/xxx
arch=arm
baudrate=115200
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${loadaddr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${loadaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=0 mtd=ubi uart_en=1
bootcmd=bootxq
bootdelay=3
bootmenu_0=Startup system (Default)=bootxq
bootmenu_1=Startup firmware0=bootxq 0
bootmenu_2=Startup firmware1=bootxq 1
bootmenu_3=Upgrade firmware=mtkupgrade fw
bootmenu_4=Upgrade ATF BL2=mtkupgrade bl2
bootmenu_5=Upgrade ATF FIP=mtkupgrade fip
bootmenu_6=Upgrade single image=mtkupgrade simg
bootmenu_7=Load image=mtkload
bootmenu_delay=5
color=101
ethaddr=58:xx
ethaddr_wan=44:xxx
ethaddr_wan2=58:xxx
ethprime=eth1
fdt_high=0x6c000000
fdtcontroladdr=4ffc4490
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=1
flag_ota_reboot=0
flag_try_sys1_failed=15
flag_try_sys2_failed=8
invaild_env=no
ipaddr=192.168.10.1
loadaddr=0x46000000
mode=Router
model=RD03
mtdids=nmbm0=nmbm0
mtdparts=nmbm0:1024k(bl2),256k(Nvram),256k(Bdata),2048k(factory),2048k(fip),256k(crash),256k(crash_log),34816k(ubi),34816k(ubi1),32768k(overlay),12288k(data),256k(KF)
no_wifi_dev_times=0
pcbasn=xxx/xx
rand_key=xx
rand_nonce=xxx
restore_defaults=0
serverip=192.168.10.100
ssh_en=1
stderr=serial@11002000
stdin=serial@11002000
stdout=serial@11002000
telnet_en=0
uart_en=1
wl0_radio=1
wl0_ssid=rd03_minet_9a57
wl1_radio=1
wl1_ssid=rd03_minet_9a57
cat /etc/fw_env.config
up:~# cat /etc/fw_env.config
/dev/mtd1 0x0 0x10000 0x20000
So, just to be sure and to not have a brick, the correct steps (in the correct order) to be executed for upgrading U-Boot are as follows?
opkg update && opkg install kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
mtd write /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-ubootmod-preloader.bin BL2
mtd write /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-ubootmod-bl31-uboot.fip FIP
ubiupdatevol /dev/ubi0_0 -t
ubiupdatevol /dev/ubi0_1 -t
reboot
Thanks for the support! 
Yes. similarly you can update the recovery image in the same fashion at any time.
To update recovery it is sufficient to execute only this command at any moment, isn't it?
ubiupdatevol /dev/ubi0_2 /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-ubootmod-initramfs-recovery.itb
cat > /etc/fw_env.config <<EOF
/dev/ubi0_0 0x0 0x1f000 0x1f000 1
/dev/ubi0_1 0x0 0x1f000 0x1f000 1
EOF
cat > /etc/config/ubootenv <<EOF
config ubootenv
option dev '/dev/ubi0_0'
option offset '0x0'
option envsize '0x1f000'
option secsize '0x1f000'
option numsec '1'
config ubootenv
option dev '/dev/ubi0_1'
option offset '0x0'
option envsize '0x1f000'
option secsize '0x1f000'
option numsec '1'
EOF
This is only valid if you are running OpenWrt's u-boot and you have created ubi0_0 and ubi0_1 with the instructions from he wiki.
Yes. The former instructions wipe the volume and this one replaces the contents of the volume with that of the given image.
1 Like
Thank you very much!
Last question, I hope: is there a way to check that recovery updated correctly (e.g. comparing the versions before and after flashing recovery)?
Ah I thought I did follow the instructions on the wiki to update uboot!
So does this mean I haven't updated my uboot properly then?
Edit - the files I'm creating/editing by using your cat commands, should they have been set somehow via the instructions in the wiki?
up:~# strings /dev/mtd8|grep -i u-boot
[31mLoad BL31+U-Boot FIP via TFTP then write to NAND.
[33mU-Boot 2025.01-OpenWrt-r28801-1ee44825ad (Feb 11 2025 - 17:28:45 +0000)
ver=U-Boot 2025.01-OpenWrt-r28801-1ee44825ad (Feb 11 2025 - 17:28:45 +0000)
Looks as though there is some version of uboot on mdt8 (I found this command after Googling to find the uboot version installed)
fw_setenv bootmenu_default 3
reboot
After logging into recovery and confirming the image it's booting:
fw_setenv bootmenu_default 0
reboot
Make sure the recovery image is bootable, if you don't have a way to select boot options through UART.
Alternatively, you can dump /dev/ubi0_2 and check the checksum.
They are created by /etc/uci-defaults/30_uboot-envtools, but this process is skipped if you upgraded your system by keeping the old configuration. This is why it's important to do a clean flash when changing u-boot versions.
[ -e /etc/config/ubootenv ] && exit 0
Cool thanks for that. Just for my understanding. Do those files (fw_env/uboot_env) tell the uboot tools where to look for the uboot variables / uboot location? I updated those files and now fw_printenv shows "ver=U-Boot 2025.01-OpenWrt-r28801-1ee44825ad (Feb 11 2025 - 17:28:45 +0000)".
It is interesting that the old file offsets still show things like "CountryCode=CN", these are required for the firmware to work correctly?
There isn't a massive requirement to update uboot regularly? It is only called into action when recovery is required.
No, u-boot doesn't read them at all. They are used by OpenWrt tools such as fw_*env (although you can ask for a different config file through the -c parameter).
As for why the old one shows data from the old bootloader, that's because the stock bootloader store and read environment data from mtd1 Nvram, while OpenWrt's bootloader uses ubi0_0 (ubi0_1 exists for redundancy).
After you switch to OpenWrt's u-boot, the old boot data is still left in Nvram. You can read the strings stored there by typing: strings /dev/mtdblock1
You rarely need to update your bootloader after flashing OpenWrt u-boot. Only do so if you are having issues or the new version contains a specific fix for your model, such as the nmbm fix for winbond NANDs.
1 Like
Thanks for the explanation
Fixing my comment about the winbond chip, the fix is applied to the kernel, not to u-boot, so even in this case you do not need to update your u-boot.
1 Like