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 <lro...@gmail.com> >>> Cc: Albert Aribaud <albert.u.b...@aribaud.net> >>> Cc: Heiko Schocher <h...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
