From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ellero Date: Thu, 07 Feb 2013 10:07:33 +0100 Subject: [U-Boot] [PATCH] arm: fix bug on relocation address In-Reply-To: <510B8F94.3080401@gmail.com> References: <1359642542-18998-1-git-send-email-lroluk@gmail.com> <510AC112.2090409@myspectrum.nl> <510B81D8.20700@gmail.com> <510B93E8.5070701@denx.de> <510B8F94.3080401@gmail.com> Message-ID: <51136ED5.8080507@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 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 >>>>> 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 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