[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP

[Kumar Gala]

On Jul 7, 2009, at 5:38 PM, Peter Tyser wrote:

> On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
>> On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
>>
>>> On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
>>>> On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
>>>>
>>>>> Previously, boot page translation was enabled while U-Boot  
>>>>> executed.
>>>>> This resulted in the address range 0xfffff000 - 0xffffffff being
>>>>> translated to SDRAM which made the 0xfffffxxx address space  
>>>>> unusable
>>>>> for
>>>>> other peripherals.
>>>>>
>>>>> This change disables boot page translation after the secondary CPU
>>>>> cores
>>>>> have been initialized which allows the 0xfffffxxx address space to
>>>>> be
>>>>> properly accessed.
>>>>>
>>>>> Signed-off-by: Peter Tyser <ptyser at xes-inc.com>
>>>>> ---
>>>>> This was tested on the XPedite5370 which has flash mapped in the
>>>>> 0xfffffxxx adddress space.  I verified the flash was accessible
>>>>> as expected and Linux properly brought up 2 cores.
>>>>>
>>>>> I wasn't sure how the MPC8572 handled caching with respect to the
>>>>> boot
>>>>> page translation.  I didn't add any cache flushes/invalidates, but
>>>>> they
>>>>> may be necessary if the 0xfffffxxx range is not mapped as
>>>>> uncachable.
>>>>> Anyone at Freescale have any comments on this?
>>>>>
>>>>> Best,
>>>>> Peter
>>>>
>>>> I'm concerned about this because we specifically avoid the  
>>>> 0xfffff000
>>>> - 0xffffffff range since if we reset a core we want it to go  
>>>> through
>>>> boot page translation.  Can you explain what you are putting at  
>>>> that
>>>> address?
>>>
>>> Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB
>>> flashes - 1 from 0xf0000000-0xf7f00000 and the other from  
>>> 0xf8000000 -
>>> 0xffffffff.  We've used this convention for a while, before we  
>>> started
>>> using MPC8572s.
>>>
>>> U-Boot is always stored at in the flash at 0xfff80000 on the
>>> MPC85xx-based boards we support.  Thus I couldn't reprogram U-Boot
>>> when
>>> CONFIG_MP was defined since the top 4K of flash was really accessing
>>> SDRAM because of the boot page translation.
>>>
>>> With this patch boot page translation is still used to bring up the
>>> secondary cores on power on.  This change just makes it so that boot
>>> page translation is disabled after the other cores are brought up.
>>
>> I understand what the patch does.  It just removes the capability of
>> soft-resetting a core back into the boot translation code.  I
>> understand your problem I'm just not keen on solving it by completely
>> disabling boot translation.
>>
>> We had a similar memory map and I moved away from it because of the
>> reset vector issues.  Additionally, things like >4G of memory also
>> start creeping up.
>
> I'm not super familiar with how the MP support in U-Boot is used.   
> Would
> you be resetting a secondary core for debug purposes?  Or is there an
> example of when you'd reset one in normal operation?  I thought normal
> operation was to use the "cpu release" command, or to let the OS
> manually take the secondary cores out of their wait loops.
>
> What if I spruced up cpu_reset() to temporarily re-enable boot page
> translation, then disabled it again?  (And maybe re-initialized the  
> cpus
> MP table so that it could properly ack the primary core similar to in
> pq3_mp_up().
>
> It seems somewhat dirty to me to constantly keep boot page translation
> enabled, even when its not needed.  Especially since it would  
> require us
> to change our memory map, environment variable scripts, documentation,
> etc on all our boards:)
>
> I'd be happy to look into an alternate workaround if you have an idea
> for a cleaner implementation.

The idea is after u-boot if you soft-reset a core that it would go  
back into the spin table code.  U-boot is long gone at this point.

- k