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

[Luca Ellero <lroluk@gmail.com>]

Hi all,

On 01/02/2013 10.49, Luca Ellero wrote:
> 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@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.
>>
>
> 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

Any news here?
If this patch isn't the proper way to fix this misbehaviour, please 
suggest some other way to correct it. I'm a bit scary of viewing code 
running in "not-existing" addresses :-)
Thanks
Regards
Luca