-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
> To my opinion if you are willing to spend more than 4 hours writing a > bootloader bigger than 4k and with SD Card boot feature (vfat?) you > better switch to u-boot. It is more robust. It has all stuff we need > from a bootloader. What I would have done here is dump the registers for the CPU after U-Boot initialized them, and diff them against a dump after my bootloader had started Linux. But isn't the case that the Openmoko patches got you over this hump, not U-Boot in this case, or did I misunderstand? In terms of VFAT support (but not SD Card, I found out the hard way there is no real support for it in U-Boot and you have to do the protocol in your driver) it's GPL so we will rip it from U-Boot, along with any CPU init that might come in the form of U-Boot support, and adapt the Linux SD driver. So we will have any value that U-Boot has for our scenario without worry we missed something. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH4T88OjLpvpq7dMoRAntjAJ9M51A0giZlMNDnZ58wIsm5p+MgeACgliyh 71MbV+i7TSuTxw8zQgL9BwI= =ipOu -----END PGP SIGNATURE-----
