Yes. Naturally. Every write operation has risk, so trying to rewrite the boot blocks increases the risk every time.
The bootloader needs to be written just once, when the installer installs the modified bootloader, initialises the basic ubi structure and installs the recovery OpenWrt iniramfs instance. But after that there is rarely a reason to update it.
Normal sysupgrades of the normal runtime OpenWrt instance are later done inside the ubi areas that provides wear leveling.
@daniel I have a question about your UBI installer instructions. You mention this in step 5 of your instructions
- Click exactly inside the radio button to confirm the terms and conditions, then abort the wizard.
Why do we need to abort the wizard? If I don't abort the wizard and continue with the stock firmware, will it later prevent me from flashing the UBI installer?
I am already using 3 RT3200 flashed with OpenWrt UBI and I followed your instructions everytime. I never tried the stock firmware anytime. I recently bought a new RT3200 (USD $60 + tax at Walmart.com USA) and I would like to test the stock firmware for a few days and then flash OpenWrt UBI on it.
If I wanted to do full backup, please let me know if the order of steps at Belkin RT3200/Linksys E8450 WiFi AX discussion - #2785 by ka2107 correct in that case?
I hadn't done full backup for my 3 existing RT3200, but I have the minimal backup files for 2 of them. I haven't tried reverting back to stock firmware on any of them, and don't really plan to except if/when I decide to sell these devices later in the future.
Thanks in advance.
What sort of risk are we talking? 10%? More? How many writes can these things take? Can you check for damage on a production system?
Does rerunning the installer to say get the 22.03 release / recovery rewrite everything or only the new bits?
Much less. In the datasheet of this SPI-NAND chip they write "Max cycling: 100K Program / Erase cycles" which is typical for SLC NAND. But obviously that doesn't mean that you can safely write 100k times and then the 100k + 1 time it will certainly fail. In reality this depends on a lot of factors including small errors in the silicon manufacturing process, exposure high or low temperature, radiation exposure, ... and even the kind of data you are writing to it. Hence, if you don't need to write to area which is critical for the system to boot, I would not do it.
UBI keeps track of write counters of the area of the flash which is used by UBI (ie. everything but not ARM Trusted Firmware and U-Boot) and wear leveling is based on that information.
The boot area (first couple of megabytes) of the flash is written to only once in the factory and one additional time when you run the installer. There is no tracking or counter of the write cycles used on that area.
Re-running the installer will re-write everything and you should not do it unless you have a very very good reason to do so.
Yes, that looks correct.
No, it won't prevent you. It just wastes your time and wants you to connect the device to the Internet. Newer versions of the stock firmware also no longer allow you to abort the wizard...
@daniel Thank you for your answers.
I also noticed something minor in your github repo. The ARM trusted firmware package version number is unchanged in UBI Installer v1.0.0 (same as in UBI Installer v0.5.2), but the package in v1.0.0 image seems to be updated based on the release notes.
ARM Trusted Firmware A v2.4(release):OpenWrt v2021-05-08-d2c75b21-1
Thanks. How can we check if we have badblocks? Or does having a working setup mean no bad blocks?
Hi,
Have been decided the root-cause permanent solution for the potential of hangs on rebooting problem?
I have a brand new RT3200 and I want to install permanently OpenWRT but release v1.0.0 of ubi-initramfs-recovery-installer may not include this fix yet.
Considering that doing a future bl2 update is dangerous, does make sense to wait to install OpenWRT because maybe this issue is going to be fixed very soon and included in the next ubi-initramfs-recovery-installer release?
Unfortunately the hang-on-reboot issue with the 300MHz@0.9V operating point is still present, even in the newly published updated ARM Trusted Firmware v2.7 
root@OpenWrt:/# cd /sys/devices/system/cpu/cpufreq/policy0/
root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# echo userspace > scaling_governor
root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# echo 300000 > scaling_setspeed
root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# cat scaling_cur_freq
300000
root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# reboot
[ 69.182444] br-lan: port 4(lan4) entered disabled state
[ 69.193696] device lan1 left promiscuous mode
[ 69.198325] br-lan: port 1(lan1) entered disabled state
[ 69.258958] device lan2 left promiscuous mode
[ 69.263552] br-lan: port 2(lan2) entered disabled state
[ 69.328540] device lan3 left promiscuous mode
[ 69.333126] br-lan: port 3(lan3) entered disabled state
[ 69.398408] device lan4 left promiscuous mode
[ 69.403008] br-lan: port 4(lan4) entered disabled state
[ 69.466739] mt7530 mdio-bus:00 lan4: Link is Down
[ 69.649621] device eth0 left promiscuous mode
[ 69.663175] mtk_soc_eth 1b100000.ethernet eth0: Link is Down
[ 73.844748] reboot: Restarting system
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02CA [000F]
Jump to BL
NOTICE: BL2: v2.7(release):OpenWrt v2022-08-31-75393484-1 (mt7622-snand-1ddr)
NOTICE: BL2: Built : 16:39:01, Sep 5 2022
*** and there it hangs for ever ***
I've also reported this to upstream again here:
However, as this 300MHz operating point has been removed as a work around you can of course safely operate the device with the current installer, release and snapshot images even with the ondemand scheduler or manually clocked down to 437.5 MHz @ 1.0 V (which is then the lowest available operating point of the CPU) without any issues at reboot.
Thanks for your updates.
What are your last post install recommendations for the best settings?
Should I still add to /etc/rc.local the lines
echo 437500 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
or this is not necessary any more?
That's not necessary any more as the 300 MHz @ 0.9V OPP has been removed from the device tree and is not available any more:
root@OpenWrt:/# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
437500 600000 812500 1025000 1137500 1262500 1350000
But if I want to optimize power consumption and heat is still necessary to set /sys/devices/system/cpu/cpufreq/policy0/scaling_governor to ondemand or to schedutil right?
Yes as default is userspace which just runs one specified freq.
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
conservative ondemand userspace powersave performance schedutil
what are the different behaviour of these available options? Ok, some of them are self explaining but the differences between ondemand and schedutil are not.
I just flashed the current v1.0.0 installer and release files on my brand new RT3200 and everything went well, thank you for your great job!
Here’s the documentation on them https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
Is there any advantage to using the mtk drivers rather than mt76 ones. I'm running snapshot, and things seem generally stable at this point, what's the pro/con to using the proprietary drivers?
MT76 currently appears broken for some devices when in 802.11ax mode and there is >= 1 wall between AP and client. Speeds drop extremely low. Not sure if proprietary drivers actually fix the issue though.