andy at openmoko.com
Wed Mar 19 20:14:06 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel