[U-Boot] [PATCH] DEBUG 8xxx cpu_numcores

[Peter Tyser]

On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote:
> 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 at 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 at xes-inc.com>
> >> Date:   Mon Sep 21 11:20:27 2009 -0500
> >> 
> >>  ppc: Remove board.c relocation fixups
> >> 
> >>  Signed-off-by: Peter Tyser <ptyser at 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?

Either near the top of lib_ppc/board.c:board_init_r() or possibly in
cpu/mpc8[5|6]xx/cpu_init.c:cpu_init_r().

I added Ed's debug, and it looks like cpu_numcores() is called many
times prior to relocation though.  So I'd assume we can't just call it
once after relocation.

So the options are:
1. Add "gd->cpu +=" fixup to lib_ppc/board.c where it used to be (We
can't put the manual fixup in cpu/mpc8[5|6]xx/cpu_init.c since that code
won't have the relocation offset needed for fixing up).
2. Re-call probecpu() in lib_ppc/board.c
3. Re-call probecpu() in cpu/mpc8[5|6]xx/cpu_init.c

I'd slightly lean towards #1, but its not particularly pretty either...

Peter