From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ellero Date: Fri, 01 Feb 2013 09:50:32 +0100 Subject: [U-Boot] [PATCH] arm: fix bug on relocation address In-Reply-To: <510AC112.2090409@myspectrum.nl> References: <1359642542-18998-1-git-send-email-lroluk@gmail.com> <510AC112.2090409@myspectrum.nl> Message-ID: <510B81D8.20700@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 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. I know how is the U-Boot memory map and I summarize it here (more or less, depending on board configuration): TOP of RAM ------------------------ Kernel Log Buffer --------------------------- Protected RAM --------------------------- TLB Table (32kB to 64 kB) --------------------------- LCD Frame Buffer --------------------------- Relocated U-Boot Code --------------------------- malloc area --------------------------- Board Info (struct bd_t) --------------------------- Global Data (struct gd_t) --------------------------- IRQ Stack --------------------------- Abort Stack --------------------------- ... 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. 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? Thanks Regards Luca