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

Luca Ellero lroluk at gmail.com
Fri Feb 1 10:49:08 CET 2013


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


More information about the U-Boot mailing list