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

[Kumar Gala]

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.

- k