From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Tyser Date: Wed, 22 Jul 2009 10:47:01 -0500 Subject: [U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP In-Reply-To: <1247070328.11207.207.camel@localhost.localdomain> References: <1246992188-28951-1-git-send-email-ptyser@xes-inc.com> <1247004785.11207.157.camel@localhost.localdomain> <1247006306.11207.165.camel@localhost.localdomain> <94120C8D-02FF-4E13-835C-8431E0C8CF39@kernel.crashing.org> <1247070328.11207.207.camel@localhost.localdomain> Message-ID: <1248277621.24163.68.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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