-----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 <[EMAIL PROTECTED]> 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-----
