[Arm-netbook] Planned boot process?

[Tom Cubie]

On 12/22/2011 04:08 AM, lkcl luke wrote:
> 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.

     I think Allwinner wants to push the kernel upstream(personally i 
like to see that happens), but they have no time and people to do this. 
None of the developers in Allwinner has the experience of doing some 
open source project, nor committing patches to the upsteam. I have asked 
my manager, and told him that we need the community to help. He is glad 
and said we will fully support the community to do this. So allwinner do 
want to push it upstream, just we don't what to do and how to do it. At 
least one thing is for sure, allwinner is friendly to the community and 
will be supporting the community.

> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk