While this is all true, this is not unique feature of Raspberry Pi / foundation. Rockchip does work on mainlining support for some of their SoCs into various p

While this is all true, this is not unique feature of Raspberry Pi / foundation. Rockchip does work on mainlining support for some of their SoCs into various projects. Recently they finally got their TF-A support merged for RK356x and RK3588. They also have people on staff maintaining U-Boot and reviewing Linux patches and doing some upstreaming. Some companies that make boards also fund upstreaming via third parties like free electrons/bootlin/collabora/paid individuals, or donate HW and/or funds to projects like Armbian or again to random individuals who show interest (which is Pine64 modus operandi, I guess), or do it themselves. And then, there are seemingly independent developers (on the HW/SBC manufacturer) doing sometimes very significant development for personal or other reasons (to have some well working HW for their SW projects - routers, or media center software like libreelec comes to mind) End result is that quite a lot of boards end up having good quality upstream support not very long after launch these days, as a confluence of all these factors. And having resources for maintaining out-of-tree patches becomes irrelevant. > For years many Rockchip SoCs were stuck at ancient 3.x, 4.x, 5.x kernel LTSes, which made a lot of use cases quite difficult. That may be true if you only look at Linux provided via BSP, but there are Rockchip SoCs that are well supported in mainline Linux for many years, like RK3399 (because of strong push from Google to get it upstreamed). Other thing now, is that there's such a critical mass of say Rockchip/Allwinner related drivers upstream, that adding almost fully working support for a new SoC that had no support upstream, is sometimes attainable even for individuals who have a weekend or two of time to give to the project. Eg. here is me porting Rockchip RV1103/1106 SoC support over the current mainline https://codeberg.org/megi/linux/commits/branch/luckfox-6.14 https://codeberg.org/megi/linux/commits/branch/luckfox-6.14 and adding a few boards on top. Except for CRU driver, it's mostly just light changes to existing drivers. So these days for some simpler SoCs you don't even need vendor support, or rely on anyone, and can just port it yourself based on released BSP code in a few days. Super complex SoCs like RK3588, featuring a lot of new IP blocks of course take longer time and larger cooperation, but now, at similar [to rpi5] time after launch, there's very nice U-Boot support for booting via anything that the SoC can offer, fully opensource TF-A, and my Orange Pi 5 + supports GPU in kernel/mesa, dual HDMI output, PCIe, and pretty much all of the onboard features + working suspend to RAM, and this will only get better. So RPi having resources for maintaining their out-of-tree patches will be more of a burden to them, eventually, because you'll be able to use many boards with generic distro kernel, while RPi will become an exception requiring some special handling and custom kernel. It's already an exception in my world, where pretty much everything I have uses U-Boot, except for RPi which has to be it's own weird thing.