omap SDRC controller mismodels case where two RAM banks set to overlap
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro QEMU |
Confirmed
|
Low
|
Unassigned |
Bug Description
linaro-media-create --image_file 0928bqemu.img --rootfs ext3 --dev beagle --binary linaro-
qemu-maemo-
...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-
[ 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/
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...
summary: |
- qemu-maemo: latest linaro snapshot fails on beaglexm with "kernel BUG at - /build/buildd/linux-linaro-2.6.35/mm/bootmem.c:341!" + omap SDRC controller mismodels case where two RAM banks set to overlap |
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.