3 ms·

Then you're misinformed. :) Eg. RPi 5 didn't have mainline Linux support for a very long time after launch and it's still very barebones and was not even submit

by megous 2y ago

Then you're misinformed. :) Eg. RPi 5 didn't have mainline Linux support for a very long time after launch and it's still very barebones and was not even submitted by RPi foundation or whatever, but by Suse employee.

CursedSilicon 2y ago
Pi and mainline kernel support has been a thorn since the OG Pi. Usually they get barebones support and then drip-feed in patches from folks who can be bothered enough to upstream it The Pi foundation meanwhile just has the `rpi-kernel` fork on github and pretends nothing is wrong with doing it that way
geerlingguy 2y ago
Just a nit—Raspberry Pi often works with vendors and outside contractors (with funding and engineering support) to upstream various parts over time. For example, Igalia is officially partnered with Raspberry Pi to work on Mesa drivers which are in 6.13[1]. I don't think Raspberry Pi has as much priority on pushing everything into 'mainline' ASAP, but less than two years after launch, some things are there. And unlike many Arm vendors, at least Pi engineers assist with the efforts (e.g. [2]) even _5 years_ post-launch. Besides that fact, Raspberry Pi has the resources to maintain their patches against current and future LTS branches, meaning you can run their fork at 6.6, 6.12, 6.13, and beyond, which is handy in terms of broad hardware and feature support. 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. I am extremely hopeful Cix (and Radxa, to some extent) is pushing to get things in mainline more quickly. But until it starts happening at a rate better than other Arm vendors, I won't give a gold medal to them yet :) [1] https://www.phoronix.com/news/Igalia-Raspberry-Pi-3D-Opts https://www.phoronix.com/news/Igalia-Raspberry-Pi-3D-Opts [2] https://github.com/lategoodbye/rpi-zero/issues/43 https://github.com/lategoodbye/rpi-zero/issues/43
- megous 2y ago
  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.
  - geerlingguy 2y ago
    Indeed, though ironically, just today Oleksii Moisieiev posted a patchset to add the Pi 5 to u-boot :D https://lists.denx.de/pipermail/u-boot/2025-February/579540.html https://lists.denx.de/pipermail/u-boot/2025-February/579540.... Though from informal conversations with some of the Pi engineers, it seems like they're typically more involved in Yocto/buildroot, and their own tool https://github.com/raspberrypi/pi-gen-micro https://github.com/raspberrypi/pi-gen-micro (not saying it's better or anything, but they do have a lot of engineers who come from Broadcom... they are a bit different!).

by megous 2y ago

CursedSilicon 2y ago

Pi and mainline kernel support has been a thorn since the OG Pi. Usually they get barebones support and then drip-feed in patches from folks who can be bothered enough to upstream it The Pi foundation meanwhile just has the `rpi-kernel` fork on github and pretends nothing is wrong with doing it that way

geerlingguy 2y ago

Just a nit—Raspberry Pi often works with vendors and outside contractors (with funding and engineering support) to upstream various parts over time. For example, Igalia is officially partnered with Raspberry Pi to work on Mesa drivers which are in 6.13[1]. I don't think Raspberry Pi has as much priority on pushing everything into 'mainline' ASAP, but less than two years after launch, some things are there. And unlike many Arm vendors, at least Pi engineers assist with the efforts (e.g. [2]) even _5 years_ post-launch. Besides that fact, Raspberry Pi has the resources to maintain their patches against current and future LTS branches, meaning you can run their fork at 6.6, 6.12, 6.13, and beyond, which is handy in terms of broad hardware and feature support. 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. I am extremely hopeful Cix (and Radxa, to some extent) is pushing to get things in mainline more quickly. But until it starts happening at a rate better than other Arm vendors, I won't give a gold medal to them yet :) [1] https://www.phoronix.com/news/Igalia-Raspberry-Pi-3D-Opts https://www.phoronix.com/news/Igalia-Raspberry-Pi-3D-Opts [2] https://github.com/lategoodbye/rpi-zero/issues/43 https://github.com/lategoodbye/rpi-zero/issues/43

megous 2y ago
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.
- geerlingguy 2y ago
  Indeed, though ironically, just today Oleksii Moisieiev posted a patchset to add the Pi 5 to u-boot :D https://lists.denx.de/pipermail/u-boot/2025-February/579540.html https://lists.denx.de/pipermail/u-boot/2025-February/579540.... Though from informal conversations with some of the Pi engineers, it seems like they're typically more involved in Yocto/buildroot, and their own tool https://github.com/raspberrypi/pi-gen-micro https://github.com/raspberrypi/pi-gen-micro (not saying it's better or anything, but they do have a lot of engineers who come from Broadcom... they are a bit different!).