I would love to see the list of ‘changes since last RC’ for such a bold move 
Should be fixed now in RC3, we fixed just this issue, no other changes.
Agree. It is fixed now.
2 Likes
Hi all, a bit confused, when I enable Latest Firmware will it update firmware without extra adventure like serial connection etc?
Basically I connect to the router remotely.
Thanks.
Yes, it will. Serial is only need if something goes wrong with U-Boot update (and since the rc2, you can pick what you want to update).
2 Likes
Thanks. Are you tried all three options?
Turris 1.1 is very unstable. After restarting, the system boots for over 10 minutes.
Still not resolved
Kernel issues with Turris 1.x continues. Are you tried firmware upgrade?
Okay, so I’ve put my second Indiegogo 1GB Omnia on a serial cable and ran the update including all the firmware goodies, one by one. In bold, I emphasize things I consider to be issues to be looked into by the team.
1. Initial state:
$ 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)
$ sha256sum /dev/mtd0
c3fcbb64d3c24ab04954af4db8d5bd9414f3163cdaf506f2c6fb056169c1b833 /dev/mtd0
$ sha256sum /dev/mtd1
323914a0504700d23b5bf96fcd5fa899441f5a86f2335c7be5734af8cb088409 /dev/mtd1
$ schnapps factory-version
5.0.0
I first switched to HBT without selecting any new package lists and rebooted. No issues as expected.
2. I checked the “Latest firmware” meta checkbox in Reforis and nothing else, installed the packages and rebooted.
No issues, but no firmware update (as expected).
3. I checked “Factory image”.
Nothing happened. This one doesn’t install any packages on its behalf, so the postupdate hook did not run.
This is a bit unexpected, but will rectify itself with any following update or package install.
I ran the postupdate hook manually. After that,
$ schnapps factory-version
6.4.4
$ sha256sum /dev/mtd1
323914a0504700d23b5bf96fcd5fa899441f5a86f2335c7be5734af8cb088409 /dev/mtd1
So the postupdate hook updated the schnappshot to latest stable TOS version, while leaving the rescue image the same (as expected).
After reboot everything okay.
4. I checked “MCU” and installed the packages.
It went well, but the LEDs were left in a very unusual blinking pattern. The blinking pattern stopped at reboot. However, there was not “reboot needed” notifiaction generated by the MCU package list (I think it should be in case an update of the MCU actually happened).
The first boot attempt failed at DDR training (@mbehun):
U-Boot SPL 2015.10-rc2 (Aug 18 2016 - 20:43:35)
High speed PHY - Version: 2.0
SERDES0 card detect: SATA
Initialize Turris board topology
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 |
--------------------------------
poll_op_execute: TIMEOUT
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
:** Link is Gen1, check the EP capability
PCIe, Idx 2: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
Memory config in EEPROM: 0x01
ddr3_tip_pbs_rx failure CS #0
Title: I/F# , Tj, Calibration_n0, Calibration_p0, Calibration_n1, Calibration_p1, Calibration_n2, Calibration_p2,CS0 ,
VWTx, VWRx, WL_tot, WL_ADLL, WL_PH, RL_Tot, RL_ADLL, RL_PH, RL_Smp, Cen_tx, Cen_rx, Vref, DQVref, PBSTx-Pad0,PBSTx-Pad1,PBSTx-Pad2,PBSTx-Pad3,PBSTx-Pad4,PBSTx-Pad5,PBSTx-Pad6,PBSTx-Pad7,PBSTx-Pad8,PBSTx-Pad9,PBSTx-Pad10, PBSRx-Pad0,PBSRx-Pad1,PBSRx-Pad2,PBSRx-Pad3,PBSRx-Pad4,PBSRx-Pad5,PBSRx-Pad6,PBSRx-Pad7,PBSRx-Pad8,PBSRx-Pad9,PBSRx-Pad10,
Data: 0,75,19,15,20,17,20,20,CS0 ,
0,0,10,10,0,422,6,1,6,23,10,4,0, 63,63,63,63,31,31,63,63,63,63,63, 0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,
0,0,6,6,0,420,4,1,6,19,10,4,0, 63,63,63,63,31,31,63,63,63,63,63, 0,0,0,0,0,0,0,0,0,0,0, 0,2,2,8,0,0,5,8,8,8,0,
0,0,6,6,0,419,3,1,6,19,10,4,0, 63,63,63,63,31,31,63,63,63,63,63, 0,0,0,0,0,0,0,0,0,0,0, 3,1,1,9,0,0,0,1,6,6,0,
0,0,10,10,0,422,6,1,6,23,10,4,0, 63,63,63,63,31,31,63,63,63,63,63, 0,0,0,0,0,0,0,0,0,0,0, 0,1,0,0,0,0,0,0,0,0,0,
Run_alg: tuning failed 0
DDR3 run algorithm - FAILED 0x1
DDR3 Training Sequence - FAILED
<<< 30 second wait here, the watchdog kicked in automatically >>>
U-Boot SPL 2015.10-rc2 (Aug 18 2016 - 20:43:35)
High speed PHY - Version: 2.0
SERDES0 card detect: SATA
Initialize Turris board topology
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 |
--------------------------------
poll_op_execute: TIMEOUT
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
:** Link is Gen1, check the EP capability
PCIe, Idx 2: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.29.0
Memory config in EEPROM: 0x01
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200), Build: jenkins-omnia-master-23
SoC: MV88F6820-A0
Watchdog enabled
I2C: ready
SPI: ready
DRAM: 1 GiB (ECC not enabled)
Enabling Armada 385 watchdog.
Disabling MCU startup watchdog.
Regdomain set to **
MMC: mv_sdh: 0
SF: Detected S25FL164K with page size 256 Bytes, erase size 64 KiB, total 8 MiB
PCI:
00:01.0 - 168c:003c - Network controller
PCI:
01:00.0 - 11ab:6820 - Memory controller
01:01.0 - 168c:002e - Network controller
Model: Marvell Armada 385 GP
Board: Turris Omnia SN: 0000000B000061B6
Regdomain set to **
SCSI: MVEBU SATA INIT
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
Net: neta2
Hit any key to stop autoboot: 0
Setting bus to 1
BOOT eMMC FS
scanning bus for devices...
Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SUV500M Rev: 0030
Type: Hard Disk
Capacity: 114473.4 MB = 111.7 GB (234441648 x 512)
Found 1 device(s).
BtrFS init: Max node or leaf size 16384
4331048 bytes read in 152 ms (27.2 MiB/s)
BtrFS init: Max node or leaf size 16384
21434 bytes read in 108 ms (193.4 KiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x421628 ]
## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Device Tree to 0fff7000, end 0ffff3b9 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.15.142 (packaging@turris.cz) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 8.4.0 r16881+135-4a1d8ef55c) 8.4.0, GNU ld (GNU Binutils) 2.34) #0 SMP Thu Dec 21 07:34:52 2023
[ 0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Turris Omnia
<<< Normal boot followed >>>
5. I checked “U-Boot and rescue image” and installed the packages.
When the update finished, all LEDs went dark (0% brightness), but the router normally ran. After a reboot, the LEDs remained dark, but the router booted without any other issues.
I’ve manually adjusted the LED brightness using the button, which brought them to life, but all of them were white (I waited for a few minutes, still all white).
After another reboot, LEDs finally worked as they should.
Also:
$ strings /dev/mtd0 | grep 'U-Boot 20'
U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
$ sha256sum /dev/mtd0
f1c7561ca24a6ecec8ad6f30ca488587c002092bd0654b1c853ed2581b092b29 /dev/mtd0
$ sha256sum /dev/mtd1
76c6b46ca5e48d38f105d62d06ccfcf7fd107439ce535c21f02c302c4e9d64b3 /dev/mtd1
$ omnia-mcutool -v
Bootloader version: b5a8a24e007eb72be16aeb3fff6f03ec647023e4
Application version: 67eddc9540526d0a9d9660f7a7867af9a28a68d6
MCU type: STM32
Board firmware type: stm32-rev23-user-regulator
Features: 0x1f6e
EXT_CMDS
WDT_PING
LED_STATE_EXT
LED_GAMMA_CORRECTION
NEW_INT_API
FLASHING
NEW_MESSAGE_API
BRIGHTNESS_INT
POWEROFF_WAKEUP
CAN_OLD_MESSAGE_API
Application firmware length: 21400 Bytes
Application firmware checksum: 0xfeeb0f31
$ 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
Yes, fw_printenv doesn’t work after the update. I tried all of these combinations in /etc/fw_env.config:
/dev/mtd0 0xc0000 0x10000 0x40000
/dev/mtd0 0xf0000 0x10000 0x10000
/dev/mtd2 0x0 0x10000 0x10000
Does it mean the firmware upgrade did not migrate my custom SSD boot environment and uses the default (but how could the router boot from the SSD then)? I no longer have the serial cable attached, so can’t check or call saveenv manually in U-Boot.
Differences to the update of my other Omnia
- Wifi interfaces did not get renamed (I have the same mPCIe cards in the same order in both routers).
- No problem with BTRFS partitions vs. U-Boot. But on the second Omnia, I have only a single partition on the SSD, and that was not found to be problematic.
2 Likes
I upgraded both my Turris Omnia routers (CZ11NIC20 and CZ11NIC23) with these results:
- the WiFi configuration was reseted on both routers after update
- upgrade Turris Omnia 2020 (CZ11NIC23) went smoothly
- U-Boot and NOR update crashed during updating process on CZ11NIC20 router … serial connection and booting over serial (U-Boot and NOR update) solved it
So, basically a indi omnia model 2016 is not able to update the whole U-boot part without going the serial route?
It is. However, I suggest going step by step - first install the firmware update, reboot (hope it boots) and only then install the u-boot update. In my previous report, this led to successful update without the need for serial connection (I only had it for debugging purposes).
However, if you boot from a multi-partition SSD, you will most probably need to repartition it.
In any case, have the serial cable prepared and tested before you start the endeavor. And be ready for possible wifi interface renaming (i.e. have cable or VPN access to the router’s admin interface).
4 Likes
This would be probably something different, can you get a full console log, so we can see what is causing the long boot?
@miska This is what the serial console looks like.
0:30 I connected the power and 01:09:57 turris turris: Router Turris successfully started.
Console log ends at 0:55
1 Like
Still wondering how the brightness button will work as a gpi-key? Any example?
Thank you, it actually booted several times within that time period, I’ll ask kernel guys to take a look whether they can guess what the problem might be. Can you try booting without all your drives? Wild guess, but it looks like troubles sheduling tasks and few crashes happened in smartd, so it might be caused by somehow locked up USB…
It should be, but having a serial cable at hand is a good idea. And if you are using non-default setup (like booting from SSD), it gets trickier. We are trying to convert the configuration, but given the versatility of U-Boot, we cannot guess how to convert every setup.
Uhm, it is a indi ( so first ) model omnia, complete standard 2GB wifi 5 model ( with still excelent int mem), Ext USB drive for the storage, and running all the basic stuff like pots and adblock like a charm.
So, is there a reason to update the U boot part as in is it essential for future OS upgrades? since the only linux type computer i have is a rasp4 and i’m definitly what you would call a ‘enthousiast’ nOOb.
@miska
All usb drives removed.
Transmission, samba4 and smartd services stopped.
14:28 power on and Jan 4 14:40:44 turris turris: Router Turris successfully started.
The serial console looks the same.
I am attaching the complete boot.