Will this unified kernel for ARM devices affect Android (in a good way) at all? Does it mean we're looking at a future where an Android image could be installed on different ARM devices?
The same kernel could be installed on different devices, yes, provided the necessary drivers for all of those devices were part of that kernel build. You still have some platform specifics in userspace though, like build.prop and all the HAL libraries. Those could conceivably be loaded in a more neutral way, but I don't think it's set up for that yet.
I don't know if Google will ever be able to get manufacturers to make their drivers open source and offer them up to the community, but I hope they eventually manage to at least get them to bundle their proprietary drivers, and offer support for 2 years since the device's launch. In that way, it could at least become like Windows eventually, which wouldn't be a bad outcome at all.
They'd also have to stop changing the driver APIs. For example my G2 used to only have drivers for Linux 2.6 but ICS uses Linux 3.0 which made life difficult for custom ROM hackers.
The situation for Linux on ARM is better than it was 10 years ago, but it is still chaos at the low levels.
Most of this has to do with cost. Each of the silicon vendors has their own IP which is bundled with their SoC; things like serial ports, PLLs, etc.. I don't foresee a time when a nearly universal standard like the 16550 on x86 is going to be available across major SoCs. The situation with USB controllers isn't too bad, but nearly everything else is unique to one vendor or another.
Since we're commonly populating 1Gbyte of RAM on these high-end ARM systems for phones and tablets, I'm curious to see how the transition to 64-bit is going to go. I'm sure it will be hilarious... and by that I mean there will be a lot of broken-ness for quite a while.
I'm not real hot on Intel for battery-powered mobile devices, because I don't see major cost or power-consumption advantages. But if Intel can make it easy to transition to newer chips, that could be one significant advantage.
Its my big bug-bear when developing ARM embedded systems, having to re-learn and re-code libraries every time the chip changes. Just look at the guys struggling with the low level stuff on the Raspberry Pi
A low level BIOS flashed into the chip would be an absolutely awesome outcome for the embedded crowd.
8 comments
[ 5.2 ms ] story [ 29.4 ms ] threadMost of this has to do with cost. Each of the silicon vendors has their own IP which is bundled with their SoC; things like serial ports, PLLs, etc.. I don't foresee a time when a nearly universal standard like the 16550 on x86 is going to be available across major SoCs. The situation with USB controllers isn't too bad, but nearly everything else is unique to one vendor or another.
Since we're commonly populating 1Gbyte of RAM on these high-end ARM systems for phones and tablets, I'm curious to see how the transition to 64-bit is going to go. I'm sure it will be hilarious... and by that I mean there will be a lot of broken-ness for quite a while.
I'm not real hot on Intel for battery-powered mobile devices, because I don't see major cost or power-consumption advantages. But if Intel can make it easy to transition to newer chips, that could be one significant advantage.
[1] http://us2.campaign-archive1.com/?u=193b767bbb3b0eb0d949d592...
A low level BIOS flashed into the chip would be an absolutely awesome outcome for the embedded crowd.