On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser ptyser@xes-inc.com
...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
gd->cpu += gd->reloc_off;-#endif
Peter, Joakim,
any suggestions on how to properly fix this?
Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups.
Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey.
Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/** The cpu pointer is set to an address in flash prior to relocation.* We need to update it to point to the same CPU entry in RAM.*/gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;+#endif
#ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif
What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation?
Where would we call it if it was after relocation?
- k