From owner-freebsd-ppc@FreeBSD.ORG Sun Feb 22 03:11:24 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B20824F0 for ; Sun, 22 Feb 2015 03:11:24 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4EEF4E for ; Sun, 22 Feb 2015 03:11:24 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t1M3BFqa023285 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 21 Feb 2015 19:11:16 -0800 Message-ID: <54E948D3.2050201@freebsd.org> Date: Sat, 21 Feb 2015 19:11:15 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD PowerPC ML Subject: New 64-bit pmap Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYd+VMvhqDwUyAw2T4nCHgeGgzbR5K1C6Uuk944FoIVMl4BpvL9yW7bff+yh7DtpcHd30I/T9admsX/oDKAJmy3ZEKdwIAvAwc= X-Sonic-ID: C;zoeddkC65BGntUIUj30JFw== M;2pUZd0C65BGntUIUj30JFw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 03:11:24 -0000 I wrote a new memory management implementation for 64-bit PPC systems last week to get greater concurrency on big SMP systems. On a 32-thread POWER8 system, this results in a factor of two speedup in buildworld time. Smaller systems should see little change. Since this is a nearly ground-up rewrite of the pmap layer, I'd appreciate any testing before pushing the code into HEAD. The patch is at http://people.freebsd.org/~nwhitehorn/ppc64-new-pmap.diff. -Nathan From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 23 11:06:07 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55F73DA3 for ; Mon, 23 Feb 2015 11:06:07 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11599254 for ; Mon, 23 Feb 2015 11:06:05 +0000 (UTC) Received: (qmail 4964 invoked from network); 23 Feb 2015 11:05:59 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 Feb 2015 11:05:59 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 23 Feb 2015 06:05:59 -0500 (EST) Received: (qmail 7839 invoked from network); 23 Feb 2015 11:05:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Feb 2015 11:05:59 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 5A7B41C43B2; Mon, 23 Feb 2015 03:05:57 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Darwin ABI and its use of stw r0, 8(%r1) using callers %r1 value vs. ofwcall's code Message-Id: Date: Mon, 23 Feb 2015 03:05:57 -0800 To: FreeBSD PowerPC ML , Nathan Whitehorn Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 11:06:07 -0000 The compiled BootX code for calling openfirmawre for its _Peer use (as = one of many examples) does %r1 related code that looks like the = following. This code is here just for illustrating the Darwin ABI usage = as it suggests what APple's openfirmware might be expected (or at be = least allowed) to do itself when it is called, much liek when _Peer is = called. _Peer: mfspr r0,lr ... /* no use of %r1 until... */ stw r0,0x8(r1) /* Note the 8(%r1) usage on the so far unchanged %r1 = */ stwu r1,-0x90(r1) /* Here %r1 is finally changed */ ... /* no %r1 changes */ addi r3,r1,0x38 ... /* no %r1 changes */ mtspr ctr,r9 or r12,r9,r9 /* %r9 referencing the openfirmware address to jump to = */ bctrl ... /* Just for completness, not essential to my point... */ lwz r0,0x48(r1) /* the success case's return value extraction */ addi r1,r1,0x90 or r3,r0,r0 lwz r0,0x8(r1) mtspr lr,r0 blr The position 8(%r1) in the stw is based on the caller's %r1 value in = this standard Darwin ABI calling sequence. The following code from ofwcall64.S (-r277335 but the usage is not new) = has used that same 8(%r1) position relative to the final value that it = gives %r1 just before calling into openfirmware: /* Get OF stack pointer */ ld %r7,TOC_REF(ofwstk)(%r2) addi %r7,%r7,OFWSTKSZ-32 ... mr %r1,%r7 std %r5,8(%r1) /* Save real stack pointer */ ... /* no %r1 changes */ /* Finally, branch to OF */ mtctr %r4 bctrl At this point OF would be allowed to store the lr to 8(%r1) before it = changes or records %r1 if it followed just the Darwin ABI, just like the = code above does. That would replace the "std %r5,8(%r1)" value that was = assigned in ofwcall64.S. This may partially explain the corrupted %r1 that I've sometimes = observed when openfirmware returns. (But see later notes.) The only reason that this works as well as it does is that (G5 Quad-Core = PowerMac) openfirmware protects itself before potentially executing any = normal Darwin ABI code, including special code that in part records %r1 = as it came from the caller (x/i notation): or r2,r0,r2, addis r2,r0,-x49 ori r2,r2,0xf000 /* so %r2:=3D0xFFB7F000 */ std r1,r2,0x8, /* %r1 saved to have a special, separate copy = */ std r0,r2,0x10, mfspr r0,lr std r0,r2,0x120, mfmsr r1 std r1,r2,0x108, (Side comment: It would not be good to call the entry point recursively = in any form.) Openfirmware also carefully saves the 64-bit lr value and the 64-bit = msr. My guess is that it has its own transition between potential 64 bit = code and the 32 bit environment going in and for returning (usually?). = It may even use the msr value to change behavior for being called form = 32-bit vs. 64-bit contexts to some degree. Unfortunately I can not tell (yet?) if openfirmware always restores/uses = what it saved for returning or not. It may be that it sometimes does and = sometimes does not. So far I've identified only the save side of things. Should the PowerMac code have this Darwin ABI conflict and depend on = Apple's openfirmware having an extra non-ABI layer that translates back = and forth from/to 64-bit environments? If it is to depend on such, then = why appear to have a full transition to a 32 bit context before calling = into openfirmware? (There easily could be evidence that Im not familiar = with.) It is even possible that openfirmware is detecting that it was not = called from a 64 bit context and so is doing things that are = inappropriate in response. A different point for the relocatable powerpc64 kernel is that = openfirmware might not tolerate the instruction after /* Finally, branch to OF */ mtctr %r4 bctrl being outside the 32 bit addressing range unless openfirmware always has = a clean transition back to 64-bit calling contexts. This could be a reason to either have a 64-bit calling context if it is = supported or to disallow such a large relocation on PowerMac G5's. Yet a different point is the BootX code use of %r12 (which follows the = Darwin ABI): mtspr ctr,r9 or r12,r9,r9 /* %r9 referencing the openfirmware address to jump to = */ bctrl Every indirect call to openfirmware sets %r12 to the called address even = when it is not necessary to the local jump code to the called routine = and so only the called code would potentially use the %r12 value. The wording I have for the description of Darwin ABI's rule is = consistent with the caller possibly caring for some reason: "... wherein a routine that branches indirectly to another routine must = store the target of the call in GPR12. No special purpose for a routine = that has been called directly." (Mac OS X Internals, Amit Singh). The = code generated for BootX certainly is following that %r12-use rule when = it calls openfirmware. So for PowerMac's it may be that %r12 should be used instead of %r4 in = teh following code. /* read client interface handler */ ld %r4,TOC_REF(openfirmware_entry)(%r2) ld %r4,0(%r4) ... /* Finally, branch to OF */ mtctr %r4 bctrl =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 23 12:29:58 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D518A0 for ; Mon, 23 Feb 2015 12:29:58 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F78C66 for ; Mon, 23 Feb 2015 12:29:58 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id bs8so16220412wib.4 for ; Mon, 23 Feb 2015 04:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=undRr4HVWSn9XHXiJtXH/kNmEj9YW4uXVE8vUmZgXu4=; b=yhd+ZdTk9chfQA2WqPBCMLxArO4mMco7RFQUP/ikWh2MdjHtMppesGdDypqPaN8P37 d4+c+XqqTdWytoig14I+Djmm6L/CQrCdPOBONxq+9aHY/1owOD28pewaD6IMXK2je3lx XkOtzWzuwNtlntRDQrv+omTTYl892UEPkjghYt6WZ4gbEuURN2xC3apLFWCjaXwdgPvi gT8BVxz05WlBFoW9uVRd14/CrmhXoWbKGWDZElFGgLcR2+hqkR04qlKGiQkmzdQZtWk8 mbMiWR7n6fG3Cu2PgG/dQ39U3e9Z8EA76MUm+oqvZw+FIowIbtO4vtbZepWOSUCcYTEi 1/LQ== MIME-Version: 1.0 X-Received: by 10.180.206.14 with SMTP id lk14mr20197446wic.71.1424694596480; Mon, 23 Feb 2015 04:29:56 -0800 (PST) Received: by 10.28.13.131 with HTTP; Mon, 23 Feb 2015 04:29:56 -0800 (PST) Date: Mon, 23 Feb 2015 13:29:56 +0100 Message-ID: Subject: FreeBSD vs. laptop features From: Matthias Schojohann To: freebsd-ppc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 12:29:59 -0000 Hi, how can i 1) tell my laptop to turn the screen off? vidcontrol -t 15 doesn't do anything it seems. 2) disable the feature that my laptop turns off when closing it? I know not recommended because of heat etc. I'm on FreeBSD 10.0-RELEASE and it's an iBook G4 Cheers, Matt From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 23 14:30:13 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B376105 for ; Mon, 23 Feb 2015 14:30:13 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB9B6AC9 for ; Mon, 23 Feb 2015 14:30:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YPu1M-0005FC-Mr for freebsd-ppc@freebsd.org; Mon, 23 Feb 2015 15:30:04 +0100 Received: from 46.13.138.74 ([46.13.138.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 15:30:04 +0100 Received: from logout128 by 46.13.138.74 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Feb 2015 15:30:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ppc@freebsd.org From: Martin Kukac Subject: FreeBSD 10.1 on PowerMac 7,3 Date: Mon, 23 Feb 2015 14:38:04 +0100 Lines: 35 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 46.13.138.74 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:30:13 -0000 Hello, I have PowerMac G5 2.0DP (PM7,3 but has PowerPC 970 (version 2.2) CPU not the fx ones) and I'm trying to make FreeBSD working on it. I'm sorry if problems I will mention in the following text were already discussed here, but I didn't find answers, when I searched through the list. Install was quite straightforward, though I had to download USB image and boot from USB, because ISO did always hang during boot. The only minor problem here were inverted colors in virtual consoles, which persists even in the installed systems, but I can live with that, as I mainly work in X, where colors are OK. The first problem I have is power/thermal management - CPUs seem to be stuck on 1300MHz instead of 2000MHz and what's bigger problem - I don't think fans work the way they should. Sysctl output displays constant rpm on all fans except the "backside" one and from what I saw inside the case system really does not modify speed of any other fan. Temperature of both CPUs seems to be constant as well, I have never seen different temperature than that right after the boot. This is a problem, because during Xorg compilation system warned me that the U3 has reached 92C and I'm a bit afraid about the machine. The second problem is (maybe it has something to do with inverted colors in terminal) that after I start X session, all virtual consoles become broken. Even though input still works, text is not readable, it looks like this: http://i61.tinypic.com/wnq7p.jpg The card is Radeon 9800 Pro. Any suggestions? I wanted to replace Debian on my machine with FreeBSD and I didn't expect to end this soon. Thanks, Martin From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 23 17:23:51 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C1067DE for ; Mon, 23 Feb 2015 17:23:51 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1B081C4 for ; Mon, 23 Feb 2015 17:23:50 +0000 (UTC) Received: by labgm9 with SMTP id gm9so20092559lab.2 for ; Mon, 23 Feb 2015 09:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lPb0w9tJa/BBlK4YtCweFre8My6NDCLxDXIKY77NEeg=; b=q3xMg/qexRoSW1o64hSslXT0JwPlF0J8vOKoamS1/YGxACcTCjX4Kb/b/usKYHlxip Mo/bsaLnZfrsim7jzQK3K6O3UM12vwJTlGOXQolEDKyI2TGr7kKnpd+wNCJhNv6oP+6U XlO/2A12pvimKm7MlFvlFiUXWGAH5KDdG0Zg4mxDqOluWzqErdpaK3NIpWEa3WH6ItiS UVKtR3IQ0/zPISHZ5QJnOwnppNILhpzoF5CHnX6j40rpdPKdx6NM8DbHqOPllE1CRZDp C4ZUcGO5ABpw1EKz9sG5UEH9xeQWbIGTRk6tkL/czcG4/07G/8tIAvwpWml/61LeChSC afZQ== MIME-Version: 1.0 X-Received: by 10.112.62.135 with SMTP id y7mr10703700lbr.50.1424712228759; Mon, 23 Feb 2015 09:23:48 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.25.145.65 with HTTP; Mon, 23 Feb 2015 09:23:48 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2015 09:23:48 -0800 X-Google-Sender-Auth: WgC95pek904o51aetv-eLpwZt8M Message-ID: Subject: Re: FreeBSD vs. laptop features From: Justin Hibbits To: Matthias Schojohann Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 17:23:51 -0000 Hi Matt, On Mon, Feb 23, 2015 at 4:29 AM, Matthias Schojohann wrote: > Hi, > > how can i > > 1) tell my laptop to turn the screen off? vidcontrol -t 15 doesn't do > anything it seems. There's currently no way that I know of to turn the screen off. However, you can set the brightness to 0, using: sysctl dev.backlight.0.level=0 It may not be too difficult to add the 'screen off' capability to vt, I can look into that later (you can file a bugzilla for it, so it doesn't get lost, if you'd like). > 2) disable the feature that my laptop turns off when closing it? I know not > recommended because of heat etc. This is handled in /etc/devd/apple.conf , under the second block. - Justin From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 23 21:14:21 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EF2B826; Mon, 23 Feb 2015 21:14:21 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12C2EF5F; Mon, 23 Feb 2015 21:14:19 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id t1NLE7E4081366; Mon, 23 Feb 2015 22:14:10 +0100 (CET) (envelope-from andreast-list@fgznet.ch) Message-ID: <54EB9828.5070104@fgznet.ch> Date: Mon, 23 Feb 2015 22:14:16 +0100 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nathan Whitehorn , FreeBSD PowerPC ML Subject: Re: New 64-bit pmap References: <54E948D3.2050201@freebsd.org> In-Reply-To: <54E948D3.2050201@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 21:14:21 -0000 On 22.02.15 04:11, Nathan Whitehorn wrote: > I wrote a new memory management implementation for 64-bit PPC systems > last week to get greater concurrency on big SMP systems. On a 32-thread > POWER8 system, this results in a factor of two speedup in buildworld > time. Smaller systems should see little change. > > Since this is a nearly ground-up rewrite of the pmap layer, I'd > appreciate any testing before pushing the code into HEAD. The patch is > at http://people.freebsd.org/~nwhitehorn/ppc64-new-pmap.diff. For the record. Tested on: - G5 QUAD -> stable. - POWER5+ -> stable. - G5 DUAL 32-bit -> stable. The test contained buildworld hammering and gcc bootstrapping. Thanks Nathan for your work! Andreas From owner-freebsd-ppc@FreeBSD.ORG Tue Feb 24 05:33:53 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2247B864 for ; Tue, 24 Feb 2015 05:33:53 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A647BCD8 for ; Tue, 24 Feb 2015 05:33:52 +0000 (UTC) Received: by wghl18 with SMTP id l18so3000702wgh.7 for ; Mon, 23 Feb 2015 21:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PRuNvK53BSLGNlBpqTPCOtaB/bZngkcY4fxFkbygvAE=; b=ECfeaUMGB4QRIvKWPiNd8t1aJhveOZosXhu+XHb283cLPp6Oe18evkqzJHr/f0kMwK gddNzu1pX3A5pyBaT6F1ed+van22R3fH82eO1AQ7vwcIhRmHmaiOQfqjngIu5a7aTR7d hJyL0+sRKLOgjmk8bbBwE5G5xQNH5fV3Sq1ZxXHkk6P/BmhP2obXkEW92EmD9bhsORNR dJO/zitckBHscSi/G8PqzpINzjfH7KtwiKiD350dx9X1uupZBwl1aWDHtTBRvJcY97fA 0dITkf1jVScapI2PJjBvhynvHUehxf+smyvaVmDxQULgW7Tc5KghpGlw0Ne99QF6TTLj W6zw== MIME-Version: 1.0 X-Received: by 10.194.78.231 with SMTP id e7mr28445565wjx.33.1424756030950; Mon, 23 Feb 2015 21:33:50 -0800 (PST) Received: by 10.28.13.131 with HTTP; Mon, 23 Feb 2015 21:33:50 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 06:33:50 +0100 Message-ID: Subject: Re: FreeBSD vs. laptop features From: Matthias Schojohann To: Justin Hibbits Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 05:33:53 -0000 Thank you very much - i commented the whole "lid" block out. For the screen brightness: it doesn't seem to do much...also tried level 10, always stays the same. If the brightness to 0 works, i could set that as an option :) Am i missing something? Matt 2015-02-23 18:23 GMT+01:00 Justin Hibbits : > Hi Matt, > > On Mon, Feb 23, 2015 at 4:29 AM, Matthias Schojohann > wrote: > > Hi, > > > > how can i > > > > 1) tell my laptop to turn the screen off? vidcontrol -t 15 doesn't do > > anything it seems. > > There's currently no way that I know of to turn the screen off. > However, you can set the brightness to 0, using: > > sysctl dev.backlight.0.level=0 > > It may not be too difficult to add the 'screen off' capability to vt, > I can look into that later (you can file a bugzilla for it, so it > doesn't get lost, if you'd like). > > > 2) disable the feature that my laptop turns off when closing it? I know > not > > recommended because of heat etc. > > This is handled in /etc/devd/apple.conf , under the second block. > > - Justin > From owner-freebsd-ppc@FreeBSD.ORG Tue Feb 24 23:20:03 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA30D2E3 for ; Tue, 24 Feb 2015 23:20:03 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF98BA8F for ; Tue, 24 Feb 2015 23:20:03 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t1ONJkT2008425 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Feb 2015 15:19:47 -0800 Message-ID: <54ED0712.9050900@freebsd.org> Date: Tue, 24 Feb 2015 15:19:46 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andreas Tobler , FreeBSD PowerPC ML Subject: Re: New 64-bit pmap References: <54E948D3.2050201@freebsd.org> <54EB9828.5070104@fgznet.ch> In-Reply-To: <54EB9828.5070104@fgznet.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaISvgFiGuxSbbJvKXK8LgfRvjgoftGiWpWJp2SLDNOlyU0tCioYg5is1E8XjUhHH2InO9rqafAxh+QNGEzIchumv95PjDlTCU= X-Sonic-ID: C;xjxin3u85BG/tO8Jj30JFw== M;cNWcn3u85BG/tO8Jj30JFw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 23:20:03 -0000 On 02/23/15 13:14, Andreas Tobler wrote: > On 22.02.15 04:11, Nathan Whitehorn wrote: >> I wrote a new memory management implementation for 64-bit PPC systems >> last week to get greater concurrency on big SMP systems. On a 32-thread >> POWER8 system, this results in a factor of two speedup in buildworld >> time. Smaller systems should see little change. >> >> Since this is a nearly ground-up rewrite of the pmap layer, I'd >> appreciate any testing before pushing the code into HEAD. The patch is >> at http://people.freebsd.org/~nwhitehorn/ppc64-new-pmap.diff. > > For the record. > > Tested on: > - G5 QUAD -> stable. > - POWER5+ -> stable. > - G5 DUAL 32-bit -> stable. > > The test contained buildworld hammering and gcc bootstrapping. > > Thanks Nathan for your work! > > Andreas Thanks! This is committed to HEAD now. Please post to the list if you run into any difficulties. -Nathan From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 27 01:23:36 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C05E8CC8 for ; Fri, 27 Feb 2015 01:23:36 +0000 (UTC) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79798829 for ; Fri, 27 Feb 2015 01:23:36 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id n8so10717153qaq.3 for ; Thu, 26 Feb 2015 17:23:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ENYaz2sDbTvI5HW++a8YfGdk73/9a4/Glh8cC3Kr+gU=; b=XpIF0T1GagRVKjun7bBAwCYnBNnLMpZiQJ2M7Zjg49JJ4sXvAIPn9tRVR6UEAW4OPa 0xyBAIgkyFEKhW54N2YGCvzlRW526bwkJHCVKvRNWZJi5gTnRDpEZTV94TokLHEDHNR4 JS2ZSbTK7hb1IoLjaucAbr3HXYrd2Y/0hvdiluOeLuFG41SVf76qiSPpnv9tz8SuvBq/ /cTcffDCLQCFZeqOzXDdDXT8GMWVQVbessUrSSxefGZTOOhesJrcPnmmJmE6K1WmguQI D0/a8mdJ8ZgXKmUeGgr7VBsSpTwnm2HzyrSWm5A0VrqkwlejWSoXwR4945LrIEpMvlj2 UA+Q== X-Gm-Message-State: ALoCoQlCQ8Bx2tq6VTwgzW7impDeQHz/SXloOPPzWyTk/Xd0pc6S0KxSlvV2fS3rBteeoeSbhOBS X-Received: by 10.140.106.72 with SMTP id d66mr23254140qgf.60.1425000209059; Thu, 26 Feb 2015 17:23:29 -0800 (PST) Received: from blackrose.teamblackfox.local (pool-108-4-9-48.rcmdva.fios.verizon.net. [108.4.9.48]) by mx.google.com with ESMTPSA id t51sm1695059qge.28.2015.02.26.17.23.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Feb 2015 17:23:28 -0800 (PST) Message-ID: <54EFC70F.7080005@teamblackfox.com> Date: Thu, 26 Feb 2015 20:23:27 -0500 From: Black Fox User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: FreeBSD on POWER6 p520 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-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, 27 Feb 2015 01:23:36 -0000 Hello, Looking at adding a POWER6 machine to my lineup, I was eyeing the p520. I like FreeBSD, so I wanted to see if it was possible to run it on this server, and if so, how good is the support? Thanks, The Black Fox From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 27 05:29:38 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F14A162E for ; Fri, 27 Feb 2015 05:29:38 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7E4B254 for ; Fri, 27 Feb 2015 05:29:38 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t1R5TVrk004708 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Feb 2015 21:29:31 -0800 Message-ID: <54F000BB.40906@freebsd.org> Date: Thu, 26 Feb 2015 21:29:31 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Black Fox , freebsd-ppc@freebsd.org Subject: Re: FreeBSD on POWER6 p520 References: <54EFC70F.7080005@teamblackfox.com> In-Reply-To: <54EFC70F.7080005@teamblackfox.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbtRh2/TlnJvbZfaMjIenWAhyil7zP0B0sIJW7GQdX/1xJq34ZcFJ+qdBaYo4nYZT6XCpKQoUPsFsxA3eAIf5TV3lc4YqaH+MI= X-Sonic-ID: C;QqYTm0G+5BGOm75YxQPdhw== M;jBdEm0G+5BGOm75YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-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, 27 Feb 2015 05:29:39 -0000 That should be reasonably well supported by the powerpc64 port. We at least run well on POWER8 and POWER5+ systems. The one potential issue of which I'm aware is that the on-board SCSI controller on some IBM systems doesn't have a driver yet. You may also have trouble if you want to run X, but that's probably moot for a server. -Nathan On 02/26/15 17:23, Black Fox wrote: > Hello, > > Looking at adding a POWER6 machine to my lineup, I was eyeing the > p520. I like FreeBSD, so I wanted to see if it was possible to run it > on this server, and if so, how good is the support? > > Thanks, > > The Black Fox > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Sat Feb 28 15:17:42 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85F37CA6 for ; Sat, 28 Feb 2015 15:17:42 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 428E495 for ; Sat, 28 Feb 2015 15:17:42 +0000 (UTC) Received: (qmail 14793 invoked from network); 28 Feb 2015 15:11:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Feb 2015 15:11:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 28 Feb 2015 10:11:01 -0500 (EST) Received: (qmail 32754 invoked from network); 28 Feb 2015 15:11:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Feb 2015 15:11:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 4E6051C43A6; Sat, 28 Feb 2015 07:10:58 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Large RAM Powermac G5 powerpc64 openfirmware entry point use: I seem to have removed the major/frequent boot problem(s) Message-Id: Date: Sat, 28 Feb 2015 07:10:59 -0800 To: FreeBSD PowerPC ML , Nathan Whitehorn Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 15:17:42 -0000 I have removed my re-try logic that I had in ofwcall because other = changes I've made got rid of the %r1/%r3 corruption issue that I used to = have so frequently when booting PowerMac G5s that have lots of RAM (8G, = 12G, or 16G). Also I'm no longer getting the specific .got area corruption that = authnone code was failing on when it used its %r2 to access various = things when I built with VERBOSE_SYSINIT. (It is hard to have evidence = that no corruption is happening anywhere.) I've done multiple "make -j 8 buildworld kernel && make installworked" = examples under the changes and have updated to 10.1-STABLE -r279201 = under these changes. I've done similarly for with and without = VERBOSE_SYSINIT and the like. I've done a half dozen build/install = reboot and use sequences. I've booted and used both a PowerMac11,2 and a Powermac7,2 from the same = SSD. (I do not have access to other PowerMac G5 variants.) (I've done no = investigation of analogous points yet for powerpc PowerMacs: only = powerpc64 usage of G5s.) [I would not claim that this addresses the less frequent boot failure = tracebacks that I've reported in the past: just the most frequent one = and the recent .got corruption evidence.] So what did I do? It was limited to openfirmware_core, ofw_sprg_prepare, = and ofwcall. The bias was to simplify the context involved in my = investigation, not to produce production FreeBSD code = structured/partitioned for general use. The below is not in the order of = investigation but is a description of the net result. I do not claim = that all the eliminations involved were necessary but I had less code to = worry about this way. 0) I've looked at some of the openfirmware entry point code to see what = appeared to be needed vs. not needed. 1) I've looked at some of the BootX code and what it compiles to see an = example of what was sufficient in that context. For sys/powerpc/ofw/ofwcall64.S... 2) Despite working in/with/on 10.1-STABLE I started from ofwcall64.S = from a recent 11.0-CURRENT, from after the powerpc64 kernel-relocation = changes. (And I used the matching sys/powerpc/include/asm.h update so = ofwcall64.S would compile in 10.1-STABLE.) 3) I removed things that I found to not be necessary: ofwstk and its use = (openfirmware does its own storage management for such things), use of = ofwmsr storage (msr being just locally in registers for my code, = SPRG's not directly used), saving and restoring unused non-volatile = registers (openfirmware does 64-bit save/restore of the non-volatile = registers that it uses). BootX also does nothing special for %r1 when = calling openfirmware. 4) I added/kept what was needed (possibly expressed differently): = forcing 32-bit mode before and putting msr back to its original status = after, putting back %r2's TOC value (openfirmware uses Darwin's rule = that %r2 is volatile/non-dedicated --no TOC use-- and it replaces r2's = value), sign extend %r3. 5) In ofwcall I followed all the ABI rules that I've learned of, both = FreeBSD powerpc64 and Darwin ABI rules (e.g., the %r12 indirect call = address rule). This includes covering %r1, cr, lr, %r14, %r15 = saves/restores back to caller's status. (%r14 and %r15 were used in my = ofwcall.) 6) My ofwcall does increment a count stored in memory if it sees a = changed %r1 when openfirmware returns. This allows checking if it ever = happened via kgdb. It also records the most recent such new %r1 value. = This part of the code I consider temporary a evidence gathering hack in = case problems eventually happen. For sys/powerpc/ofw/ofw_machdep.c ... 7) In ofw_sprg_prepare I eliminated the unnecessary SPRG register = handling, leaving only SPRG0 (for later restoring required FreeBSD = context) and SPRG3 (for restoring required Openfirmware context). 8) In/for openfirmware_core I eliminated all the trap vector = save/restore calls. If openfirmware needs any of its exception vector = code it seems to patch/unpatch as necessary. BootX also does not context = switch the vectors but just leaves its own in place. I also eliminated = the extern save_trap_init declaration and the save_trap_of storage. = Because ofwcall no longer had ofwmsr involved, I removed ofwmsr's extern = status so it would provide the definition for the link. (I did not = change the size or the positions assigned for the used parts of ofwmsr.) = Much of this was commenting-out activity. (Note: I choose to ignore that the trap vector save/restore calls have = code to disable the activity based on ofw_real_mode's value and make it = locally obvious that no such code was in use for my testing.) 9) I did not eliminate the now-otherwise-unused save_trap_init storage = or the ofw_save_trap_vec call from powerpc_init in = sys/powerpc/aim/machdep.c. But I could have --at which point = ofw_save_trap_vec could also have been eliminated. Also I'm not = reporting on temporary evidence/investigation code that I had at various = times but have removed over time. The result was the frequent boot crashes disappeared and I've no = evidence so far of %r1/%r3 corruption or the .got corruption that I'd = reported on earlier. My openfirmware_core, ofw_sprg_prepare, and ofwcall are too PowerMac G5 = context-specific for general FreeBSD use. But they should well point to = a now-known way to improve booting for PowerMac G5's. Other/supporting notes: I finally figured out that the ddb code for x/i is incomplete for = Powerpc64. For example DDB's x/i calls mtmsrd an Illegal Instruction. One can see this if you have it decode ofwcall from memory and compare = to the source code. Because of this the decoding of the first instructions for the = openfirmware entry point (0xff846d78 starting address on the G5 = Quad-Core) is: or r2,r0,r2, addis r2,r0,-0x49 ori r2,r2,0xf000 /* so %r2:=3D0xFFB7F000: fixed address (32-bit = mode). */ std r1,r2,0x8, /* %r1 saved to have a special, separate copy */ std r0,r2,0x10, /* more saves to fixed locations */ mfspr r0,lr std r0,r2,0x120, /* more saves to fixed locations: return address = */ mfmsr r1 std r1,r2,0x108, /* more saves to fixed locations: msr */ rldicl r1,r1,0,1 /* clears the most significant %r1 bit */ 0x7c200164 (actually mtmsrd %r1) /* forces 32-bit mode */ isync Unfortunately for 64-bit mode at the start: %r2=3D0xFF...FFB7F000 and = std r1,r2,0x8, ends up rejecting the effective address. Apple does not = force 32-bit mode until a little later in the above. Thus ofwcall does = need to force 32-bit mode and return it back to normal, despite the msr = and other save/restore code that openfirmware has.=20 (I've not explored trying to set up a mapping for the involved 64-bit = effective address range in order to allow the translation of the 64-bit = addresses in openfirmware's %r2 above. With that it might be that 64-bit = mode could be left in place.) As far as I can tell this %r2 value and its use is the only reason that = FreeBSD needs to establish 32-bit mode before the call into = openfirmware. %r2 needs to be restored after openfirmware returns since openfirmware = is using the Darwin ABI where %r2 is non-volatile and non-dedicated (no = use of TOCs), as can be seen above. =3D=3D=3D Mark Millard markmi at dsl-only.net