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

[Peter Tyser]

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.

Best,
Peter