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.swarth...@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 <pty...@xes-inc.com>
> Date: Mon Sep 21 11:20:27 2009 -0500
>
> ppc: Remove board.c relocation fixups
>
> Signed-off-by: Peter Tyser <pty...@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?
Peter
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
