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

[Peter Tyser <ptyser@xes-inc.com>]

Hi Kumar,

> > >> 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 at 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...

Any feedback on my last email above, or is disabling boot page
translation just a no-go?

Or is there an more ideal alternative?  I really don't want to change up
the memory map on all our Freescale boards, documentation, dts files,
etc because of an optional 4KB chunk of memory space:)  I'm more than
willing to implement a different workaround if it means we can keep our
current memory map...

Thanks,
Peter