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

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

[Linus Walleij]

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(-)

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;
 }
-- 
1.7.6

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

[Albert ARIBAUD]

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,
-- 
Albert.

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

[Linus Walleij]

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

[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@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.