Turris OS 7.0.3 is in RC!

Community office Testing branches
, , ,
1

Dear Turris users,

we just released Turris OS 7.0.3 into a testing branch. There are only few changes in the release, so it should be able to go out quickly and there is not much to test anyway :man_shrugging:

There is added support for upcoming 5G :telephone_receiver: kit for Turris Omnia. It should appear in retail in October, so we are preparing the software part.

But the other related part of the update is updated U-Boot. We did some changes for better compatibility with various RAM chips and added another reset mode - 10 LEDS which decreases RAM speed for better compatibility. You can now pretty safely update your U-Boot and if you encounter DDR training issues or instabilities, you can use this type of reset to resolve it by yourself. More documentation will follow. Big thanks to everybody who helped us test various U-Boot versions on various devices that we produced over the time!

10 Likes
3

Very interesting! What about Omnias booting from SSD? Will they be able to use the 10-LED rescue?

And are there some news regarding full support for SSD booting with rescue modes?

1 Like
4

7.0.2 → 7.0.3 RC1 update okay (no new problems introduced), no unintended cable/wifi or internet downtime. Restart was needed.

Transmission is still hogging the CPU.

When the firmware got updated, the router flashed all LEDs green. But after the reboot, it again set LED brightness to 0%. I guess this would scare someone who doesn’t have the serial link attached during the update. I’d say this has to be resolved before the updated is pushed to public. So far, it happened to me every time the MCU or U-Boot got updated via updater.

Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards, UBoot 2024.10-rc3. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, Syncthing, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, Strongswan IKEv2 VPN, morce.

Current boot log after the update: 
BootROM - 1.73
Booting from SPI flash

U-Boot SPL 2024.10-rc3-OpenWrt-r20343+127-4e1d1b7df0 (Sep 13 2024 - 01:38:50 +0000)
High speed PHY - Version: 2.0
MiniPCIe/mSATA card detection... mSATA
WWAN slot configuration... PCIe+USB2.0
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |
 --------------------------------
 |   0    |   6   | SATA0       |
 |   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-rc3-OpenWrt-r20343+127-4e1d1b7df0 (Sep 13 2024 - 01:38:50 +0000), Build: jenkins-TurrisOS-packages-hbk-omnia-1216

SoC:   MV88F6820-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, 2T, ECC not enabled)
Core:  89 devices, 31 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
OK
Model: Turris Omnia
  MCU type: STM32
  MCU version: b5a8a24e007eb72be16aeb3fff6f03ec647023e4/e44032e4c49337f77583d1caaf1b4b3682e878f7
  RAM size: 1024 MiB
  Board version: unknown
  Serial Number: ****
Disabling MCU watchdog... disabled
Regdomain set to **
pcie1.0: Link up
pcie2.0: Link up
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
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
  Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SUV500M Rev: 0030
            Type: Hard Disk
            Capacity: 114473.4 MB = 111.7 GB (234441648 x 512)

Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SUV500M Rev: 0030
            Type: Hard Disk
            Capacity: 114473.4 MB = 111.7 GB (234441648 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot.scr
1199 bytes read in 36 ms (32.2 KiB/s)
## Executing script at 01800000
gpio: pin gpio@71_4 (gpio 52) value is 1
21434 bytes read in 32 ms (653.3 KiB/s)
4281584 bytes read in 108 ms (37.8 MiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x4154f0 ]
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
Working FDT set to 2000000
   Loading Device Tree to 0fff7000, end 0ffff3b9 ... OK
Working FDT set to fff7000

Starting kernel ...
2 Likes
5

MOX classic, HBK branch, .5 GB, 2x WiFi, simple config. All seems OK.

6

Mox, 2x WiFi, no problem however still the old U-Boot 2022.07 (Aug 15 2022 - 12:25:08 +0000)

root@turris:~# nor-update
Verifying /dev/mtd0 against secure-firmware.bin ...
e12a263c63bd9860cff844763e81e56b - /dev/mtd0
e12a263c63bd9860cff844763e81e56b - secure-firmware.bin
Success
Verifying /dev/mtd1 against uboot ...
bd802eb0ec60fd89f983ac3cd4860fba - /dev/mtd1
bd802eb0ec60fd89f983ac3cd4860fba - uboot
Success
Verifying /dev/mtd3 against rescue ...
39f02d9fb36b4258bac37924bcdf570c - /dev/mtd3
39f02d9fb36b4258bac37924bcdf570c - rescue
Success
Can't find anything to flash to 'dtb' partition
7

Ahh, that’s Mox. This update only updated U-Boot for Omnia.

8

Hmm, sounds interesting! I’ve noticed that we’ll lose the USB3 in the front USB port when enabling the 5G kit. Would it at least be possible to keep the USB2 in the port? Or will it be “lost” completely?

9

I’ve been able to update to 7.0.3, everything went fine, but impossible to update the U-Boot, I’m getting an error :

root@turris:~# nor-update
Verifying /dev/mtd0 against uboot …
e1e576912a225b7bfbbfbb94ac4480cc - /dev/mtd0
9e402d90ad49d0043fd1e42f0a32f52b - uboot
Failed

I tried to reboot multiple time but still getting the Failed message.

10

Try with:

nor-update -v

To see whats wrong

11

it’s not giving much informations :

root@turris:~# nor-update -v
Checking and flashing ‘U-Boot’ partition: uboot → /dev/mtd0
Verifying /dev/mtd0 against uboot …
e1e576912a225b7bfbbfbb94ac4480cc - /dev/mtd0
9e402d90ad49d0043fd1e42f0a32f52b - uboot
Failed
Storing old U-boot environment to be preserved

and stay stuck like that without doing anything

12

As it operates on nor i can be quite slow. Did you gave it few minutes?

13

What do you have in:

cat /etc/fw_env.config

How old is your U-Boot:

strings /dev/mtd0 | grep "U-Boot" | head -1
14

It literally says Failed so I guess waiting wont help much

15

That Failed is actually our UX fault. The script runs a check whether you have the latest U-Boot. That Failed is part of that check, so it only means, that you have the old U-Boot and it will be updated. Then it tries to figure out which U-Boot you have to save your configuration or to migrate it. That means reading the NOR again. Only after that it will start with the update.

1 Like
16

So I guess it should say Failed. Hash mismatch. Attempting to update. Or something like that

17

here are the both output :

root@turris:~# cat /etc/fw_env.config
/dev/mtd0 0xf0000 0x10000 0x10000
root@turris:~# strings /dev/mtd0 | grep “U-Boot” | head -1
U-Boot SPL 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)

@Miska I haven’t touch it for the whole night but it didn’t change anything, it remain stuck.
I tried to reboot and restart the nor-update command but I’m getting the exact same result

18

You can try to run it with sh -x /usr/sbin/nor-update, it should help figure out where it is stuck.

2 Likes
19

Is based on latest and last OpenWrt 22.03.7?

20

I used that command and it remain stuck on the command : fw_printenv
I tried it from the terminal and never get the variable printed even after few minutes.