Is it safe to upgrade u-boot?

I noticed u-boot was never upgraded on my TO (CZ11NIC13).

~# strings /dev/mtd0 | grep "U-Boot 20"
U-Boot 2015.10-rc2 for db-88f682
U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200)

I wonder if it is safe to upgrade using nor-update and if there are any benefits at all or downsides.

1 Like

I upgraded my Indiegogo Omnia and had no problems. However, there have been issues with some devices (or: at least one):

The last messages on that thread seem to indicate that there is still work going on to fix remaining RAM training issues. However, that is now weeks ago and there has been no further feedbackā€¦

So, if you currently donā€™t have problems which a new u-boot would solve and/or you donā€™t feel comfortable with using the serial console in case of issues caused by the upgrade, maybe better wait for a solution of the remaining RAM training issue. Otherwise, the linked thread should give you the information youā€™ll need in case you run into issues after the upgrade.

3 Likes

As to me I did upgrade it with no problems. But it dependsā€¦ Just my 2 cents.

Thank you for the replies. Seems I rather stick with the current version until all issues are ironed out. :unamused:

U-boot is actively developed with v2024.04 being the latest ā€œstableā€ version and v2024.07 in works.
2015.10-rc2 on the machine is really outdated and 2022.10-rc4 in works for Turris is not fresh either. It is also strange to me RC versions are used.

Considering U-boot is not free from vulnerabilities, it puzzles me that it is so neglected.

As mentioned in the linked thread, I got random reboots after updating U-boot to the latest version on my Kickstarter Omnia. I have now reverted to the old version and it works fine.

Interesting, and did not know there was a new Uboot version.
So, if you should update you older version, is this the one you receive atm?

BTW i did update my 2015 indy TO, zero issues here.

I also have a Turris Omnia router from the crowdfunding campaign, 2 GB RAM version (revision ā€˜CZ11NIC13ā€™, board firmware type ā€˜stm32-rev23-user-regulatorā€™, U-Boot version 2015.10-rc2). I recently re-flashed it using the latest medkit - it is now running Turris OS 7.0.1 - and also updated the MCU firmware (the process was not straight forward, as already described in my previous topic).

Knowing that few months ago someone had issues after upgrading the firmware I tried to find more details about the DDR3 training code for Armada 385 SoC, code which was broken by Marvell several yeas ago (according to this post). And found out that @mbehun pushed some changes for Omnia to upstream U-Boot repository, including ones related to DDR3 training. These commits are included in v2024.10-rc1 (tag created yesterday) so I guess it will be released in October.

The same commits seem to be pushed to next-20240702-with-omnia-patches branch (from Turris U-Boot fork) but it is not clear to me if / where a version was released with these changes included.

Therefore I am asking @mbehun: could you please let us know if we can already test a Turris flavored U-Boot version with the latest patches (or you rather advice on waiting for v2024.10 to be released)? If so, on what branch it should be available, HBL? Also, is there still needed to manually set omnia_ddr3_training as per these instructions?

1 Like

@stou

The version was not released because I wanted to wait for official v2024.10 release of U-Boot.

If you are interested in testing the current U-Boot master, I can send you a binary for testing. But if the board has problems, you will need serial cable in case you need to configure either lower DDR frequency (eeprom update "DDR speed" 1333H) or older DDR training (eeprom update "Use old DDR training" 1), if the board has problems.

Would you be willing to try?

1 Like

@mbehun, yes, I would like to try it.

1 Like

Here you go: u-boot-with-spl-2024.10-rc1-for-stou.kwb.

You can use mtd write U-Boot filename.kwb to flash.

It seems that something went wrong. I downloaded the image with wget in /tmp, wrote it to U-Boot and rebooted:

root@turris:/tmp# mtd write u-boot-with-spl-2024.10-rc1-for-stou.kwb U-Boot
Unlocking U-Boot ...

Writing from u-boot-with-spl-2024.10-rc1-for-stou.kwb to U-Boot ...     
root@turris:/tmp# reboot

At the beginning it looked like it was booting normally but it started to complain about No EFI system partition and ended up with several TFTP server died; starting again messages.

boot log
root@turris:/tmp# Stopping router Turris.
[ 2499.944844] device wlan0 left promiscuous mode
[ 2499.949411] br-lan: port 6(wlan0) entered disabled state
[ 2500.455593] br-lan: port 4(lan3) entered disabled state
[ 2500.473074] device lan0 left promiscuous mode
[ 2500.477578] br-lan: port 1(lan0) entered disabled state
[ 2500.615504] device lan1 left promiscuous mode
[ 2500.619961] br-lan: port 2(lan1) entered disabled state
[ 2500.721713] device lan2 left promiscuous mode
[ 2500.726193] br-lan: port 3(lan2) entered disabled state
[ 2500.825915] device lan3 left promiscuous mode
[ 2500.830400] br-lan: port 4(lan3) entered disabled state
[ 2500.954993] mv88e6085 f1072004.mdio-mii:10 lan3: Link is Down
[ 2500.965537] device lan4 left promiscuous mode
[ 2500.970031] br-lan: port 5(lan4) entered disabled state
[ 2501.101915] mvneta f1030000.ethernet eth1: Link is Down
[ 2501.510066] mvneta f1034000.ethernet eth2: Link is Down
[ 2502.800012] watchdog: watchdog0: watchdog did not stop!
[ 2506.580983] reboot: Restarting system

BootROM - 1.73
Booting from SPI flash

U-Boot SPL 2024.10-rc1-OpenWrt-r26993+6-74879140a1 (Jul 25 2024 - 13:47:53 +0000)
High speed PHY - Version: 2.0
MiniPCIe/mSATA card detection... MiniPCIe
WWAN slot configuration... PCIe+USB2.0
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |
 --------------------------------
 |   0    |   5   | PCIe0       |
 |   1    |   5   | USB3 HOST0  |
 |   2    |   5   | PCIe1       |
 |   3    |   5   | USB3 HOST1  |
 |   4    |   5   | PCIe2       |
 |   5    |   0   | SGMII2      |
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from SPI


U-Boot 2024.10-rc1-OpenWrt-r26993+6-74879140a1 (Jul 25 2024 - 13:47:53 +0000)

SoC:   MV88F6820-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, 2T, ECC not enabled)
Core:  88 devices, 29 uclasses, devicetree: separate
WDT:   Started watchdog@20300 with servicing every 1000ms (60s timeout)
MMC:   mv_sdh: 0
Loading Environment from SPIFlash... SF: Detected s25fl164k with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment

Model: Turris Omnia
  MCU type: STM32
  MCU version: b5a8a24e007eb72be16aeb3fff6f03ec647023e4/67eddc9540526d0a9d9660f7a7867af9a28a68d6
  RAM size: 2048 MiB
  Board version: unknown
  Serial Number: 0000000B00008BF3
Disabling MCU watchdog... disabled
Regdomain set to **
pcie0.0: Link up
pcie1.0: Link up
pcie2.0: Link down
Net:   eth0: ethernet@70000, eth1: ethernet@30000, eth2: ethernet@34000 [PRIME], eth3: lan0, eth4: lan1, eth5: lan2, eth6: lan3, eth7: lan4
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
No EFI system partition
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
Missing RNG device for EFI_RNG_PROTOCOL
Loading Boot0000 'mmc 0' failed
EFI boot manager: Cannot load any image

Device 0: unknown device
scanning bus for devices...

Device 0: unknown device
starting USB...
Bus usb@58000: USB EHCI 1.00
Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb@58000 for devices... 2 USB Device(s) found
scanning bus usb3@f0000 for devices... Device NOT ready
   Request Sense returned 02 3A 00
No EFI system partition
Failed to persist EFI variables
No EFI system partition
Failed to persist EFI variables
2 USB Device(s) found
scanning bus usb3@f8000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

Device 0: Vendor: Generic- Rev: 1.00 Prod: USB3.0 CRW   -SD
            Type: Removable Hard Disk
            Capacity: 1938.5 MB = 1.8 GB (3970048 x 512)
... is now current device
** No partition table - usb 0 **
Couldn't find partition usb 0:1
ethernet@34000 Waiting for PHY auto negotiation to complete....... done
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
DHCP client bound to address 192.168.11.209 (3898 ms)
*** Warning: no boot file name; using 'C0A80BD1.img'
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'C0A80BD1.img'.
Load address: 0x800000
Loading: *
TFTP server died; starting again
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/01-d8-58-d7-00-40-ba
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/01-d8-58-d7-00-40-ba'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A80BD1
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A80BD1'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A80BD
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A80BD'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A80B
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A80B'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A80
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A80'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A8
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A8'.
Load address: 0x1900000
Loading: T
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0A
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0A'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C0
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C0'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/C
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/C'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/default-arm-mvebu-turris_omnia
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/default-arm-mvebu-turris_omnia'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/default-arm-mvebu
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/default-arm-mvebu'.
Load address: 0x1900000
Loading: T
TFTP server died; starting again
Retrieving file: pxelinux.cfg/default-arm
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/default-arm'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Retrieving file: pxelinux.cfg/default
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'pxelinux.cfg/default'.
Load address: 0x1900000
Loading: *
TFTP server died; starting again
Config file not found
BOOTP broadcast 1
DHCP client bound to address 192.168.11.209 (5 ms)
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'boot.scr.uimg'.
Load address: 0x1800000
Loading: *
TFTP server died; starting again
BOOTP broadcast 1
DHCP client bound to address 192.168.11.209 (4 ms)
Using ethernet@34000 device
TFTP from server 192.168.11.1; our IP address is 192.168.11.209
Filename 'boot.scr.uimg'.
Load address: 0x1000000
Loading: *
TFTP server died; starting again
=> 

Iā€™m not sure, but it might be related to the fact that before flashing the new U-Boot I inserted a microSD card via an USB adapter, configured it as external storage and enabled System Logs Retention.

I think I should also mention that the USB SD card reader is a double one (one slot for SD and another for microSD), but only a microSD is inserted; and I guess thatā€™s why itā€™s saying that 2 USB devices are found:
scanning bus usb@58000 for devices... 2 USB Device(s) found

Some updates:

  • I noticed that even though it was not successfully booting, it was automatically resetting about every 60-80 minutes.
  • I removed the USB to microSD card adapter and rebooted; same issues (e.g. No EFI system partition and TFTP server died messages).
  • Executed eeprom update "DDR speed" 1333H and rebooted; same issues.
  • Executed eeprom update "Use old DDR training" 1 and rebooted; same issues.
  • Executed env default -a + env save and rebooted; the *** Warning - bad CRC, using default environment warning was gone but EFI / TFTP messages were the same.
  • Re-flashed from USB flash drive; same EFI / TFTP messages.

(I will be AFK for few days; will try more - maybe booting over serial - when Iā€™m back)

1 Like

@stou please try in U-Boot:

env default -a
env save

(this will drop any settings that you may have in U-Boot environment, though)

1 Like

Already tried this, @mbehun (and as already mentioned in my previous post, the *** Warning - bad CRC, using default environment warning was gone but the EFI / TFTP messages are still there).

Do you have any other suggestion before trying to boot over serial?