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 <[email protected]> > >>>>> --- > >>>>> 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/[email protected]/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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
