[U-Boot] [PATCH] arm: fix bug on relocation address

[Luca Ellero <lroluk@gmail.com>]

Hi Jeroen,
Hi Heiko,

On 31/01/2013 20.08, Jeroen Hofstee wrote:
> Hello Luca,
>
> On 01/31/2013 03:29 PM, Luca Ellero wrote:
>> If (N. SDRAM banks > 1) and they are not contiguous, don't relocate
>> u-boot at (CONFIG_SYS_SDRAM_BASE + gd->ram_size), which is a bug.
>> Instead use the end of 2nd bank (even if there are more than 2 banks)
>>
>> Signed-off-by: Luca Ellero <lroluk@gmail.com>
>> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
>> Cc: Heiko Schocher <hs@denx.de>
>> ---
>>
>> On ARM architectures there is a bug getting top of SDRAM (where u-boot
>> will be relocated). Top of SDRAM will always be:
>>
>> CONFIG_SYS_SDRAM_BASE + gd->ram_size
>>
>> anyway this can be wrong since SDRAM can be composed by more that one
>> bank in not-contiguous address space.
> I don't think this is a valid use case since the README says:
>
> "The available memory is mapped to fixed addresses using the memory
> controller. In this process, a contiguous block is formed for each
> memory type (Flash, SDRAM, SRAM), even when it consists of several
> physical memory banks."
>

Thank for your comments.
You are saying more or less the same thing but I'm afraid I didn't 
really catch what you mean.
I know how is the U-Boot memory map and I summarize it here  (more or 
less, depending on board configuration):

TOP of RAM ------------------------
              Kernel Log Buffer
            ---------------------------
              Protected RAM
            ---------------------------
              TLB Table (32kB to 64 kB)
            ---------------------------
              LCD Frame Buffer
            ---------------------------
              Relocated U-Boot Code
            ---------------------------
              malloc area
            ---------------------------
              Board Info (struct bd_t)
            ---------------------------
              Global Data (struct gd_t)
            ---------------------------
              IRQ Stack
            ---------------------------
              Abort Stack
            ---------------------------
	     ...


Now, I have a Freescale iMX53 LOCO board which have 2 banks of 512 MB 
SDRAM, for total of 1GB. One bank is at phys 0x70000000-0x8fffffff, the 
other is at 0xb0000000-0xcfffffff.
If I stop U-Boot execution after relocation (with a JTAG debugger) I see 
that it is running at physical address 0xaff6D000 (more or less).
As far as I can see this address is not existent. And the dangerous part 
is that I can see the same data (U-Boot code) at address 0x8ff6D000. 
This clearly states that U-Boot is relocated at 0xAff6D000
but in reality it is at 0x8ff6D000 an the relocation can potentially 
override data already existing there.
Don't you think this is a wrong behaviour?
Thanks
Regards
Luca