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

[Peter Tyser]

On Wed, 2009-07-08 at 10:52 -0500, Kumar Gala wrote:
> 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.

Are there common scenarios where a core would be reset after its already
booted an OS?  If an OS did need to soft-reset a secondary core,
shouldn't the OS be responsible for ensuring boot page translation is
enabled, its translating to the proper location, etc?  For example, I
imagine non-Linux OSes bring up secondary cores in different manners and
some wouldn't re-utilize U-Boot's boot page code located in SDRAM at
all, thus they wouldn't want the boot page translation always enabled.

It just seems less than ideal to have a chunk of memory space that
somewhat magically accesses a completely different, unintuitive address
space.  Someone else ran into the same issue already:
http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html

I realize there's a tradeoff between keeping the translation enabled vs
disabled, I'm just not familiar with how OSes utilize the secondary
cores to know what the downsides of disabling translation are...

Best,
Peter