omap SDRC controller mismodels case where two RAM banks set to overlap

[Peter Maydell]

linaro-media-create --image_file 0928bqemu.img --rootfs ext3 --dev beagle --binary linaro-m-headless-tar-20100928-0.tar.gz
qemu-maemo-system-arm -M beaglexm -m 256 -sd 0928bqemu.img -clock unix -nographic

...this starts the kernel but it rapidly hits a kernel BUG():

Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35-1006-linaro-omap (buildd@gourd) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #12-Ubuntu Tue Sep 21 20:09:17 UTC 2010 (Ubuntu 2.6.35-1006.12-linaro-omap 2.6.35.4)
[ 0.000000] CPU: ARMv7 Processor [412fc083] revision 3 (ARMv7), cr=10c03c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Reserving 12582912 bytes SDRAM for VRAM
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] Truncating RAM at a0000000-bfffffff to -afffffff (vmalloc region overlap).
[ 0.000000] OMAP3630 ES1.2 (iva sgx neon isp 192mhz_clk )
[ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
[ 0.000000] kernel BUG at /build/buildd/linux-linaro-2.6.35/mm/bootmem.c:341!

The image works fine on a real hardware beagle XM rev A2. It also boots (but fsck then complains that the root fs size is bigger than the physical device size...) if you pass qemu the -M beagle option to make it emulate an old beagleboard...

[Peter Maydell (pmaydell)]

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.

[Paul Larson (pwlars)]

I see this as well, only I specified -m 512. But only with beaglexm. With -M beagle I get further than this before hitting a different problem

[Peter Maydell (pmaydell)]

The beagle model currently ignore the '-m' option and always provide a compile-time-fixed amount of RAM. This bug doesn't appear on beagle because x-loader programs the SDRC differently and the memory banks aren't set up to overlap.

[Peter Maydell (pmaydell)]

I've filed https://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/652861 about x-loader setting the RAM up to overlap. It looks like (a) it only does this for Numonyx RAM and (b) it defaults to assuming Numonyx if it can't identify the RAM manufacturer. We could work around this by explicitly advertising ourselves as Micron RAM...

[Peter Maydell (pmaydell)]

> We could work around this by explicitly advertising ourselves as Micron RAM...

...except that we already are explicitly advertising ourselves as Micron, but the x-loader function which tries to distinguish Micron from Numonyx is broken and will (almost) always decide "Numonyx": https://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/652850

[Loïc Minier (lool)]

Strictly speaking a bug in qemu, but hard to fix; was easier to fix x-loader.

Keeping this open, but Peter feel free to Wontfix if you't want to see it for now.