Hi,
I'm using "mtest" to test the sdram somewhat, but parts of the ram is ofcourse left untested doing so - due to stack- and u-boot positioning.
Enabling DEBUG'ing I narrowed in the plausible test segment into something like:
=> mtest 1090 3f8af37
where the last value is based on the information:
Top of RAM usable for U-Boot at: 04000000 Reserving 208k for U-Boot at: 03fcb000 Reserving 256k for malloc() at: 03f8b000 Reserving 128 Bytes for Board Info at: 03f8af80 Reserving 48 Bytes for Global Data at: 03f8af50 Stack Pointer at: 03f8af38 New Stack Pointer is: 03f8af38 Now running in RAM - U-Boot at: 03fcb000 FLASH: [flash_init, 771] Entering ... [flash_init, 772] flash_info = 0x03FFEB20 ... U-Boot relocated to 03fcb000
and the first from manual testing.
So, I would like to make a new u-boot binary that offered me the possibility to test the first part - from "0x0" to "0x108F" and from "0x3f8af37" to "0x3ffffff".
I've scanned my board-header to see if any of these addresses are directly present there, but without luck. The nearest I get to something that smells of the lower boundary, is the value of "CFG_INIT_RAM_ADDR" and "CFG_OCM_DATA_SIZE" both having the value 0x1000.
Any clues?
BR, Martin Egholm