On Dec 15, 2009, at 11:29 AM, Peter Tyser wrote: > 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.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? >> >> 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...
I'm for #1 as well. Can you send a clean patch w/signoff. I'll test it right away. - k _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot