[Arm-netbook] "allwinner's A10" codenamed "sun4i crane", linux kernel v2.6.36 patch available

[Bari Ari]

On 11/12/2011 06:01 PM, Luke Kenneth Casson Leighton wrote:
>   yyeeess... but all ARM hardware init is utterly and completely
> different from every other ARM hardware unit.  multiply that
> accumulatively by 650 licensees over a 20+ year period and escalating
> and you start to appreciate that there is absolutely no chance in hell
> of finding large swathes of common ground [but there *may* be some
> small ones].
>
>   even attempts made by ARM *themselves* to provide "common ground" -
> for example in the form of adding PCI-like / USB-like dynamic
> identifiers in the AHB specification, were completely and utterly
> ignored by the majority of ARM licensees and, worse, mis-implemented
> by many more!
>
>   the problem is that, unlike in the x86 world where they *have* to
> comply to standards [beyond the IC and the IC manufacturer's control],
> ARM SoC vendors are entirely at liberty to make a complete dog's
> dinner, violate every single rule and standard and _still_ make some
> money selling the chip!
Yes, it's been interesting and sad working with ARM since Acorn and 
watching this mess develop with peripherals and I/O.
>
>
>   btw please don't mention u-boot as a "solution" :)
>
>   u-boot is a god-awful mess that should never have been brought into
> existence.  it comprises half-baked versions of linux device driver
> code on top of _multiple_ flavours of part and full libc6 support
> *combined* into the same dog's dinner package.

Sure it's not greatest. There have been afew projects that actually 
stripped it down and cleaned it up a bit. The point is that vendors 
could easily modify it and be running a system in hours or days but 
choose to start from scratch just to keep their hardware locked down or 
include malware.
>
>   in the ARM world, it's actually infinitely better to place the linux
> kernel itself as the boot-loader, run a tiny initrd for the dedicated
> purpose of presenting a choice of options to boot, and then using
> kexec to load up a new (or even the exact same) kernel, a new initrd
> and to go from there.  i know of at least two projects which have
> successfully used this trick.  it would be great if someone used it to
> start up grub2 on ARM, but that may actually prove to be unnecessary.
>
>   at least with kexec you don't have the god-awful mess x 2 to maintain.
http://kexecboot.org/about  for one
>
>   coreboot, if again it was modified to include support for ARM, would
> out of necessity have to do the exact same dog's dinner that u-boot
> has gotten into: ripping off the entire device driver source code
> (with associated risks of mistakes, version control and more, of which
> there is vast numbers occurring repeatedly in u-boot) and then being
> forced to maintain it.
>
>
coreboot is not an OS unlike what EFI and u-boot actually are. No 
drivers, just hardware init and then it's off to a payload. The point of 
bringing up coreboot is that it provides a common framework or structure 
for init.

-Bari