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

[Luca Ellero]

Hi,

On 01/02/2013 11.07, Heiko Schocher wrote:
> 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 at gmail.com>
>>>> Cc: Albert Aribaud <albert.u.boot at aribaud.net>
>>>> Cc: Heiko Schocher <hs at 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.
>

That's exactly the point!!!
As far as I know iMX53 _can't_ physically move banks to other addresses.
And likely there are some other architectures that have the same behaviour.
Maybe someone on the list can confirm this.
Bye
Luca