[Arm-netbook] Linus wingeing about ARM

[Gordan Bobic]

On 10/12/2012 02:22 PM, Henrik Nordström wrote:
> fre 2012-10-12 klockan 10:24 +0100 skrev Gordan Bobic:
>
>> Seems to me the ideal way forward would be that if they licence people
>> to use the ARM instruction set and designs, they must also include a
>> standardised boot mechanism. This may be hard to to retrospectively, but
>> putting that requirement in for every future licence would solve the
>> problem for at least the future cores.
>
> ARM do have provisions for "BIOS" discovery in their IP blocks, in
> theory enabling the same boot loader and kernel to work across a range
> of SoCs. Today sadly probably only used by debuggers.
>
> I don't view the booting part as such a big problem. u-boot fills the
> "BIOS" space quite nicely. It's even less device specific than your
> favorite x86 PC BIOS, and completely open. Additionally there is a clean
> boot interface defined by the Linux kernel which keeps the OS interface
> even if you change to coreboot or another bootloader/"BIOS". And if you
> place u-boot/coreboot + devicetree in a SPI flash separate from the rest
> you get a clean separation close to the same level as x86 BIOS. Sure,
> there is no ACPI but is it needed?

The problem is that there are a number of devices with closed, 
proprietary boot loaders, and this is bad. If every ARM device came with 
uboot it'd be bearable. But the problem is that different versions and 
variants of uboot are extensively different, in what FS-es they support, 
and what devices they support, and even the commands they use to 
initialize a particular subsystem (e.g. usb, mmc, ata, ...).

Uboot is a step in the right direction, but it suffers from the same 
proprietary fragmentation as the kernels. There are different uboot 
variants even on extremely similar devices, e.g. Sheeva/Guru/Dream plugs.

Not to mention that different machids are OTT most of the time, just for 
the sake of defining things like the built-in NAND layout which should 
by all rights be a kernel boot option, rather than a hard-coded kernel 
option. This is a sufficient pain in the backside that I just don't use 
built in NAND and have all of my *Plugs booting off SD. And even then I 
have to deal with different uboot versions/implementations with 
different initialization commands and FS support.

> This is more of a matter for device vendors to settle on structure than
> ARM to impose.

If the boot loader standard were somehow enforced it would help a fair 
amount.

> The main challenge is that Android folks isn't interested
> in reducing the lockin in their devices. Meaning there is zero device
> manufacturer interest in being able to run the same Android OS image on
> multiple devices, only interest in making sure this do not happen.

Precisely - hence why enforcing a common standard would be a huge step 
in the right direction.

> And the shift to a common "boot interface" will imho come all naturally,
> driven by Lnux distributions in the general computing usage of ARM
> processor cores, not from Android.

Except there are many orders of magnitude more of Android ARM users than 
Linux ARM users. And for that reason alone, I don't expect the 
manufacturer focus is likely to change.

> The fact that ARM is being used more and more in general computing puts
> a whole range of new requiements on system design which is not seen in
> the consumer device segment or router segmennt, including the ability to
> run the same OS on multiple different system designs.

Only on very specific SoCs. Calxeda chips and Marvell chips, sure. But 
in the majority of other cases there seems to be relatively little 
general computing pressure at the moment.

Gordan