undefined | Better HN

0 pointsmrandish4d ago0 comments

> to help us polish RK3576 support

Having a few various RPi's (as one does), when they've been out of stock, I've looked into the huge variety of similar SBCs (OrangePi, etc) which can be even faster, with more ports and features for around the same money as an equivalent RPi. Many are powered by various RockChip SoCs, which extend up to desktop replacement-level, but the Linux driver support is usually lacking in some important way.

It's not Linux's fault, it's a small group of volunteers struggling with little manufacturer support or documentation. I don't get why RockChip doesn't budget the money in the business plan to fund full driver support for at least some of their more capable chips. I guess maybe too many of these chips are used in non-OS contexts to be worth it?

0 comments

monocasa4d ago

> I don't get why RockChip doesn't budget the money in the business plan to fund full driver support for at least some of their more capable chips. I guess maybe too many of these chips are used in non-OS contexts to be worth it?

They have drivers in most of these cases; at a bare minimum the silicon was tested by the DV teams, and that generally includes running drivers.[0]

The issue is getting drivers upstreamed rather than just languishing in the vendor BSP.

And the answer for why they don't get upstreamed by the vendor is multifaceted. First off, the drivers in the vendor BSP are simply not at a quality level that would be accepted upstream. On top of that, even if they were at the quality needed, practically that coordination with upstream is a decent amount of work. Additionally, their customers don't really even care about upstream in the vast majority of cases, but instead prefer some vendor outdated fork billed to them as "stable".

[0] Apple for instance is rumored to have an internal Linux distro (or at least kernel fork) for DV of their Apple silicon chips to allow the hardware teams and macos teams to work with fewer cross department dependencies.

Y_Y4d ago

> First off, the drivers in the vendor BSP are simply not at a quality level that would be accepted upstream.

You're quite right, morally and practically. I can't help but wonder though, if the like of Rockchip or other big faceless chipmakers released whatever inadequate source they had, that it wouldn't somehow end up in a nice upstream high-quality driver.

duskwuff4d ago

The source is available [1]. The problem is that it's an unmerged fork of the 6.6 kernel.

[1]: https://github.com/rockchip-linux/kernel

jmole4d ago

I've had the same frustration with rockchip, but if you search the lkml you'll find that they are indeed trying their best: https://lore.kernel.org/lkml/?q=rock-chips.com

the biggest issue is that actually contributing to upstream is an *incredibly* difficult and painful process.

greatgib4d ago

Maybe also because they don't release proper specs?

jmole4d ago

Silicon is a dog eat dog game. You release too much and you get sued for patent infringement by NPEs or competitors copy your designs and run with them. There is basically no upside unless you are running a charity like Raspberry Pi.

Margins are incredibly thin unless you're on the bleeding edge. It's not an easy business. You need to move millions and millions of chips to make a profit, and that means your FAEs are working directly with companies who are actually paying you for chips instead of trying to write perfect documentation for the open source community.

j / k navigate · click thread line to collapse

0 comments

monocasa4d ago

They have drivers in most of these cases; at a bare minimum the silicon was tested by the DV teams, and that generally includes running drivers.[0]

The issue is getting drivers upstreamed rather than just languishing in the vendor BSP.

Y_Y4d ago

> First off, the drivers in the vendor BSP are simply not at a quality level that would be accepted upstream.

duskwuff4d ago

The source is available [1]. The problem is that it's an unmerged fork of the 6.6 kernel.

[1]: https://github.com/rockchip-linux/kernel

jmole4d ago

I've had the same frustration with rockchip, but if you search the lkml you'll find that they are indeed trying their best: https://lore.kernel.org/lkml/?q=rock-chips.com

the biggest issue is that actually contributing to upstream is an *incredibly* difficult and painful process.

greatgib4d ago

Maybe also because they don't release proper specs?

jmole4d ago

j / k navigate · click thread line to collapse