Date: Wed, 23 Apr 2008 11:14:38 -0500 From: Nathan Whitehorn <nathanw@uchicago.edu> To: grehan@freebsd.org Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU Message-ID: <480F606E.3000805@uchicago.edu> In-Reply-To: <48050FAC.6080407@freebsd.org> References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <4804ECBA.5030905@uchicago.edu> <48050FAC.6080407@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I just wanted to let everyone know that I just saw the FreeBSD copyright notice go by on my iMac G5 (it stills hangs right after the WITNESS warning). Apparently I'm on PPC kernel #160 at the moment... -Nathan Peter Grehan wrote: > Hi Nathan, > >>> You really can't use the existing MMU code. The G5 was the driving >>> factor to create the pmap indirection. >> Yeah, the bridge mode MMU is just different enough to be annoying. I'm >> using the existing code as a base, because (a) it's nice to have a >> template, and (b) most of the PTE handling stuff can be reused with >> s/struct pte/struct lpte and s/PTE/LPTE, and some changes to the hash >> function and PTE_EXEC bits. > > Also, you may want to use 64-bit move instructions to atomically update > PTEs in the hash table. > >> So you suggest saving OF's SDR1 and restoring it when we need to call >> in? I guess this would solve part of the problem (debugging output >> while initializing the MMU), but I'm sure sure I understand the real >> benefit to this. > > I don't think the existing trick of putting OFW in it's own pmap will > work. A full context switch, including SDR1, would give more confidence > that OFW callbacks will work since it will be running in the address > space it created. > >> So it should be generally true that all the local variables and >> statically allocated things in pmap_bootstrap() should have virtual >> addresses equal to their physical address? > > Yes, since at that point the kernel is running on a stack allocated in > BSS. See tmpstk in locore.S. > >> Also, going to real mode seems like kind of a hack, but I think it may >> be the best choice. > > I agree. Linux does it as well. > >>> - another 1:1 relic is the use of UMA_MD_SMALL_ALLOC. I talked with >>> Alan Cox a long time back about being able to dynamically determine >>> whether this could be used, though that is a fair amount of work. I >>> would like to see a single kernel for G3/4/5, but that may be asking >>> too much up front, especially given my lack of progress in achieving >>> this goal :) >> Well, once we have the page table set up, we can add a 1:1 mapping in >> certain places -- e.g. low memory -- by adding in a whole bunch of 4 >> KB pages. > > You have to be careful. A big advantage of the BAT mechanism is that a > page's mod/ref bits aren't touched. If you have multiple mappings, you > have to take care that you don't accidentally cause a page to be R/M'd > when it shouldn't. Page-zeroing is an example: if you had 1:1 mappings, > the page's R/M bits would have to be cleared after the zeroing. Or, make > the pmap code aware of this. > > later, > > Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?480F606E.3000805>