uboot fails in latest beagle nano snapshot (02-07-2012)

The 1108 nano image works ok with -M beagle, so this is probably a problem that's been shown up by some new u-boot change.
Log from a working 1108 boot:

Texas Instruments X-Loader 1.5.1 (Jul 26 2011 - 00:39:12)
Beagle Rev C4
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2011.06 (Aug 19 2011 - 17:43:34)

OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

ERROR : Unsupport USB mode
Check that mini-B USB cable is attached to the device
In: serial
Out: serial
Err: serial
Beagle Rev C4
No EEPROM on expansion board
Die ID #51454d5551454d555400000051454d55
Hit any key to stop autoboot: 0
SD/MMC found on device 0
reading boot.scr

Investigated a bit. This is failing because:
 * something (I guess U-Boot SPL) misprograms the SDRC MCFG_0 register to claim that bank 0 of the RAM is 512MB, not 256MB
 * this causes u-boot to believe that it has 512MB to play with, so it puts some of its data structures at just below 0xa0000000, where there is no RAM, so this area always reads as zero
 * in particular, this includes its "list of DRAM banks" data structure
 * so it writes plausible values into this structure but then later when it tries to read them back they read as zero and it decides it has no DRAM
 * presumably it subsequently tries to put some actual code in the 0x90000000..0xa0000000 gap where it thinks there is RAM, and qemu barfs when it tries to execute it

I'm trying to track down the sources corresponding to the U-Boot SPL in this image (the manifest.txt seems to be out of date) which is the next step in finding out why the SDRC was misprogrammed in the first place...

So this happens because u-boot's code to identify what RAM timings to use doesn't cover the case we report:

http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=blob;f=board/ti/beagle/beagle.c;h=2dd863b4171211c014816a6b858aef9edad59835;hb=HEAD#l179

QEMU reports as a C4 via the GPIO lines, and a NAND manufacturer of Micron with a part ID 0xba. U-Boot's code for the C4 only handles (STMicro, 0xba) and (Micron, 0xbc). Anything else falls through (intentionally or accidentally?) to the XM cases and we end up with the settings for the 512MB Numonyx.

This is a legitimate config found on real hardware: here for example is a boot log I found via google which clearly shows a C4 with an (0x2c, 0xba) NAND chip and 256MB of RAM.
http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2011-May/004610.html

So it's a U-Boot bug.

Oops, wrong dmesg: the linuxtogo url is for a C1/C2/C3 with the Micron 0xba NAND; here's the C4 with that NAND:
http://osdir.com/ml/beagleboard/2011-09/msg00604.html

Thanks Peter for doing all the hard work. I have marked the bug invalid for qemu and added u-boot-linaro.

This bug seems to also be the cause for the 12.02 beagle instability.

The fix has been commited to git so should be fixed in recipe builds but still need to push a fix to ubuntu.

This bug was fixed in the package u-boot-linaro - 2012.02.3-ubuntu1

---------------
u-boot-linaro (2012.02.3-ubuntu1) precise; urgency=low

  * Update to upstream 2012.02.3 u-boot-linaro which includes patch
    to correct memory size on rev C4 Beagle.
    (LP: #928580).
 -- John Rigby <email address hidden> Mon, 02 Apr 2012 10:53:32 -0600