(Oops, resent: used the wrong sender address for the two mails to list..) Hi Toby and others, Quoting "Toby Corkindale" <toby@dryft.net>
The device-tree overlays are a massive PITA for hackers, because the learning curve is steep and the hurdles are high before you can do something simple like switch some GPIO pins, let alone configure more complex things. But it sounds like DTO is going to be good in the long run for making more-supportable hardware.
I found this here useful to understand a bit: http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded...
The problem is that in all cases, you tend to need a custom kernel for your board, and the distro makers are only supporting one or two boards. (eg. Ubuntu server is available for three boards, with a fourth in preview status)
So all the amateur distros are basically taking those, and injecting a jury-rigged custom kernel into them. This means you do get updates to userland coming through regularly, since you're hooked into an official repository for them -- but not kernels.
I am reading through some stuff related to the Firefox OS phone.. it looks as the "hardware BLOBs" are described and sitting in the firmware so can included in a new kernel you are building? Does it mean there is a stable ABIs to hook the drivers into a Android kernel? How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux 3.8 to 3.10 to..? Even other OSes?
Chris explained that this is because ARM hardware isn't discoverable. That makes more sense to me now. It's also rather annoying :(
In case you have a running kernel: You take the info from there and "suck it" into your new kernel (when you compile your own? The device tree description is on every ARM device, whether it is Android or Firefox OS? (e.g. - I struggle with the information to update Firefox OS because some assume I have Android on it - but I already have Firefox OS) Thanks for educating me:-) Peter