Comment 1 for bug 651332

For some reason uboot is detecting twice as much memory as qemu is providing. So with the default 512MB allocation as set in hw/beagle.c uboot says "DRAM: 1 GiB". If you fiddle beagle.c to pass in 256MB then uboot says "DRAM: 512 MiB". (And if you look at the result of 'bdinfo' that matches the twice-as-large values.)
The result is that the kernel tries to use the nonexistent RAM, which behaves as RAZ/WI and results in the kernel BUG the first time it tries to read back data from the high part of memory.

I think this is happening because X-Loader is spotting that it's an XM and setting up the SDRC for two banks of RAM of size 512MB but only 256MB apart(!): tracing in qemu says this:

cam-vm-266:maverick:qemu-0928$ ./arm-softmmu/qemu-system-arm -M beaglexm -sd ~/linaro/linaro-snapshot-2/0929b.img -clock unix -nographic
cscfg: write 2
cs[0].mcfg write 4590099
cs[1].mcfg write 4590099

Texas Instruments X-Loader 1.4.4ss (Sep 6 2010 - 08:19:49)
(etc)

I suspect that on the real hardware the effect is that accesses to the overlapping space go to the empty CS1 bank and fail. On qemu they just go straight through to the RAM we've mapped for CS0. So u-boot thinks that CS1 is an OK bank of RAM because a write-read to the start of it works, and so it decides that there are two banks.

I'm not sure why X-Loader is doing this (if indeed it is X-Loader and not something else). Probably qemu should either map and unmap ram in accordance with the SDRC register writes, or if it wants to fix the amount of ram it has it should ignore SDRC writes.