Bootloader

[Andy Green]

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

Somebody in the thread at some point said:
> Andy Green wrote:
>> and patch out any other junk that leaks in to get the
>> same effect.
> 
> That gets messy very quickly. E.g., just look at cpu/arm920t/start.S
> which, besides the storage driver, which only needs reading, is
> about all the "difficult" code we can share. Most of the other
> essential stuff, memory timing, GPIOs, PMU, PLL magic, etc., lives
> in board/neo1973/.

Yeah.  I just saw grep only found s3c6400 because it was on the Linux
list of machine types too.  I suppose any BSP can contain a U-Boot patch
but I don't know what we will actually get.

The usual thing against building your own bootloader and "re-inventing
the wheel" doesn't seem to apply here due to the reasoning of "getting
rid of U-Boot" and discarding every single feature except the ones
needed for pulling in and booting a kernel.

OK.  Here are some related points about this question.

 - If we have NAND back again, how are we going to manage the bad block
stuff with this minimal bootloader? Can it end up we can't get away from
U-Boot because of NAND or is it okay?

 - What about an environment?  U-Boot env seems to be a place where bugs
can come from in terms of the same devices acting different.  But maybe
we must allow kernel commandline customization pre-kernel.  If we start
down that road maybe it should be U-Boot env.

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

iD8DBQFH4WX+OjLpvpq7dMoRAtajAJ9Gxc2ymnokI5AQYtGvkQra0KXRRACfcQIW
yjK1zh0Kg9rnAb0J/ZxM6qI=
=hyjx
-----END PGP SIGNATURE-----