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