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