An intermediate bootloader would be installed into the kernel partition, merely chainloading the real (bigger) kernel from another place, this does not touch the OEM bootloader in any way and reinstalling the OEM firmware just takes the normal push-button tftp recovery route. This is one option, not the only one, not the easiest one to get working but probably the only one which could account for future kernel growth.
...and unless a fix gets commited soon, very soon, there is every reason to be realistic.
Worked fine for default on a rpi4b. But back to the last stable release for my imagebuild. To many packages not ready for fw4 yet. I'll wait till 22.03.x is stable.
DSA on upstream Linux kernel lacks using multiple CPU ports to control switch ports. There was a patch series circulating around which would make it possible to map a switch port to a certain CPU port but it wasn't found acceptable by the kernel maintainers. I don't know if there's any OpenWrt-specific effort to support it.
There was an effort to map a switch port to a CPU port on the go using iproute2, which we would no longer have to define bindings on the devicetree, but I don't know the current state of it.
Well then there is no real point splitting wan and lan hardware on single port devices or multi port devices (just simply make a single bridge of everything) since all the data must be routed and tagged with vlan and every bit of data goes through the same single Gbit port to the CPU on a full duplex line working at about half speed anyway.
That's about right! This is what I advise on the Converting to DSA page I wrote.
Even if we had a port directly connected to the CPU (this is possible on the mt7621 SoC), let's say the wan port, it still wouldn't matter if we were to put it in the same bridge with other switch port interfaces. If you want to do VLAN filtering on all of the interfaces, you put them all in the same bridge. wan and lan interfaces will still have 2Gbps access to the CPU in total.
There's also this feature called bridge offloading. Most DSA subdrivers implement this. The only one I know that lacks this is the rtl8365mb driver. What this feature does is it offloads traffic between switch ports. Forwarding frames between switch ports will be offloaded to the switch hardware so they don't go through the CPU and exhaust the link to the CPU. This may also save a bit of processing power but don't quote me on that.
However, this is only useful for switching frames between LAN ports (what makes a LAN port is completely up to us). We usually need to route wan traffic so we need to have the CPU involved, in other words, have those packets delivered locally.
I have a WRT1900ACSv2 running OpenWrt 22.03.0-rc4 with a few configuration optimizations, and honestly I am extremely pleased with this build's performance! Thank you developers! Other builds have felt tenuous at best, but I feel like I've finally struck gold. Looking forward to the continued refinement with future RCs. Well done.