On Thu, Jun 30, 2011 at 6:26 AM, Andy Green <andy.green@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 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.