this new "out of the box" MLO/u-boot combo seems to work just fine
on my xM ...
> here's where i want to clarify what's *necessary* and what is
> simply a good idea. from your next post, this revert fixes a
> performance problem with cache. so, theoretically, things should
> work *without* this revert, performance might just suffer,
> correct? so my first phase would be to build and test as is, just
> to verify booting. *then* i'd go back and do the revert.
It'll boot and work just fine without the revert, but to give you an
idea of the penalty.
Building gcc-4.6 without revert: ~25 hours average, with revert: ~12
hours, no other changes on my xM.. 
that's obviously good to know, i'm just trying to clarify what is
absolutely *essential* to get a working system. and in cases like
this, i can see turning that perhaps into a class exercise where
students get an initial working system, and this issue launches us
into a discussion on caching, where a lab requires them to fix it and
test the difference.
it's a "glass half full" perspective. sure, it's an issue that
should be addressed, but it's also a teaching opportunity.
>> and this patch helps on some sd cards,
>>
>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-bsp/u-boot/u-boot/2011.12/U-Boot-OMAP-MMC-Add-delay-before-waiting-for-status.patch
>>
>> last i read there were more discussions, heading in a different
>> direction, but the patch does seem to mask the problem well enough..
>
> again, since you explain that this patch will affect use of
> *some* SD cards, my first instinct would be to test without it to
> see if i can just get a successful boot, then go back later and
> mull over that patch.
It'll boot just fine with out the patch, you'll just a few timeout
errors messages as u-boot loads uImage..
i haven't seen any timeouts. then again, i'm using a class 10 micro
SD card, and the kernel load takes less than 1 second. i've reset a
number of times and never had a problem. so until i do, i'll just
make a note of that but leave it out of the mix.
>> Then you just need the "MLO" and "u-boot.img" from the u-boot
>> build directory.. When using the u-boot SPL version of MLO (vs
>> the older x-loader) it looks for u-boot.img vs the older
>> u-boot.bin..
>
> hmmmmm ... i *vaguely* recall from somewhere that the latest
> SPL/MLO generated by u-boot will still look for a "u-boot.bin" if
> there is no "u-boot.img" -- maybe i'm misremembering.
Not in u-boot v2011.12..
ah, thanks for clearing that up.
> in any event, as you say, the easiest solution is just a straight
> copy of the generated MLO and u-boot.img files to the SD card FAT
> partition.
^^^ Usually works fine on the xM, just be prepared to reformat..
don't see why reformatting would be necessary -- i just mounted the
FAT filesystem (mount -o loop,offset ...) and made the adjustments,
booted just fine:
OMAP3 beagleboard.org # version
U-Boot 2011.12-00201-g137703b (Jan 20 2012 - 03:38:56)
arm-linux-gcc (GCC) 4.2.2
GNU ld (GNU Binutils) 2.17.90.20070806
much less painful than i'd been expecting, thanks for the pointers.
now to document it all and move on.
rday