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

[Kumar Gala]

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?

- k