From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ellero Date: Fri, 01 Feb 2013 10:49:08 +0100 Subject: [U-Boot] [PATCH] arm: fix bug on relocation address In-Reply-To: <510B93E8.5070701@denx.de> References: <1359642542-18998-1-git-send-email-lroluk@gmail.com> <510AC112.2090409@myspectrum.nl> <510B81D8.20700@gmail.com> <510B93E8.5070701@denx.de> Message-ID: <510B8F94.3080401@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>> Cc: Albert Aribaud >>>> Cc: Heiko Schocher >>>> --- >>>> >>>> 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