On Jul 22, 2009, at 10:47 AM, Peter Tyser wrote:
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?
It is at this point.
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...
I'd be fine if we want to add a CONFIG_ option to do the disable so board ports that need/want it can do it.
- k