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

[Luke Kenneth Casson Leighton]

On Sat, Nov 12, 2011 at 11:40 PM, Bari Ari <bari at onelabs.com> wrote:
> On 11/12/2011 04:38 PM, Gordan Bobic wrote:
>>   Endless code bloat isn't the solution, even if the SoC manufacturers
>>   were to decide to provide long term support/maintenance of their kernel
>>   contributions. The obvious solution is to come up with a standard ARM
>>   BIOS - but the chances of that happening any time soon (and probably at
>>   all) is pretty close to 0.
>>
>>
> All ARM should need is hardware init and a bootloader.

 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!


 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.

 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.

 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.

l.