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

[Kumar Gala]

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.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...

I'm for #1 as well.  Can you send a clean patch w/signoff.  I'll test it right away.

- k