From owner-freebsd-ppc@FreeBSD.ORG Tue Dec 19 00:25:04 2006 Return-Path: X-Original-To: freebsd-ppc@freebsd.org Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A41B16A403 for ; Tue, 19 Dec 2006 00:25:04 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61DB743C9F for ; Tue, 19 Dec 2006 00:25:03 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CKK09247 (AUTH peterg@ptree32.com.au); Tue, 19 Dec 2006 10:24:47 +1000 (EST) Message-ID: <4587316C.1070500@freebsd.org> Date: Mon, 18 Dec 2006 16:25:16 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Andrew Turner References: <20061218104841.72ba51ea@hermies.int.fubar.geek.nz> <4585CCC1.7050005@freebsd.org> <20061218222327.308dca53@hermies.int.fubar.geek.nz> <4586CA29.10803@freebsd.org> <20061219113230.34182787@hermies.int.fubar.geek.nz> In-Reply-To: <20061219113230.34182787@hermies.int.fubar.geek.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: grehan@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: FreeBSD on an Efika X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 00:25:04 -0000 Hi Andrew, >>Do you end up in the trap handler if you touch msgbuf ? > > Not as far as I can tell. .. >> pmap_kenter() is fundamental to the operation of the system and >>probably OK, so something else must be afoot. A quick re-read of the G2 core manual gives the answer. I was under the impression that the G2 was similar to the G3/G4 in that it did a hardware table walk on TLB miss, but, that's not right. It's up to software to handle a miss, using the itlb/dtlb-load/dtlb-store exception vectors. See 6.5.2.1 of the G2 Core ref manual: http://www.freescale.com/files/32bit/doc/ref_manual/G2CORERM.pdf Since the relevant trap vectors aren't initialised, they will be either 0 or whatever OpenFirmware left in there, most likely resulting in an endless loop of unhandled exceptions. The path I'd suggest is a) Put in exception handlers at 0x1000, 0x1100 and 0x1200 to catch the TLB miss e.g. bcopy(&trapcode, (void *)0x1000, (size_t)&trapsize); As you can see in , the existing vector definition don't match these, or are incorrect for the G2 core. b) In powerpc/trap.c, panic if those vectors are hit to verify that touching a virtual address will cause one of these exceptions. Do it for both data read and write. c) Manually install a TLB to cover the first page of the message buffer to see if this allows a read/write without a trap occuring. d) Now the fun part: for those exceptions, change the handler to point to code that will walk the PTEG table and insert a TLB if found. If not found, fake a DSI or ISI trap. This can be done in C, though you will have to be careful to use a pre-allocated stack and not touch any virtual addresses while doing this, since it could result in another fault. later, Peter.