Hacker News Reader

Comment by swiley | Hacker News Reader

This appears to be the source: https://source.android.com/devices/architecture/kernel/modul...

Device tree is mandatory and vendors are encouraged to upstream the code. It sounds like Google has an eventual goal of building a single kernel that can boot on most devices which is a great thing for everyone.

View on HN

I do not think it can be done. I am mantaining a kernel for ARM a family of SBCs. Device trees are great compared to old platform files, however they are not enough. We have a lot of commits to fix other things that DT cannot access.

Insightful.

To me it seems like a chicken-egg problem: silicon designers have no incentive to standardize the way SOCs work because there will be no benefit to the software ATM.

I'm curious if forcing the egg, common kernels, will have silicon designers rethink their engineering efforts in order to save time on software.

It almost makes me feel like MS had the right model with Windows Phone to a large degree, they decided what chipsets were supported and were responsible for integrating support into the platform - though their list of support SoCs was woefully small. I really see no reason Google couldn’t take the reigns in on developing board support packages for SoC’s and if OEM’s want to use new ones that aren’t in-tree they either work to get it merged or Google doesn’t give them a Google Apps license for the device.

I'm curious as to what things DT cannot access. Is this a general issue (and if so have you spoken to the DT maintainers?), or is this because the systems you are working on are doing something unexpected?

I've had situations where we had to add a small functionality to a driver. For instance a secondary functionality that wasn't supported in the upstream version. It's very rare for drivers of complex components to support 100% of the functionality.

An example that comes to mind was a video chip that also had a GPIO pin that we needed to control. The chip had a driver in the kernel but it didn't have support for the GPIO (it is after all a very secondary function). That required a small patch.

It would of course have been possible to upstream it but then that meant implementing a "clean" patch (using the kernel GPIO API etc... instead of a one liner to toggle the PIN high on dereset) then submitting it upstream, maybe doing a couple of back and forth... Some will bother to do it, many won't.

Drivers can be built as modules most of the time. Google could still ship a single kernel binary and any vendor that had a weird quirk could load their own module. In fact I wouldn't be surprised if Google requires every driver to be built as a module and they ship a minimal core kernel.

Unfortunately there is no binary compatibility between modules and different kernels. Moreover Google recommends CONFIG_MODVERSIONS=y, which prevents to load even practically compatible modules.

The vendor would need to recompile their modules for every kernel Google releases, but that's not a huge issue - how many times does Google update the kernel?

All the ARM boards i know share our same kernel issues. The problem is that DT is basically a configuration, which is accessed by drivers. If a driver do not read it, you must edit the driver. For instance a 2 lines patch [1] is about the fec (ethernet) driver. DT can specify a sleep time before the PHY reset GPIO is toggled. However we need to sleep also after the toggle, hence the patch.

[1] https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...

Just curious, has that been discussed on the kernel mailing list?

Not really an issue if you upstream these changes. That's a big "if" though, that can be a painful process.

It also means that you'd have to wait for the kernel to be released and then google to pick it up before you can use an "official" kernel for your device. In the meantime you'll have to ship your own customized version. I'm not really sure how that's going to work.

Does Apple do it?

> a single kernel that can boot on most devices

That seems to be also a goal of postmarketOS, which was discussed here recently.

https://github.com/postmarketOS/pmbootstrap/issues/91

Reply on news.ycombinator.com