andy, paul, On Thu, Jun 30, 2011 at 6:26 AM, Andy Green <andy.gr...@linaro.org> wrote:
> Nicolas already gave a rundown but the short answer is the ROM can drive > the MMC hardware of the OMAP4, talk SD-HC protocol, parse your partition > table and FAT filesystem on your SD Card, and will load and execute a file > of the magic name "MLO" on partition 1. > > That is "x-loader", which sets stuff up and loads and executes a magic file > "u-boot.bin" off partition 1. And "u-boot" does its usual thing from then > on. > unlike MLO filename which is hardcoded in the ROM code (hence cannot change) the 'u-boot.bin' is coded in x-loader and is manageable. as it turns out ROM code needs to be able to read FAT/SD, x-loader needs that too (to load u-boot), and u-boot as well ;-) how funny... > > ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in > OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care > about any arcane stuff like geometry for example. It only needs to success > to pull MLO reliably and anything further can be done there in an > upgradeable way. > yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback from linux/SD card users. > > Of course, it'll pull anything called MLO. I believe folks are working on > adding stuff to be able to call U-Boot "MLO" directly eliminating x-loader > and Matt Hsu and I already did that for Qi. > one clarification: the u-boot MLO project is just about the capabilities of rebuilding MLO from u-boot sources. in fact MLO is a 'tiny uboot'. so instead of duplicating the source tree for x-loader as it stands today, the idea is to have a mlo config in uboot and rebuild this tiny uboot from uboot sources so that there is no need to maintain 2 MMC driver for example. you will still get a 2-stage bootloader. > > So, it would be nice if you could suggest Android team which >> repo/branch/tag/revision can be safely used to produce releases. >> > > Yeah confusing ain't it. There are two camps in x-loader development one > on omapzoom and one on gitorious. TI engineers like omapzoom but the > official repo is gitorious. > i don't think it's a TI vs others issue. TI has been pushing for a mailing xloader because there is a lot of confusion on this topic. the clean mainline tree started after the android xloader and is still lacking behind. if community/TI is able to bring mainline x-loader to the same level of features has the omapzoom one, I am pretty sure that the migration can happen. > The magic branch I (and I believe Ubuntu) use is: > > git://gitorious.org/x-loader/**x-loader.git<http://gitorious.org/x-loader/x-loader.git>master > > ... and BTW, 3.0 android kernel from us requires MLO update from what you > supply at the moment to this in order for 3D unit to start up. So this is a > good idea anyway. >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
