[U-Boot] [PATCH 1/2 v2] 85xx: CONFIG_MP Boot Page Translation update

[Kumar Gala]

On Aug 7, 2009, at 3:57 PM, Peter Tyser wrote:

>
>>> diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
>>> index 76f02a4..53fc3be 100644
>>> --- a/cpu/mpc85xx/mp.c
>>> +++ b/cpu/mpc85xx/mp.c
>>> @@ -129,7 +129,7 @@ ulong get_spin_addr(void)
>>>
>>> 	ulong addr =
>>> 		(ulong)&__spin_table - (ulong)&__secondary_start_page;
>>> -	addr += 0xfffff000;
>>> +	addr += determine_mp_bootpg();
>>
>> changing this has some issues.  We expect the the address that the
>> spin table is at to be marked cache-inhibited.
>
> The secondary cores will be running with the spin table in
> cache-inhibited memory and it looks like Linux accesses the spin table
> after ioremapping it, so that flow looks OK.
>
> I assumed the e500 Coherency Module will ensure that the cpu_status()
> function should also be OK as is.
>
> It looks like I should have added 2 cache flushes to U-Boot's
> cpu_release(), like:
>
> --- a/cpu/mpc85xx/mp.c
> +++ b/cpu/mpc85xx/mp.c
> @@ -106,9 +106,11 @@ int cpu_release(int nr, int argc, char *argv[])
>        table[BOOT_ENTRY_ADDR_UPPER] = (u32)(boot_addr >> 32);
>
>        /* ensure all table updates complete before final address  
> write */
> -       eieio();
> +       ppcDcbf((unsigned long)table);
> +       asm("msync");
>
>        table[BOOT_ENTRY_ADDR_LOWER] = (u32)(boot_addr & 0xffffffff);
> +       ppcDcbf((unsigned long)table);
>
>        return 0;
> }
>
> I'll resubmit with the change above, let me know if I'm off base.

There's another issue with this, its possible that the location in  
memory is not mapped in the TLBs.  We typically max out @ 2G of DDR  
mapped (via the TLBs).  So what happens if we have 3G of DDR.

- k