5 ms·
This is a common story in ARM / embedded linux. SoC vendors’ main focus is to make the chip and give it enough BSP support for customers to buy it and build the
by mafuyu 3y ago
This is a common story in ARM / embedded linux. SoC vendors’ main focus is to make the chip and give it enough BSP support for customers to buy it and build their products around it. The bare minimum for this is typically a set of hacky kernel patches targeting a giver kernel version.
The customer then needs to figure out what they want to do: Take the kernel blob as-is? Get the vendor’s kernel source and try and modify it for their specific needs? Rebase it to a newer kernel? The customer typically wants to just get enough support to ship their product; they’re not in the business of maintaining some other company’s kernel patches. They’ll do it if they have to, but the engineers will grumble about it the entire time.
Thus, getting support landed into Linux upstream is primarily the task of the chip vendor. There’s a good business case for it, as better and widely available software support will help sell the chip. But it’s also incredibly expensive to write all that kernel code and take it through the process of upstreaming. A lot of this stuff won’t meet the standards of the Linux kernel without lots of work.
The ARM SBC market flips this, where you have a bunch of enthusiasts, and then a smaller market of businesses wanting to use them in their products. That can provide enough momentum for a community-driven upstreaming effort.
- MichaelZuo 3y ago> A lot of this stuff won’t meet the standards of the Linux kernel without lots of work. Can you elaborate on this? I never got the impression that 'the standards of the Linux kernel' were some incredibly high bar.
- cmrdporcupine 3y agoHow does questionably formatted, badly documented, insufficiently tested, and full of Chinese comments sound? That's what I've come expect from this space. In general, it's the usual: China, great at hardware... software an afterthought
- MichaelZuo 3y agoWhy exactly is it so difficult to polish it up, document it properly, and translate as necessary, that it can't be accomplished by a few smart engineers in a few months?
- mafuyu 3y agoIt's very much doable. You see the big vendors upstream proactively, and they have whole teams supporting upstreaming efforts. But chip bring-up and driver support can be messy affairs. It's not just a matter of a driver working or not- hardware bugs or weird undocumented behavior show up all the time. If customers aren't exercising some feature of the chip, bugs can and will go undetected in that module. The datasheet only gets you so far, especially for undocumented hardware quirks, and the vendor is in a much better place to understand what's happening and fix them. It's an active process of reporting bugs, investigating them, and getting fixes merged upstream into the vendor's BSP, at the very least. This requires active maintenance, which means engineers on the vendor side. That's where the support contracts kick in. Upstreaming to Linux on top of all that means that you actually need to support and validate the set of features your chip claims to support. That means more thorough test and validation, code that meets the standards of the kernel, and more engineers to actively maintain the code. Not to mention the language barrier for Chinese chip vendors. Of course, any upstreaming efforts are great and I think things are trending in a good direction. Just pointing out that there are reasons things are the way they are. Fabbing a chip that isn't completely buggy and people want to buy is already a small miracle- better software support can always wait until the chip becomes a hit.
- MichaelZuo 3y agoIf it's doable by a few smart engineers in a few months, assuming there are no show stopping quirks, then that should imply the trustworthy, reliable, manufacturers get their stuff upstreamed, by whomever, and the unreliable ones don't.
- kop316 3y agoHere's one example of a wifi driver for the pinephone: https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64-linux/-/blob/mobian-6.6/debian/patches/wireless/0084-8723cs-Add-a-new-driver-v5.12.2-7-g2de5ec386.2020101.patch?ref_type=heads https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64... The diff is 13.4 MiB and is over 200,000 lines long. It includes it's own AES and SHA-256 engine. Trying to polish this up would be close to years, and a good kernel dev is not cheap.