[U-Boot] [PATCH] arm: fix bug on relocation address
Heiko Schocher
hs at denx.de
Fri Feb 1 11:07:36 CET 2013
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.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
More information about the U-Boot
mailing list