Petition to speedup the process of upstreaming Omnia support to OpenWrt

Considering there are some issues on the software side, when it comes to different packages and supporting various functions, not to mention wireless performance issues I think it would be best to give the users a choice to use clean OpenWrt firmware and generic kernel with Omnia support. What is the holdup on upstreaming the support?

13 Likes

I don’t think there’s any restriction for that, anyone should be able to flash just normal wrt image.
What makes Turris from OpenWRT is dynamic update for software and security features. Turris positioning itself if not as home security appliance then apparently as security hardened home appliance.
So if you don’t need those treats - you can just flash a custom built image.

But there is no support for Omnia yet in regular OpenWrt

1 Like

Ah right - the kernel. Mainline seems to be only armada 370 capable.

+1000 standard openwrt/lede

4 Likes

i can help with testing if support is added
BTW: Armada 385 support patches are here:

Don’t know guys why you would use rather OpenWRT than TurrisOS, which benefits for example: updater-ng, automatic update(s), Foris UI, Knot DNS with DNSSEC, Majordomo, uCollect & Firewall & SSH honeypots [statistics from Turris.cz] and so on.

Trust me support from CZ.NIC will improve over time, because right now they’re overwhelmed.
You can help them if you want rather than upstreaming Omnia to OpenWRT.

It needs time. They prefer manufacturing of our beautiful peace hardware like Turris Omnia is.

On the other hand:
I don’t have any wireless perfomance issues (I have connection 200/20 and which is also get from wifi AC). I see here a lots of issues about DNS. Did someone here already try to contact CZ.NIC?
And also I can see that guys from CZ.NIC are responding here.

The more support for omnia there is upstream, the less work for CZ.NIC and the more they can focus on Forris, auto-updates and other pieces like the OpenVPN GUI and knot. I see no contradiction in supporting Omnia upstream.

The smalle the diff from upstream to omnia, the better it is for CZ.NIC, isn’t it?

I would rather not switch to OpenWRT, because I like the auto-update function. I would even pay a small subscription fee for using the auto-update service.

1 Like

@maurer there are much more changes than just those two files, for example: https://github.com/CZ-NIC/turris-os/commit/992fd7dcfcf34997dbb8e6704382f2f7e6f129e1#diff-95fe863dcc2e6442652e40b702708ae8

Any news about upstreaming the support for Omnia to OpenWrt/LEDE?

I’m hoping this becomes a reality. I not really fond of automatic updates. My kernel was auto-updated the other day, but the kmod-wireguard package was not --leaving my wireguard tunnel in a broken state. Given the potential for things to break, I’d rather handle updates myself. Plus, I don’t like having tons of packages pre-installed that I’ll never use. I just want a minimal image that I can manage myself. I can help with testing if someone puts out an image.

It would be indeed kind of a relief, if Turris team would give us a script which we could choose to delete the packages that we do not want to install.

For example, packages A,B,C i do want, but F,G, X, Y, Z i do not.

So each time we get a Turris update, some auto-reference to that script that is run after the update is done. Which could be translated as…

Turris update in progress…Turris update completed…executing script…(packages F,G,X,Y,Z) being removed.

Somewhere I read that it should be soon that we can remove packages, we don’t want :slight_smile:
We can now sit tight and wait.

1 Like

You can disable the automatic updates from Foris UI.

What other files differ? Maybe I’ll try compiling it for Omnia when I have some spare time. What else is needed to support the hardware?

So far I see:

Are you sure this one is really needed? It says Turris Lite all over the place?!

Turris Omnia was initially called Turris Lite and that is an early commit adding support for it, so in this commit the old name is still used, however, if you check current versions of files modified in this commit you see it says Turris Omnia. These files are certainly needed. I have already tried compiling OpenWRT with the changes from turris-os source but I must’ve missed something as it did not work. To be specific it did not include the kernel in the image, despite proper setting, so I gave up.

Trying to build LEDE, here is my progress so far:
https://github.com/lede-project/source/compare/master...danrl:omnia

Suggestions? Mistakes?
Can anyone help me with mvebu/images/Makefile? Not sure how to patch this one.

only a crude hack for now (builds a medkit for flashing via usb drive):

diff --git a/target/linux/mvebu/image/Makefile b/target/linux/mvebu/image/Makefile
index 8b203a4122..9d41a473a9 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -28,6 +28,18 @@ define Build/clearfog-bundle
        gzip -9n -c $@.new > $@
 endef

+define Build/medkit
+       rm -f $@.new
+       mkdir -p $(TARGET_DIR)/boot
+       cp -f $(dir $(IMAGE_KERNEL))/$(notdir $(IMAGE_KERNEL)) $(TARGET_DIR)/boot/zImage
+       cp -f $(dir $(IMAGE_KERNEL))/$(notdir $(IMAGE_KERNEL).dtb) $(TARGET_DIR)/boot/dtb
+       $(TAR) -cp --numeric-owner --owner=0 --group=0 --sort=name \
+               $(if $(SOURCE_DATE_EPOCH),--mtime="@$(SOURCE_DATE_EPOCH)") \
+               --file=$@.new -C $(TARGET_DIR)/ .
+       gzip -9n -c $@.new > $@
+endef
+
+
 # SD-Card Images:
 # these values are optimized for a 4GB labeled sdcard that actually holds 7744512 sectors of 512 byte
 # MBR:            2048 sectors
@@ -64,6 +76,18 @@ define Device/Default
   SUPPORTED_DEVICES = $$(DEVICE_DTS)
 endef

+define Device/turris-omnia
+  KERNEL_INSTALL := 1
+  KERNEL := dtb | kernel-bin
+  DEVICE_TITLE := Turris Omnia
+  DEVICE_DTS := armada-385-turris-omnia
+  BOARD_NAME = turris-omnia
+  IMAGES := medkit.tar.gz
+  IMAGE/medkit.tar.gz := medkit
+  IMAGE_NAME = $$(IMAGE_PREFIX)-$$(2)
+endef
+TARGET_DEVICES += turris-omnia
+
 define Device/UBI
   IMAGES := sysupgrade.bin
   IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata

@miska, I found a lot of patches for 4.4 and wonder if they are going to be upstreamed to Linux kernel. If not, may I try to upstream this or that so that we don’t have to ship this large patchset with LEDE?

Looks not that bad, @nerdpunk! Thanks for sharing. Mind sharing the rest of your changes, too? Are you using the same patchset as CZNIC?