Upgrading from WRT1900ACS to Turris Omnia. I build my own OpenWrt and I have lots questions

General discussion
1

I just bought a Turris Omnia as an upgrade from Linksys WRT1900AC v1.
I build my own OpenWrt from latest sources and I have lots of questions about my new Turris Omnia. I hope to meet many enthusiasts and tinkerers here to discuss improvements to this router.

Before I bought Omnia, I briefly tried a WRT1900ACS which is almost indentical, but the mwlwifi was unusable and the wifi is not on separate cards like WRT1900AC v1, so I sold it. I still have my WRT1900ACS branch and I tried to use that as a base for Omnia build.
I found out that there are still some significant differences, not all for the better. I’ll use this topic to discuss all of them instead of opening topics for each one. I will keep them numbered.

1) Dual boot / dual firmware

As an enthusiast OpenWrt user, I like to test lots of modifications to OpenWrt. Inevitably, some of them are bad. I really liked the dual firmware layout of WRT1900-series. It was nice to have a known stable firmware to go back to, when I make a mess with a new kernel and the rest of the family want internet access.

WRT1900 splits the large mtd into partitions using dts and ubi volumes, while Turris Omnia uses a very small mtd for uboot and a large emmc for kernel and rootfs. Is it possible to configure OpenWrt to create the dual firmware layout on emmc ordinary partitions? I looked around in both menuconfig and sources, but I can’t see the option.

As an alternative, I could enlarge the boot partition (mmcblk0p1) to hold two kernels (testing kernel and backup kernel), manually partition and format the second partition (mmcblk0p2) and create 2 btrfs volumes (testing rootfs and backup rootfs), then I could edit uboot scripts to load one kernel or the other as needed, each with it’s btrfs subvolume in rootflags. With this configuration I could update OpenWrt by manually copying rootfs files into the btrfs subvolume and the kernel into boot partition.

2) Is TurrisOS better?

I briefly looked at TurrisOS at gitlab. I noticed that it’s basically a wrapper around OpenWrt buildroot with a new package feed. I was expecting a fork instead, with patches, lots and lots of patches. I found the patches, but I’m confused how they apply. For example, this patch does not match the source file from OpenWrt main branch since 2023-06-01.
On the other hand, I see something about omnia-mcu ability to power off the system. This is not in OpenWrt main branch. The front GPIO button is also not in OpenWrt and not in mainline kernel.

How should I combine the best from each? Can I just take patch files from TurrisOS patches/openwrt/, put them in the OpenWrt target/linux/mvebu/patches-6.1/ and make target/linux/prepare to test them?

3) Missing drivers

a) I see a ATSHA204A devicetree node added 2 years ago, in kernel 5.19, but it’s not in TurrisOS 6.5, not even as a backport. Is it actually present on the board? How does it compare to mvebu-cesa?

b) turris-omnia-ctrl devicetree node needs some out-of-tree kernel driver, which is in /patches/openwrt/a-new-kernel-5.15/0019-mvebu-patches-5.15-Backport-Turris-Omnia-MCU-support.patch. Is this compatible with kernel 6.1? Why wasn’t this added to upstream OpenWrt while it was still using 5.15 kernel?

c) About the front button (again). I see it defined as gpio-keys in the devicetree, but it acts on led intensity even when kernel not loaded. That means it is not a gpio button. I’m confused. What’s needed for this button to work in OpenWrt for custom actions? Just the devicetree node, or is there something else?

d) SPDIF audio sound card was added in the linux devicetree 2 years ago (6.1rc1). Did anyone try it? Does it actually work?

4) Hardware mods and addons
Did anyone try to add a SD-card reader/module to gpio header? It seems to have all the needed pins.

Thanks for reading.

4 Likes
2

3a) Atmel SHA204A driver only implements RNG from the chip. I tried to add it, but it reports

atmel-sha204a 6-0064: failed to read clock-frequency property
atmel-sha204a: probe of 6-0064 failed with error -22

So, what is the clock frequency of this chip?

3

3f) Frequency scaling
I remember that WRT1900ACS had frequency scaling. It doesn’t seem to be available in OpenWrt kernel 6.1.

4

You should not ask yourself if something is better than the other because it simply does not work like it. Turris OS is based on top of OpenWrt with its specific patches and its own feed. OpenWrt targets being minimalistic, but some features are disabled and not optimized for big devices. Turris OS uses OpenSSL by default, BTRFS as a file system, then it provides automatic updates on the fly, it has Turris Sentinel, dynamic firewall, etc. These are quite interesting features, and if you notice, their oldest router - Turris 1.x, which is more than 10 years old- is still supported and has new features. Even though Turris (ehm… CZ.NIC) employees are doing what they can, there are just a few guys there, and many knowledgeable guys, including me, have left, and that’s life. It just works like that. That’s the reason why the development almost stopped, and that can be seen on their GitLab. There are currently, if I am correct, three packagers, and no one is fully dedicated as a full-time employee only to the Turris distribution. Turris OS is still a lot behind in the OpenWrt versions. The current stable version is still based on OpenWrt 21.02, and it speaks for itself (End of Life version, vulnerable, outdated, etc.).

In the past, Turris OS was forked. It was in the beginning, but from my point of view, it was a dead end. You might look at what happened with Turris OS 3.x Just look at how other vendors are doing it. They fork their sources and they did not contribute to upstream. What happened? You are getting a maintenance burden, customers are complaining about outdated versions and kernels, and why it is missing features when it is working in upstream. You need to follow upstream development and be sure that it works. Isn’t it better when vendors are cooperating with the upstream? :slight_smile: In the long continuity, patches and its feeds do make sense. You don’t play on your own playground, but with the upstream community you can work side by side and help each other, which results in the shape, where Turris is. On my watch, I contributed daily to the OpenWrt. Even though it was not easy, I figured it out and thought it all made sense. It’s the way how it should be. You can see that if it is missing upstream, it is missing downstream as well. It gets updated upstream, and then downstream gets it in a timely manner. This leads to you supporting only what you developed and created and everything else is an upstream problem, not ours.

I need to admit that OpenWrt does not release new versions very often, and you rely on opkg upgrade, which OpenWrt says to avoid using it on their forum.

Unfortunately, it won’t work like this. In the best world, it would, but because of the lack of Turris maintainers and the fact that they also stopped working upstream, it is hard to do it. This is explained in WORKFLOW.adoc · hbk · Turris / Turris OS / Turris Build · GitLab and to sum it up:

  1. You need to be careful about which patches you are looking for. It is important to choose the right branch.
    HBK and HBL is OpenWrt 22.03, HBD is OpenWrt 23.05
    Everything is based on kernel 5.15.
  2. You need to rebase several patches; you need to be sure that it works.
    Then, also resolve merge conflicts, etc.

It sounds like an easy job to do, it is, but don’t be mistaken. :slight_smile: Turris kernel developers have been working and improving support of Turris routers in the Linux kernel, so it should run with vanilla kernel, but regarding Turris and its OpenWrt patches, it will take some time to make sure that it compiles, that it runs and that it is tested. Basically, if kernel 6.1 is enabled for the mvebu target in OpenWrt, then it should take just a few days to switch to it except for specific (downstream) patches like Turris SFP when patches do not apply, and the code changes a lot. Then Turris Kernel guys should step in.

Since we know somehow each other from OpenWrt packages feed, I tried to share my thoughts from developer perspective.

4 Likes
5

Thanks for this generous reply.

I am not aware of Turris/NIC.CZ internal organization and politics. I just commented on what I saw. BTW, I don’t see much activity on the forum either.

Do you think they would mind if I do some PR to OpenWrt with some of their improvements? Or do they prefer to do it themselves?

I did read the workflow doc, but I couldn’t find the hbd branch, so I looked mostly at the hbl branch. Here’s what I found so far:

3b) I did manage to separate the mcu patches. It was actually a simple job; only one conflict. I think I got them all, probably. Link. OpenWrt built OK with them and it’s booting. There’s a kernel message that I should be updating MCU firmware, but there’s no tool for that in OpenWrt and my build is so far hacked-debloated-patched-and-hacked-again that I doubt the binary from Turris will work. I probably need to flash TurrisOS, update MCU, then back to OpenWrt. After that, well… I’m not exactly sure what I should be testing. Poweroff? Leds? I never actually used TurrisOS and I probably never will, so I have no ideea how it should work and what it can do. Maybe some old TurrisOS user that knows it’s functions best may be able to guide me.

3a) Another thing that I did was add some clock-frequency to the I2c node where atsha204a is connected. Link.
According to the specs, max supported is 1MHz. I used 100KHz and it appears to be working:

  • No more kernel error, but no success message either.
  • It appears in /sys, both in i2c bus and in hw rng as the current rng.
  • I have no ideea how to test that it actually generates entropy.
  • As a note, I have an Atheros wifi card installed that also has a hw-rng function. That might be a source of confusion.

Note that I didn’t open any pull requests. If the MCU driver gets merged into OpenWrt and it fails to build with a newer kernel, there no way I could fix it. My knowledge of C is very limited.

6

The MCU can do a few things - power off the router, shut down power for each USB separately, set the LEDs brightness and color “calibration”, plan to power on the router on a specified time. That’s basically it.

The tool that handles it is Turris / omnia-mcutool · GitLab .

7

Wow, these are words of wisdom, @Pepe :slight_smile: Wish every vendor shared this view =)

8

@M95D regarding the Atmel SHA204A chip, the random number generator in that chip is highly questionable.

One of the things I recently implemented is TRNG provided by the microcontroller, for which I have also prepared driver both for U-Boot and Linux kernel. Stay tuned.

3 Likes
9

@mbehun: Thanks for the info.

What I did today:

  • added TurrisOS package feed to my OpenWrt. It’s a mess. Lots and lots of errors. I got some of the packages to build, but I don’t consider this a success.
  • nor-update works… probably… it’s kind of hard to tell with those confusing output messages
  • MCU Tool works:
    • updated firmware
    • kernel warnings are gone
    • led commands work (but who uses a binary when there’s /sys/class/leds/ ?)
    • led intensity is NOT remembered after a reset (Is this normal? I was expecting it to be saved somewhere.)
    • button function switch appear to work, but there is no default function for it in OpenWrt (or there is, but doesn’t work)
    • button function is also NOT remebered after a reset
    • gpio status appears ok
    • “halt” powers off the router
    • timer wakeup works
    • didn’t test the watchdog

Next to do:

  • separate mcu tool from everything else and add it to my personal feed
  • search the devicetree for the missing cpu frequency scaling
  • test msata with a passive msata-sata converter and a DAS (direct attached storage) with port multiplier
  • investigate how turris uboot and recovery are built
  • make a better recovery, because this one doesn’t even have lsblk
10

@M95D

  • TurrisOS packages are currently not being developed under master branch of OpenWRT, so that is probably the reason for that many errors
  • LED intenstity should be remembered through light reset (MCU firmware does not reset), but won’t be remembered after hard reset. This is intentional, as I do not want to store such settings in MCU flash memory, because
  • button function is not remembered even through light reset. The idea was for the OS to hold the configuration in /etc/config settings and configure it during system initialization (note that the in-development turris-omnia-mcu kernel driver allows to do this via sysfs)
  • omnia-mcutool and MCU firmware are WIP to be added to upstream OpenWRT
  • as far as I know, there is no CPU frequency scaling driver for Armada 38x, so adding scaling tables to device-tree won’t help you
  • regarding how U-Boot is being built, you can look at Makefile in TurrisOS packages repository. Note that this Makefile just uses the package/boot/uboot-mvebu basis from upstream OpenWRT, but with some patches added on top of that. You can also build upstream U-Boot with turris_omnia_defconfig. There are some patches being in development, though, and some are still pending on the mailing list.
  • regarding rescue-image, you can look at rescue-image package. This is always built, but normally the built binary is experimental. Sometimes we test the built binary to see whether everything works as it should and then declare it stable.
11

Thank you for the info.

I saw that the with MCU driver pull request conversation ends with a note that is “work in progress”, but the pull request is open. So, is it good to use, or is it still work in progress? I dropped Turris feed from my repo and used this PR instead. It needed some conflict resolved, but other than that, it looks fine to me.

I’m a bit dissapointed that there is no frequency scaling. It really made a big difference in temperatures on WRT1900AC (Armada XP, about 20C between idle and full load), especially since idle driver is marked as defective too. Since this chip is so old there is no hope it will ever be added.

This week I tried to get two wifi cards working: Atheros AR9287 and AR9832. Eventually they worked, but the kernel must not have PCI-E ASPM included and PCI-E MPS setting must be set to “default”. No other settings will work.

atsha204a works at 1MHz too. Low quality randomness is better than no randomness.

12

3c: there is a STM32F030R8T6TR (U21) to control power and LEDs. Firmware is in omnia_hw_ctrl.