5 ms·

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 en

by fmntf 9y ago

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.

exabrial 9y ago
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.
- snuxoll 9y ago
  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.
Khol 9y ago
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?
- simias 9y ago
  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.
  - castratikron 9y ago
    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.
    - fmntf 9y ago
      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.
      - rbanffy 9y ago
        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?
- fmntf 9y ago
  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/b2fc4a3cba41c7f7af86b99476055c2b46e86605 https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...
icebraining 9y ago
Just curious, has that been discussed on the kernel mailing list?
simias 9y ago
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.
valuearb 9y ago
Does Apple do it?

by fmntf 9y ago

exabrial 9y ago

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.

snuxoll 9y ago
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.

Khol 9y ago

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?

simias 9y ago
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.
- castratikron 9y ago
  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.
  - fmntf 9y ago
    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.
    - rbanffy 9y ago
      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?
fmntf 9y ago
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/b2fc4a3cba41c7f7af86b99476055c2b46e86605 https://github.com/UDOOboard/linux_kernel/commit/b2fc4a3cba4...

icebraining 9y ago

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

simias 9y ago

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.

valuearb 9y ago

Does Apple do it?