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.
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.
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.
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
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.
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.
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