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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
