Hacker News Reader

Comment by megous | Hacker News Reader

> If the software that can run on these are cobbled together semi-proprietary chains of mishmashed crap, these boards will continue to be mediocre at best.

What part of SW needed for RK3399 is that? To me pretty much all from bootloader to kernel is mainline in various projects and FOSS. So far it was fairly straightforward use mainline APIs trying to make cameras work via ISPs, RGA for image rotation, Hnatro for JPEG encoding in HW, etc. etc.

Very few small bugs here and there that can be easily fixed.

I've seen much worse. TRMs are available. Various other PDFs from Rockchip can be found, too (even some obscure ones about camera calibration, and stuff like that).

View on HN

I have a question regarding "mainline" that I hope someone could help clarify.

What is the difference (in terms of coding, etc.) between mainlining support for a chip into Linux versus pinning it to a specific kernel revision? What makes it easy to bring a chip up on a specific kernel version,but not easy to submit that to the mainline kernel so future versions of the kernel are compatible?

Are there significant changes between kernel versions that require someone to be an active maintainer for the specific chip, making sure changes to the kernel stay compatible with the chip? And thus most manufacturer don't care enough to keep supporting future versions once they get on specific kernel version working?

To have code included in mainline you need to have reasonably sane code in the first place, and then invest some time working with upstream maintainers to address their concerns. On the other hand vendor code dumps are usually haphazardly put together garbage that nobody wants to touch.

Rebasing (possibly shitty) patches from the SBC vendor to a recent kernel can be non trivial in my experience (as someone who have 0 knowledge of the Linux kernel code, so I'm a good baseline to define what's trivial ^^). And yes most vendors are will ship one working kernel source and forget about it forever right after :) even vendors that are not the worse depend on drivers that are provided by the SoC vendor, and might be stuck because rebasing a GPU driver might even be hard for them I guess.

Code will stay compatible (if someone refactors something, they'll update all the drivers), so that's not it. You just need to test your hardware with each new kernel release (every two months), otherwise you may not notice any breakage.

Reply on news.ycombinator.com