| Message ID | 1316332361-18454-1-git-send-email-linus.walleij@linaro.org |
|---|---|
| State | Accepted |
| Commit | 46b5ccbfe299887fa1f8b15d494d0a5f0e75ee2e |
| Headers | show |
Hi Linus, 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? Amicalement,
Hi Arnaud, On Sun, Oct 16, 2011 at 5:51 PM, Albert ARIBAUD <albert.u.boot@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. Yours, Linus Walleij
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@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,
diff --git a/board/armltd/integrator/integrator.c b/board/armltd/integrator/integrator.c index c8d2bc7..83f047c 100644 --- a/board/armltd/integrator/integrator.c +++ b/board/armltd/integrator/integrator.c @@ -86,6 +86,15 @@ int misc_init_r (void) return (0); } +/* + * The Integrator remaps the Flash memory to 0x00000000 and executes U-Boot + * from there, which means we cannot test the RAM underneath the ROM at this + * point. It will be unmapped later on, when we are executing from the + * relocated in RAM U-Boot. We simply assume that this RAM is usable if the + * RAM on higher addresses works fine. + */ +#define REMAPPED_FLASH_SZ 0x40000 + int dram_init (void) { gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; @@ -111,15 +120,17 @@ extern void dram_query(void); * */ sdram_shift = ((cm_reg_sdram & 0x0000001C)/4)%4; - gd->bd->bi_dram[0].size = 0x01000000 << sdram_shift; - gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, + gd->ram_size = get_ram_size((long *) CONFIG_SYS_SDRAM_BASE + + REMAPPED_FLASH_SZ, 0x01000000 << sdram_shift); } #else - gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; - gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, + gd->ram_size = get_ram_size((long *) CONFIG_SYS_SDRAM_BASE + + REMAPPED_FLASH_SZ, PHYS_SDRAM_1_SIZE); #endif /* CM_SPD_DETECT */ + /* We only have one bank of RAM, set it to whatever was detected */ + gd->bd->bi_dram[0].size = gd->ram_size; return 0; }
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. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- board/armltd/integrator/integrator.c | 19 +++++++++++++++---- 1 files changed, 15 insertions(+), 4 deletions(-)