[U-Boot] [PATCH 3/5 v1] integrator: do not test first part of the memory

[Albert ARIBAUD]

Le 17/10/2011 13:57, Linus Walleij a écrit :
> Hi Arnaud,
>
> On Sun, Oct 16, 2011 at 5:51 PM, Albert ARIBAUD
> <albert.u.boot at aribaud.net>  wrote:
>> Le 18/09/2011 09:52, Linus Walleij a écrit :
>>>
>>> When booting from Flash, the Integrator remaps its flash memory
>>> from 0x24000000 to 0x00000000, and starts executing it at
>>> 0x00000000. This ROM thus hides the RAM underneath and first
>>> 0x40000 bytes of the memory cannot be tested by get_ram_size().
>>> So let's test from 0x40000 to the end of detected memory
>>> instead.
>>
>> Is this masking of RAM by FLASH a hardware thing that cannot be avoided?
>> Can't the U-Boot startup code somehow remap the FLASH elsewhere, and then
>> proceed to really test the whole RAM?
>
> Well, it is unmapped in board_init() but that is post-RAM-test.
>
> The reason I cannot unmapp it in dram_init() is that at this point
> U-Boot is running from flash and has not relocated itself (it wants to test
> RAM before relocating of course) and the flash it is running from is
> exactly that which is in the way of the RAM test.
>
> So on integrator, the flash memory remaps itself to address 0x00000000
> when booting from flash, and U-Boot has text base 0x00000000 in
> this case, and is running in flash relative 0x00000000.
>
> If it would remap the flash at this point it would unmap itself,
> and crash.
>
> This way of having the flash containing U-Boot remap itself over the
> system RAM seems to be uncommon, but I'd share the problem with
> anyone else trying to do something similar I guess.

There is a technique for remapping running code memory, which relies on 
the mapping controller being able to map the same device twice: usually 
you start with one window already defined for the boot device, then you 
create another window where you want the device to end up, then you jump 
to that new address, then at that new address you can unmap the original 
window. I sort of did that for orion5x, for a slightly different reason 
-- see orion5x_config_adr_windows() in cpu.c.

Otherwise, I don't suppose there is static RAM that the FLASH code could 
use as a pivot? If there was, you could boot from flash @ 'bad' 
location, copy a flash-remapping routine into SRAM, jump to it, once 
remapped, the routine jumps to flash@ 'good' location and then you can 
test the whole RAM.

> Yours,
> Linus Walleij

Amicalement,
-- 
Albert.