From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 17 03:34:07 2003 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C958216A4B3 for ; Fri, 17 Oct 2003 03:34:07 -0700 (PDT) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F8CB43F93 for ; Fri, 17 Oct 2003 03:34:06 -0700 (PDT) (envelope-from grehan@freebsd.org) Received: from freebsd.org (CPE-203-45-244-178.qld.bigpond.net.au [203.45.244.178]) by dommail.onthenet.com.au (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id ABU59808 (AUTH peterg@ptree32.com.au); Fri, 17 Oct 2003 20:33:56 +1000 (EST) Sender: grehan@dommail.onthenet.com.au Message-ID: <3F8FC5B7.86989E0B@freebsd.org> Date: Fri, 17 Oct 2003 20:34:31 +1000 From: Peter Grehan X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin References: <3F8CAFAE.6260CFCF@freebsd.org> <20031015044706.GA787@blarf.homeip.net> <3F8CE205.5CB0B9E0@freebsd.org> <16269.25586.238272.357023@grasshopper.cs.duke.edu> <16270.38736.984138.190456@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Alex Zepeda cc: freebsd-ppc@freebsd.org Subject: Re: FYI: rudimentary loader for ppcbug-based systems X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2003 10:34:07 -0000 > > which is why I think there is a reasonable chance of getting a GENERIC ppc > > That would be great. I'm not trying to discourage this, I'm just > trying to correct what appear to be some misconceptions about the > alpha port, or perhaps are my misconceptions about ppc hardware. > Will one pmap module work for all ppc platforms? Does the TLB look > the same everywhere? The same pmap will work for 603e, G2 (i.e. 824x), G3 and G4, but not for the MPC8xx or IBM 4xx processors. Also, some G3 and G4 models allow the hash table lookup to be disabled, and that might be worth investigating for performance reasons, and to have an implementation for the 8xx/4xx CPUs. So, it might be worth making this a run-time switch. There are TLB routines that are CPU independent, but any of the models that allow s/w TLB miss have CPU-specific instructions to allow TLB refill. The 8xx/4xx CPUs don't have BAT registers, the 603e and some G3/G4s have 4 BATs, while other G3/G4s have 8 BATs, and some G4s have an extended BAT that can map up to 4G. The current port is dependent on BATs to direct-map physical memory, so BAT emulation with locked TLBs may have to be done on the 8xx/4xx CPUs. I'd like to have a kernel that can take advantage of CPU-specific features at run-time, rather than having to conditionally-compile for each CPU model, or having a lowest-common denominator GENERIC. later, Peter.