Need help with upstreaming Turris Omnia

I have no experience with creating proper device support patches, and would really appretiate help with upstreaming of Turris Omnia. Even though this router comes with OpenWRT (fork), the devs are shy to submit the patch themselves.

The required sources can be found at
https://gitlab.labs.nic.cz/turris/openwrt/tree/test/target/linux/mvebu
https://gitlab.labs.nic.cz/turris/openwrt/blob/test/target/linux/generic/patches-4.4/734-phy_mvsw61xx-88e6176.patch
https://gitlab.labs.nic.cz/turris/openwrt/tree/test/package/boot/uboot-turris-omnia
https://gitlab.labs.nic.cz/turris/openwrt/blob/test/package/kernel/linux/Makefile

All this combined compiles fine with the latest LEDE snapshot.

Device details:
https://www.turris.cz/doc/en/start
https://omnia.turris.cz/en/

I will be glad to test the patch on my device.

Do you have a repo/branch with the patches applied? I started copying them over one by one a while ago and sometimes the build failed. I suggest we start a new branch and test this very well before submitting a patch.

What target image did you build? The medkit?
How well does the Omnia storage work with ext4? I heard btrfs is better suited (one of the devs said that IIRC on the omnia forum)

I own a Turris Omnia as well, but rely heavily on it. Testing capabilities are limited :slight_smile:

The most important thing to get started would be to beat the crucial turris omnia specific hardware support in state acceptable for merging, this means no special kernel/ u-boot forks. For hardware like the turris omnia (with plenty of flash, which lends itself to in-place upgrading), additional features like btrfs might be nice to have, but in the grand scheme of things those will be more difficult to merge and should be much less important (as in optional) than getting basic hardware support applied (in a way that it works and behaves just like any other LEDE router).

This is what I have: https://github.com/amq/omnia-kiss

git clone --recursive https://github.com/amq/omnia-kiss.git
cd omnia-kiss
rsync -a custom/ lede/
cd lede
./scripts/feeds update -a
./scripts/feeds install -a
make defconfig
make -j2 V=s 2>&1 | tee build.log | grep -i error

I think the uboot-hack could be a problem for upstreaming, couldn't it?

Update: The build failed for me.

I hope that it will be official support from LEDE for Turris Omnia, because I have the impression that Team Turris is not trying to help and develop the project.

1 Like

there's another lede-fork with turris omnia support - but i haven't tested any of these yet:
https://github.com/Xiche/lede-source/tree/turris-omnia

I can also volunteer for testing, at the moment my turris is not in a critical role yet.

I've got a lot of experience building custom OpenWRT images, but I'm not a programmer who is really suitable for trying to change the code to meet the quality standards of upstream.

Like slh above, I think the most important thing is to get the kernel and u-boot changes in place (along with a build target). Once that's in place, I'll happily dump the rest of the turris specific software and stick with plain LEDE packages

once we get it running, closing the other gaps will be far easier.

yes!

would also like to engage in testing to make the omnia great again :wink:

anyone know why omnia-devs wont engage in giving back to wireless freedom?

anyone know why omnia-devs wont engage in giving back to wireless freedom?

The usual issue is just that they are busy making it work for their users
(fixing issues, updating version, working out kinks in the software)

Remember, this wasn't done as a croudsourced router for the sake of doing an
open router, this is an organization who needed a router for their own purposes
(to replace prior versions they have deployed), and they decided to expand their
users and gain some funding for the project via croudsourcing. So they have
their internal needs to meet and customers to keep happy, not just us
open-source folks.

David Lang

While that is probably their reasoning, it's still deeply flawed, because with each week going by, their workload to either backport upstream (OpenWrt or LEDE) or to ignore upstream and start doing everything themselves becomes larger and larger - much larger than committing basic hardware support early on.

1 Like

I'm also happy to help with any testing and porting of packages. I'm just no good when writing C is involved.

The link above to Xiche's repo seems to contain the basic Turris definitions for the normal mvebu kernel 4.4 in a rather clear form in four commits:
https://github.com/Xiche/lede-source/commits/turris-omnia

(But I have no idea if those are complete)

I boulding medikit omnia firmware based on Xiche commits.

Image boot OK.
Port WAN not working ( I switch wan to LAN4 port)
When I connect lenovo tablet to 2,4GHz WiFi, router lost connection on LAN/WAN and wifi is down.

WiFi speed is good (tested on intel 7260ac) - ~320Mbit/s
I have omnia with standard compex wireless card.

Coping files to 3,5' disc connected to USB3.0 port - ~100MB/s
openssl speed:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 12620.89k 42010.65k 108303.62k 178323.11k 220879.88k
sha1 12976.13k 41386.43k 102654.97k 162157.08k 194570.92k
des cbc 19084.34k 19590.98k 19812.52k 19861.83k 19723.61k
des ede3 6891.92k 7025.72k 7050.10k 7083.12k 7041.28k
aes-128 cbc 39578.24k 45318.83k 47478.07k 48038.96k 47977.81k
aes-192 cbc 35366.05k 39899.29k 41873.44k 42099.07k 41913.00k
aes-256 cbc 31999.19k 35968.17k 37215.12k 37416.28k 37494.15k
sha256 16646.66k 40446.16k 74101.98k 94036.76k 101876.70k
sha512 6915.66k 27636.42k 40677.54k 56031.91k 63261.97k
sign verify sign/s verify/s
rsa 2048 bits 0.023852s 0.000618s 41.9 1617.4
sign verify sign/s verify/s
dsa 2048 bits 0.006931s 0.007409s 144.3 135.0

My changes:
https://github.com/heinzek/source/tree/omnia_new

2 Likes

it looks like you've been continuing to work on this, any updates on the progress?

Hello.
Was the topic dead?
Or Turris Omnia turned out to be a failure?

There is ongoing discussion elsewhere: