-----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-----
