[Arm-netbook] Planned boot process?

[lkcl luke]

On Wed, Dec 21, 2011 at 5:26 PM, Derek LaHousse <dlahouss at mtu.edu> wrote:
> Hello,
>
> I've seen the discussion on putting an I2C EEPROM on the motherboard side of
> the PCMCIA, and I think I've understood the discussion about putting a device
> tree on that EEPROM.

 yes. so, when the CPU card is put into different devices, a decision
can be made "oh look, it's completely different, let's boot up an
entirely different OS not just a different configuration but literally
an entirely different OS from an entirely different partition".

>  But how does the CPU-card side boot up?

 it literally depends on the SoC vendor on their boot sequence.  TI
CPUs execute an internal ROM from a fixed memory address.  this ROM
reads some external GPIO pins, and, depending on which are high or
low, either the CPU will jump execution to a fixed memory address
(published in the reference manual) or it will read data from the SDIO
interface (a fixed block size) and then execute that.

 some SoCs also have the ability, depending on pins set, to also read from USB.

 but, really, it entirely depends on the SoC vendor.

 now, this is why u-boot was "invented", to "normalise" all of these
things... _but_... what _is_ u-boot?  well, it's a complete dog's
dinner mixture of cut/paste parts of the linux kernel, cut/paste parts
of libc6 and cut/paste parts of various applications.

 in other words, u-boot is a complete mess, an absolute pain to
maintain, and full of bugs... _and_ you have to duplicate vast amounts
of linux kernel code in order to get it to work.

 a much *much* simpler arrangement is to boot a linux kernel, start a
"basic application" - even in initrd - which could either be "hello
what OS would you like" or even a port of grub2.  then you run kexec.

 this has actually been done - there do exist kexec-based bootloaders.
 the nice thing about such bootloading techniques is that the
applications can be compiled using *standard* libc6 (ur uclibc) rather
than pissing about, which means that they can be tested on a
*standard* system (e.g. compiled as an x86 application) and tested
under qemu really really easily, if you prefer not to be rebooting
your main system.

 i used to think that u-boot was great, but because it has to be
customised - each and every time *just* like the linux kernel has to
be customised - and because there is so little common code across SoC
vendors, i'm just really confused why u-boot is still even in
existence,

> The lichee/v2.6.36 build script attempts to make a uBoot image.  I assume this
> is an artifact of the Android device where the code originated.  Will the
> AllWinner A10 EOMA/PCMCIA CPU-card have a firmware, an EEPROM, a device tree?

 yes.  actually, the allwinner scheme is pretty damn good so it mayy
be worthwhile investigating and using that: it's the same thing, after
all.  the problem is: it's not "supported" by the linux kernel
developers - there was no discussion about it.

 perhaps if allwinner proposed it upstream, wrote documentation on it
etc. then it would stand a chance of upstream acceptance, but until
that happens the most sensible thing is probably to use devicetree.

 l.