4 ms·

I don't get it. 1. Rockchip sells a chip in some boards (let's focus on one, e.g. in Orange Pi 5) 2. Orange Pi 5 has some software pre-installed (I guess linux

I don't get it. 1. Rockchip sells a chip in some boards (let's focus on one, e.g. in Orange Pi 5) 2. Orange Pi 5 has some software pre-installed (I guess linux right? even if it's android then it's still linux, right?) 3. Some people need to find out by themselves how to make normal upstream linux running on this chip Questions: A. How the system provided by Orange Pi works on the RK3588? Does it not use all the power/features? B. Why Rockchip only "suggests" how to handle problems instead of fixing it? C. Who and why created the "OEM" linux that has been installed on Orange Pi 5 for selling? C.1. Why the people who created it won't release their work into linux?

mcpherrinm 3y ago
They will ship images using a probably old kernel with various patches and drivers which may not be in suitable shape for simply including upstream. The vendor may ship this initially, but often won't work on upstreaming the changes or porting to newer kernels, so you end up with devices stuck running forks of old kernels unless somebody takes the kind of effort discussed here to upstream the changes.
- p0w3n3d 3y ago
  or unless vulnerabilities of old kernels will allow someone to take them over
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 ago
    How 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 ago
      Why 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 ago
        It'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.
cmrdporcupine 3y ago
To these companies software is just a cost centre. Their product is hardware. They want to make a lot of a thing, sell it to as many people as possible, and then move on to make the next thing they sell a lot of. The kind of thing that motivates us when we build systems doesn't necessarily motivate them. The finished software product is, in the end, your problem, not theirs. Software engineers are expensive. The more they can push off and avoid paying them, the better.
- p0w3n3d 3y ago
  thank you, guys/gals, for the explanation, that's a new plane of problems, orthogonal to what I have been experiencing so far.

mcpherrinm 3y ago

They will ship images using a probably old kernel with various patches and drivers which may not be in suitable shape for simply including upstream. The vendor may ship this initially, but often won't work on upstreaming the changes or porting to newer kernels, so you end up with devices stuck running forks of old kernels unless somebody takes the kind of effort discussed here to upstream the changes.

p0w3n3d 3y ago
or unless vulnerabilities of old kernels will allow someone to take them over

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 ago
  How 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 ago
    Why 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 ago
      It'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.

cmrdporcupine 3y ago

To these companies software is just a cost centre. Their product is hardware. They want to make a lot of a thing, sell it to as many people as possible, and then move on to make the next thing they sell a lot of. The kind of thing that motivates us when we build systems doesn't necessarily motivate them. The finished software product is, in the end, your problem, not theirs. Software engineers are expensive. The more they can push off and avoid paying them, the better.

p0w3n3d 3y ago
thank you, guys/gals, for the explanation, that's a new plane of problems, orthogonal to what I have been experiencing so far.