Turris Omnia 2019

This is true. Then I too disagree with the affiliation to a VPN which is the stupidest thing in the world in that sense. But a piece of hardware remains that and you can install OpenWRT stock. Then it is clear that an amd64 APU is no different from a 32-bit or 64-bit Marvell ARM. But these also sell routers with an Intel i7 processor. Then it's just an example. There will be another thousand stores or a thousand ways to create your own device. However I contacted them and they are extremely available.
Mine is not a suggestion for purchases, it's just an example. And then have something to install the blessed OpenWRT without biting the world or having 90% less potential.

1 Like

Which is introduced with kernel 5.4 and will probably not make it into the OpenWrt stable branch for many months to come, perhaps even years (seeing how the 19.07 branch currently goes and the 5.4 kernel not yet being introduced in the Master branch)


The limitations of the device's CPU, controlers and board buses are known but still outclass most of the other devices that are supported by OpenWrt.

At some point OpenWrt may not even be the best distro choice for the device considering that the distro is trying to support as many devices under one umbrella (efforts to support device with scarcity of hardware resources) and not being sufficiently diverse to unleash the full potential of the TO.

Whilst the TO probably still falls within the classification of a SOHO device it is already hovering on the edge of industrial grade equipment and for such other distros are better suited.

Unless there will be significant development with embedded boards, controllers and CPUs such devices will not meet the performance of what is today's classification of industrial grade equipment.

Considering that multi-homed and/or 1Gb/s+ WAN connectivity are being introduced to SOHO subscribers it will require hardware in SOHO devices to match the subscriber line capabilities, hardware that today is considered industrial grade equipment.

That may be an exaggeration given that it's already being tested out in Koen's staging tree – https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary
As well as David's – https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/k54
And Christian's – https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=summary

They're aiming to get things moved into Kernel 5.4 for v20.07 – so perhaps, just months.

I myself has made a half attempt at porting 5.4 to mvebu but only for Linksys WRT devices (cherry picking Koen's commits). Haven't compiled it yet though.

This would only be enabled for those using software buffers on RX for mvneta. OpenWrt's mvebu (often paired with Marvell switches given that they're from the same company) kconfig uses hardware buffer management by default on RX.

I don't really know of any consumer/retail hardware that ever pairs an mvneta switch with anything other than an Armada CPU in OpenWrt's build system.

What's more is that I don't know of any public testing going on where swconfig is paired with XDP. I think it's only ever been tested with DSA. I have not heard of any plans whatsoever for OpenWrt to switch to DSA, even in their 2020 roadmap.

I genuinely think it would be more painful for OpenWrt to move away from swconfig than switching to K5.4. Just as hard as moving the project from iptables to nftables.

Will see how it pans out, 19.07 not being released now December.


swconfig is removed for the TO build and only delpoys DSA.

It is considered legacy and new switch drivers should use the DSA (distributed switch architecture) kernel framework [1]

The preferred contemporary driver architecture for ethernet switches in the Linux kernel is DSA (distributed switch architecture). [2]


[1] https://openwrt.org/docs/techref/swconfig
[2] https://openwrt.org/docs/techref/hardware/switch

For version 4.0 right? I've perused their sources in GitLab to see how they've done it – but it seems really convoluted.

Yeah it's legacy, but I haven't seen any plans or any developers assigned to oversee/manage the move of OpenWrt to DSA. I've heard chatter in that it's only because it's not as mature and that there needs to be a way to package the DSA subsystem like mac80211 backports.

Turris has a foundation backing it (I think NIC.cz?). OpenWrt is like OpenSSL. Everyone uses it – but it seems that there's no foundation or anything like that monetarily supporting it, leading to the current slow down and delays in releases and adapting to newer things like DSA and nftables. Prior to heartbleed, OpenSSL had at most two active developers who couldn't support themselves with dwindling donations.

It is not introduced by a patch in TOS (4.x+) but in the build conf for the TO in OpenWrt since 18.6x branch.

I'm sorry, I should have clarified myself. Beyond just the build, I'm talking about DSA in the overall configuration system. E.g. making/bridging VLANs and LuCI/Foris web interface.

Basically DSA support in the front-end.

http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020456.html

Till date there has been no support for VLAN conf via Foris | reForis.

(L)UCi has support for it by parsing VLAN related ip commands however lacking support for VLAN related bridge commands [3].


[3] https://github.com/openwrt/luci/issues/2798

Thanks for authoring that issue. Though I can see that netifd has become a blocker – akin to another OpenWrt homegrown utill, fw3, being a blocker for nftables adoption...

So it seems that it would be best if this be tackled by these people collaborating with each other:
Jo-Philipp Wich – LuCI
Florian Fainelli – DSA (maintainer(?)) and former OpenWrt dev
Hans Dedecker/John Crispin – for netifd

Are hardware buffers faster?

Turris Omnia uses DSA, not swconfig. The other mvebu devices need to be migrated.

Going from swconfig to DSA results in a performance decrease. Not an issue for the Turris Omnia but can be an issue elsewhere.

Moving to nftables will definitely be difficult.

edit: Speaking of those XDP changes, it seems there were other non XDP related speedups snuck in those commits.

Back before K4.9, @davidc502 was keeping a separate patch to enable hwbm for his builds for the A38x/XP CPUs in the Linksys WRT series. I believe there was a speedup. Prior to that I believe software bm was used. The patch modified the Kconfig and the dts. However, it is obviously now mainlined.

Additionally from my previous post, these are the other Kconfig macros that enable hwbm for mvneta:

CONFIG_MVNETA_BM=y
CONFIG_MVNETA_BM_ENABLE=y

I presume this is related to the fact that a "CPU" port is not being used. I still have not followed up on whether or not DSA maintainers have agreed on a way to tackle this.

That's part of it. The other part has to do with how DSA handles VLAN tagging. It results in a slowdown of at least atheros and mediatek switches.

This was made apparent in the testing of the kernel 4.19 bump of ramips. The upstream ethernet driver is slower purely because of DSA.

Mediatek in their SDKs still use swconfig for that reason.

Related: https://github.com/openwrt/openwrt/pull/2693

2 Likes

Zombie revive:

I recently hit this problem. The solution is here: https://forum.turris.cz/t/default-turris-omnia-u-boot-environment/10181/2?u=neheb

The problem is that the OpenWrt medkit file modifies the U-Boot environment in such a way that it ends up breaking things when going back to the original firmware.

It's unfortunate but I don't think the Turris people are to blame. Then again, they did not add support for the Omnia at all. That was done by another person.

With above-mentioned PR#2693 the OpenWrt medkit changes the U-Boot environment of the original Turris Omnia (not 2019) in a different way:

kernel_addr_r 0x1000000
scriptaddr 0x1800000
fdt_addr_r 0x2000000
boot_targets mmc0 scsi0
boot_prefixes / /boot
boot_scripts boot.scr
mmcboot btrload mmc 0 0x01000000 boot/zImage @ && btrload mmc 0 0x02000000 boot/dtb @ && setenv bootargs "$bootargs cfg80211.freg=$regdomain" && bootz 0x01000000 - 0x02000000; run distro_bootcmd
distro_bootcmd scsi_need_init=true; for target in ${boot_targets}; do run bootcmd_${target}; done
bootcmd_mmc0 devnum=0; run mmc_boot
mmc_boot if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
bootcmd_scsi0 devnum=0; run scsi_boot
scsi_boot run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
scan_dev_for_boot_part for distro_bootpart in 1; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_boot echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_scripts; done
scan_dev_for_scripts for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
boot_a_script load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}

This has been inspired by the default U-Boot environment of the Turris Omnia 2019, but modified to work on the original Turris Omnia as well.

The first part of mmcboot is identical to the default one, so I would expect absolutely no change in U-Boot behaviour, when going back to TurrisOS. That's the plan, at least.

If this is not your production device, would you be able to build a PR#2693 image (last force-push on Feb 23) and test a complete cycle:

  • Start with TurrisOS and default U-Boot environment
  • OpenWrt (PR#2693) medkit 4-LED flash & boot
  • OpenWrt (PR#2693) sysupgrade & boot
  • TurrisOS 4-LED flash & boot

Maybe monitor each step with the serial console.... The environment should be updated at step 3, and then stay.

This is going in production soon with TurrisOS 4. I tried putting OpenWrt master on it (as well as the kernel 5.4 bump) but it just resulted in a stalled kernel (no output). I don't really have any desire to debug it at this point.

Would you be so nice to provide some hint? I was trying to search for it but no luck so far.
Thanks.

Look here. I think the steps were:

If the U-Boot environment has been modified previously (likely manually via
serial console), first use serial to reset the default environment.
=> env default -a
=> saveenv

Ha, I think I found it. Is it this (in serial console)?

env default -a
saveenv

EDIT: ah, too late :smiley:
thank you, fantom-x

some patches where added today for XDP support on Marvel socs.