From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 13:26:21 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509BD106566C for ; Tue, 15 Apr 2008 13:26:21 +0000 (UTC) (envelope-from nathanw@uchicago.edu) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 264B18FC17 for ; Tue, 15 Apr 2008 13:26:21 +0000 (UTC) (envelope-from nathanw@uchicago.edu) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <0JZD00B00BZWV900@smtpauth2.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Tue, 15 Apr 2008 08:26:20 -0500 (CDT) Received: from trantor.tachypleus.net ([76.201.159.245]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPSA id <0JZD00AFWBZVHK10@smtpauth2.wiscmail.wisc.edu> for freebsd-ppc@freebsd.org; Tue, 15 Apr 2008 08:26:19 -0500 (CDT) Date: Tue, 15 Apr 2008 08:30:59 -0500 From: Nathan Whitehorn To: freebsd-ppc@freebsd.org Message-id: <4804AE13.2060600@uchicago.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.159.245 X-Spam-PmxInfo: Server=avs-11, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.15.60825, SenderIP=76.201.159.245 User-Agent: Thunderbird 2.0.0.12 (X11/20080322) Subject: G5 Bridge-mode MMU 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, 15 Apr 2008 13:26:21 -0000 I'm trying to get G5 support going, and have run into an interesting problem while bootstrapping the MMU. Firmware loads the kernel in protected mode, and we have no BAT facility. Thus, the bootstrap allocator fails because low physical memory isn't 1:1 mapped. And we can't add this region to the page table, because the page table is what we are trying to allocate. And we can't even use the MMU's large page facility in bridge mode. One solution is to drop back to data real mode while the page table is allocated and set up. This seems to work ok, but requires that the kernel stack is mapped 1:1, which seems to be the case on my iMac G5. I'm not sure how reliable this assumption is, though. It's also irritating because any open firmware calls from real mode (e.g. printf()) make the machine hang up. The other solution is to prepare a temporary statically-allocated page table with enough mappings to map the kernel, OF, and the real page table, then switch to the dynamically allocated one. I'm not sure there is enough stack for this though, since we are so early in the boot process. It could be globally statically allocated, but that would pointlessly increase the kernel memory footprint of everyone with bridge support compiled into their kernels. Thoughts? -Nathan