Bootloader

Andy Green andy at openmoko.com
Thu Mar 20 10:26:27 CET 2008


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

Somebody in the thread at some point said:
> On Wednesday 19 March 2008 19:36, Andy Green wrote:
>>> -1 for writing our own bootloader
> I agree.
> 
>>> If U-boot is bloated and big, we should certainly look into why that's
>>> so and slim it down, but IMO we should avoid reinventing the wheel and
>>> stick with what works.
> I stripped down u-boot code to 96k (just to fit in the very first NAND page, so
> I don't care about NAND Errors (samsung told me that...)) and it has:
> serial support, nand support (ecc), mmc support with vfat support. that's it. No fancy
> LCD support, ethernet, or whatever. I think it is enough for a bootloader. 
> It loads kernel from nand into ram, and jumps into it.
> All other init stuff is done at the kernel driver level, so I see no problem here...

Well, if it has arch support, this solution will work.  I guess we want
to kill U-Boot so it is harder for it to make a bloat comeback and to
establish our new system of Linux doing the things Linux is good at, not
U-Boot.  But arguably we should leave that door open for others to crap
themselves up with U-Boot bloat if they want.  I don't mind to see
either solution myself.

>> Huh I grepped it and it seems U-Boot already has s3c6400 support, I
>> didn't realize.
> So don't re-invent the wheel...

I was mistaken, on what I have from git a few weeks ago anyway, the grep
hits were just the Linux machine ID number.  I guess we likely get
U-Boot support in the Samsung BSP though and then the question comes back.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH4i3DOjLpvpq7dMoRAp/lAJ98Tt65/13LK+9nTpGuMkM5zL9tdACghTvn
p+ZyK8FXdD04gEfdy2kVWkQ=
=ve/7
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list