Bootloader

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> On Thu, Mar 20, 2008 at 4:21 PM, Andy Green <andy at openmoko.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>>  Hash: SHA1
>>> Really, why would we need any device driver in the bootloader?
>>  > Bootloader are not meant to deal with the device, they let the OS do it.
>>
>>  We have to have a little device-specific knowledge in there to get at
>>  the kernel image over SD on VFAT for example, or it seems NAND bad block
>>  skipping, but it should be really really minimal.
> 
> At least the way I use drivers in bootloaders and in u-boot in
> particular is to validate the hardware without a kernel. Once a

Understood, and it is not a crazy way.

> Memory is arguably the most tricky part in
> bringing up an OS and something that the kernel expects to be ready to
> go, and u-boot 's community and code is a good asset here.

We will hopefully get handed working bootup code to set this up tailored
by the vendor to the on-chip memory.  So we can reasonably expect that
part to not be too tricky for us.

If the prototypes need U-Boot to get straightened out, we will use it
until it is straightened out and hopefully replace it with a minimal
version of our own or if that plan breaks for some reason, a forced
minimal configure of U-Boot.

>>  > And you're right, we could write a dozen of minimal bootloaders by the
>>  > same time we spend fixing/maintaining u-boot.
>>
>>  Well if U-Boot already came patched and working, to start with it would
>>  be quicker to use it.  But I prefer to get rid of it.
> 
> By getting rid of u-boot you'd IMHO be losing one of the attractions
> to openmoko: a low barrier to-entry hackable device. In my case I'm a

No I don't see that at all.  What we will be doing is providing one
common OS for the hackability: Linux[1].  You're not saying that the
Linux kernel is "not hackable", right?

I appreciate what U-Boot has done for me over the years including on
GTA02, but I see U-Boot as fundamentally a wannabe Linux, it is
constantly bloating out with travesty-dumbed-down-drivers from Linux,
adding faux APIs from Linux and generally wanting to be Linux when it
grows up.  Let's just go straight to full-on Linux and get ALL the
drivers full strength with just one tree and API set for us to maintain.

Whatever you were planning to do in the lower-quality sources of U-Boot
(no offense but c'mon just compile the thing from its git and count the
compiler warnings), you can now do as a Linux driver or usermode app
with all the userspace support you would expect -- and using standard
libs and APIs.

It's just going to be a few extra seconds per boot (maybe not so much
either since GTA02 U-Boot burns a few seconds booting itself already).

If you're concerned there is some functionality you can't achieve you
could with U-Boot[2], bring it up here and we will try to figure it out.
 But for sure there are going to be TONS of things you can do with linux
+ userspace you would find very tough to do with U-Boot.

> contributor to u-boot, knows how it works a bit, and am looking
> forward to hacking it on openmoko. Writing your own bootloader or

You can stick U-Boot on whatever we do if you want.  I suspect we might
find that Samsung give us U-Boot patches in which case you should be
away real easy and I am sure we would make patches available.  And as I
said if we can benefit to bring up prototypes and so on we won't
hesitate to use it either.  Just we would rather not ship and maintain it.

- -Andy

[1] Or whatever OS you put on the thing, but it ships with Linux.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD4DBQFH4tpYOjLpvpq7dMoRAk9CAJ0VwUFexgcRwRTQ3qPJclRdyVME2gCYgtXj
ArrqO+zicLQgAySaTyWJVQ==
=nDCE
-----END PGP SIGNATURE-----