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

[Heiko Schocher <hs@denx.de>]

Hello Luce,

Am 01.02.2013 09:50, schrieb Luca Ellero:
> 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.

You have 2 memory banks which are not contiguos.

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

Here you have a gap from 0x90000000 - 0xafffffff between the two banks,
which U-Boot currently not supports ...

> 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?

This wrong behaviour results because you use U-Boot in a
configuration, which U-Boot currently not handle correct resp.
does not support ...

Why you need such a memory configuration?

I suggest to move the second bank (if possible) to 0x90000000
and you have a contiguos memory, and U-Boot should work fine.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany