I have also updated my omnia and mox classic to 6.5.0 and updated firmware and factory-image. On both devices the updates went fine. Thank you @mionica for extensive exploration and recommendations.
The mox is now having uboot version: U-Boot 2022.07 (Aug 15 2022 - 12:25:08 +0000)
And the omnia: U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
However on the omnia, the fw_printenv command is still giving a warning message:
$ fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
I updated the content of /etc/fw_env.config to text below, which matches the logic used in /usr/bin/fw_env-config-init.sh. However after rebooting my omnia, the āWarning: Bad CRC, using default environmentā is still there.
/dev/mtd2 0x0 0x10000 0x10000
There was already extensive discussion about this, there is even post by @backon suggesting to fix it with:
It would, if you wired IOREF to 3.3V instead of 5V. But I wouldnāt dare trying just what I found on that page
If youāre into embedded, use a Raspberry Pico or RP2040-Zero - those are dirt cheap, and have 3.3V I/O by default; I believe thereās example code in the Pico SDK for using the pico as a uart-usb bridge.
Realistically though, thatās excessive. Just grab the cheapest usb-to-ttl-serial board thatās 3.3v and you can find on aliexpress or your preferred local robotics shop; chop off one end of 3 M/F-F jumper wires, and solder those to TX, RX and GND - then youāre sorted. Never wire the 3v3 or 5v of those to the Omnia - if your adapter canāt work off the USB voltage, get another one that can.
I personally use CH340Eās - theyāre 3v3, really small, really cheap, and use USB-C. The purple things.
Edit: Iāve confirmed the CH340E works just fine with baud set to 921600, with ~15cm jumper wires; having >100KB/s is great if you ever need to use kwboot or the like.
First, the correct contents for /etc/fw_env.config are indeed /dev/mtd2 0x0 0x10000 0x10000
(Iāve no idea why fw_printenv was working with 0xf0000 there - maybe it ignored the failed lseek()?; anyway, I fixed the wrong config I had posted earlier).
So, to get a proper environment in place, (no serial cable required), run these:
After the successful update, I enabled the latest firmware package list (all 3 subitems at once). Everything worked without any special steps in this case - but the LEDs were set to 0% brightness! This is the second router where this happened after MCU update. Normally I say LEDs are fancy stuff and I donāt care if their color or brightness is a bit off, but I really care about they indicating at least that the router has booted! It could be very intriguing for people to see the router completely dark after an update.
For reference, I had this U-Boot before update:
U-Boot SPL 2015.10-rc2 (Oct 06 2020 - 03:14:44)
U-Boot
U-Boot 2019.07 for turris_omnia
** Invalid partition type "%.32s" (expect "U-Boot")
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
U-Boot.armv7
No valid device tree binary found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>
U-Boot
U-Boot 2019.07 (Oct 05 2020 - 23:50:39 +0000)
U-Boot
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
fw_printenv works without issues after the update. I had no /etc/fw_env.config before the update.
you have already the newest U-BOOT at your Mox. The latest version is 2022.07.
Regarding factory image, not sure why is not workingā¦ I will look closer on it. (But to be honest we have full hands with TOS 7 now )
If you write via ssh this command ā schnapps update-factory
What is the output? This command should automatically download the latest HBS version, delete the older one and set it as default factory image.
it is not so easy to say regarding UBOOT. Because lot of users have old versions on their routers, like I was on my omnia at home. Or some people have first omnia from indiegogo campain for example. Thatās the reason why we marked it as āexperimentalā, becuase it is potencially dangerous.
Unfortunately lot of changes happened during the years and we tested of course different update cases, different uboot versions, but our sources are limited and we are not able to cover all cases.
For example my omnia at home had 2015 uboot and during testing phase I had no issue to update to the latest one, same with MOX. But we are really glad and appreciate your approach. Special thanks to @mionica here.
Of course we will collect all these problems and try to find the best solution.
Thanks to this firmware and MCU update we want to reach unity in our routers and bring new features sometimes based on firmware/MCU updates, like now, when users with the latest uboot and MCU have possbillity to switch off and automatically switch on the Omnia router.
So answer to your question is not so easy.
I got the same result after updated MCU. Easy fix is to log in to your router via ssh and send command ā rainbow brightness 8 or choose some number between 0ā¦8 how much you want of brightness. 0 ā none, 8-> max.
Even easier is to just press the brightness button (if you have physical access; but if you donāt, youāre probably not that much concerned about LEDs ).
I totally forgot on this button XD not using it. You are right.