We just released Turris OS 6.5 into RC phase. Originally we wanted to release 6.4.5, but we have a bunch of features that we don’t want to keep to ourselves till Turris OS 7.0 (yes, we are still working on it, and it’s building again, we just need to fix reForis that got broken and retest again so stay tuned). This is definitely not the last rc but we want to get it out so it will get as much testing as possible. Now let’s dive into those:
Turris 1.X
We migrated to 5.15 kernel and fixed the problem that held us back at 5.10. Work well in our tests, but more testing in various configuration would be more than welcome.
Omnia
We now have a kernel counterpart for updated MCU firmware. You can read more details in merge request. You can now enable gamma correction on Omnias LEDs by writin 1 to /sys/bus/i2c/devices/1-002b/gamma_correction. You can also use omnia-mcutool --wakeup '2023-10-19 08:00' to start your Omnia after it has been shut down via poweroff. And you can also change the brightness button to gpi-key by writing mcu into /sys/bus/i2c/devices/1-002a/front_button_mode. To be able to do all of that, you have to upgrade your MCU firmware, but don’t worry, we have something to help you with that as well.
Generic
We added another interesting item to the list of available packages. You can now select that you want to have the Latest firmware and your router will automatically install latest U-Boot, latest rescue system and if you are on Omnia, even latest MCU firmware. Apart from that it will update your factory image, whenever you update to new major release. So now, it will make your factory image contain Turris OS 6.4.4, but once we release Turris OS 7.0, it will get updated to Turris OS 7.0, so you wouldn’t have to migrate again from Turris OS 3.0. As it touches really crucial parts of your router, do not enable it when there is high probability of power failure. It can break your router in a way that is not easy to fix.
We also changed some defaults to IPv6 setup and backported support for pref64 (RFC 8781), thanks to @Ondrej_Caletka for implementing it.
This time, more then ussually, we would like to get some feedback and make sure everything works as expected. Especially on Turris 1.X. Thank you for your help!
Is it safe to enable this when I’m booting from mSATA because the eMMC died?
And is it now generally considered safe to upgrade FW for all Omnia users? I remember there were advices to not try it on the Indiegogo pieces unless really needed.
Depends ont he version of U-Boot you had previously. If it was old, you might need to reconfigure U-Boot manually to be able to boot from mSATA.
There was a problem with DDR training after the code in U-Boot changed, but we believe that it is fixed now - at least on boards we could get our hands on. We are pushing it as experimental, because we want to make it more widely available and easier to test but we want technically skilled people to test it first and help us polish it.
Can you specify which U-Boot version is too old? But in any case, I guess the solution here would be to just boot with serial cable and rewrite the boot line again and save it, right? However, the question is what to do with this in a fully automated update once the fix goes into release…
I can give it a try. What is the fallback option if it doesn’t work? Is there some A/B switching or another way to upload the older U-Boot if it doesn’t work?
nOOb here, but personally i have zero interest in the whole LED music part. The 2016 Omnia is locked up in the closet.
So, is the whole tricky updating part just for that ‘function’? Since i have no clue about serial USB & U boot stuff.
6.4.4 → 6.5.0 RC1 update ok (no new problems introduced), no unintended cable/wifi or internet downtime. Restart needed.
I haven’t (yet) enabled the firmware update package list.
Sentinel C++ version still reported as “Dynamic Firewall: disabled”.
Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, morce.
Isn’t that expected to some degree? To check all channels, the AP needs to switch to those channels thereby loosing connectivity on the channel it uses for its own AP duties, no?
Turris 1.1 + WiFi upgrade + /srv on HDD.
Failed to reboot properly after upgrade. Power and WiFi LEDs remained on. The serial console was silent and the LAN was off. I left router in this state for about 30 minutes, then rebooted it by removing power. Router booted into the new system with no problem. So far I haven’t encountered anything malfunctioning.
Unfortunately, this update hasn’t fixed a problem that has been occurring sporadically for several months. Ethernet LAN stops responding. All devices connected by cable lose connection and report unavailable network. WiFi and WAN continue to work without any problem. There is no record of any error in the logs, even during the outage (I managed to capture it live once) there is no log of Ethernet devices disconnecting. I have no other modifications in the router except cron jobs for Acme, AdBlock and a few firewall rules for incoming traffic. I have ruled out DHCP, DNS, SD card and HW router error (I own another Turris 1.1). I was hoping it might be a kernel bug and would be fixed by this, but this morning I found the router in the same state. Has anyone encountered similar behavior? Now I’m going to gradually disconnect ethernet devices to see if there is a problem somewhere after all, but this condition appears most often 1-2 times a week, but sometimes it also lasts 2 weeks.
EDIT: I think I jinxed it. There’s just been a spontaneous reboot. Unfortunately /srv/log ends more than a hour before the reboot. The next log is after the boot itself.
It supports all our devices, but most notable difference is in case of Omnia. There were big changes in how U-Boot works, plenty of fixes in MCU firmware and quite some of the routers were released with Turris OS 3. MOX used pretty decent U-Boot to start with, but still updating factory to Turris OS 6 might be handy.
In really old version of U-Boot - aka original Indiegogo campaign, we had special handling of Btrfs before we upstreamed the support. The commands working with Btrfs looked quite different. You wouldn’t use normal load command, but something custom. Later on we also changed the NOR layout, but that should be handled by update utility and move you environment to a new offset. Any newer than that, updating U-Boot should preserve it’s environment and should boot just fine. The oldest version (aka Indieogo and shortly after) is the one that we try to automatically migrate scripts from custom command to the standard ones and thus there is the biggest chance that something might go wrong.
I can give it a try. What is the fallback option if it doesn’t work? Is there some A/B switching or another way to upload the older U-Boot if it doesn’t work?
[/quote]
Well, definitely not all cases are fixed. I can’t boot now after installing the firmware-upgrade package. Installation went without errors. And now boot stops at
DDR3 training sequence - 2nd boot - skip
And that’s all. I’m now trying to boot over serial. Kwboot from Ubuntu 20.04 repo didn’t work at all. I downloaded the cz.nic binary build and that seems to do something, but so far all attempts at booting from kwboot failed somewhere in the middle. Is it possible that the watchdog is killing the router in the middle of u-boot upload? I tried the higher speeds, but the practical result is always the same.
@peci1 only use the -B option to set higher baudrate if you have Prolific USB to serial converted (PL2303). In that case you can use baudrate 5200000.
I guess your previous u-boot was the original one from indiegogo campaing (2015). You can download it at https://repo.turris.cz/archive/omnia/3.11.23/nor_fw/. At the time you had to use different image when booting over UART, because kwboot at the time required it. But when using current version of kwboot it should be possible to use any one of those images.
The best way to get current version of kwboot is either to install u-boot-tools or to clone u-boot repository and build tools (you will need ARM compiler arm-none-eabi-gcc):
git clone https://source.denx.de/u-boot/u-boot.git
cd u-boot
make turris_omnia_defconfig
CROSS_COMPILE=arm-none-eabi- make tools -j8
@mbehun I think there is a much more low-level problem I have. I can’t even upload the boot image header, and I think it is because of the DDR training problem and watchdog kicking in earlier than the upload finishes. I’m not even sure what good would the boot image be if DDR doesn’t work. So I first need to get the DDR working. The transfer speed setting for kwboot doesn’t affect the header upload speed, that’s always 115200.
I have access to JTAG programmer acting as either ST-Link or JLink. If there is a way to fix the boot problem using that, please send me the instructions.
@peci1 The DDR does not need to work (and never works) when the first part of the image (U-Boot SPL) is uploaded over UART. It is uploaded into cache. That first image then trains DDR, and afterwards the second part (U-Boot proper) is loaded into RAM.
The default MCU watchdog timeout is 120 seconds. If you can’t upload even the first part of the image within 120 seconds, then something is seriosly wrong with your UART connection.
I tested with two different USB-UART converters from different manufacturers. Both work exactly the same way. But I agree this is weird because the speed is 115 kbps and the header is ~180 kB, so it should get uploaded in ~12 seconds. I see the “progressbar” consistently growing, but apparently, it is too slow. Do you know what do the various signs in the progressbar mean? (., +, E (this one’s for error)).
