From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 15:11:19 2014 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 772A897F for ; Fri, 10 Oct 2014 15:11:19 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 221E96E2 for ; Fri, 10 Oct 2014 15:11:18 +0000 (UTC) Received: (qmail 14928 invoked from network); 10 Oct 2014 15:04:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Oct 2014 15:04:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Fri, 10 Oct 2014 11:04:37 -0400 (EDT) Received: (qmail 29205 invoked from network); 10 Oct 2014 15:04:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Oct 2014 15:04:37 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 26330B1E002; Fri, 10 Oct 2014 08:04:34 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall? Date: Fri, 10 Oct 2014 08:04:35 -0700 Message-Id: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: Justin Hibbits 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, 10 Oct 2014 15:11:19 -0000 Based on 10.1-RC1 sources but probably long true.. s_trap in /usr/src/sys/powerpc/aim/trap_subr64.S starts with the = following sequence of 8 lines of source immediately after the s_trap = label (ignoring the unused u_trap label line, not shown below): s_trap: bf 17,k_trap /* branch if PSL_PR is false */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping */ mfsprg2 %r29 mr %r28,%r27 realtrap also has that exact instruction sequence starting a few = instructions down in its code --but immeadiately followed by a branch to = s_strap that ends up reexecuting that same instruction sequence (but = in/at s_trap), presuming that the original "bd 17,k_trap" in realtrap is = not taken: realtrap: /* Test whether we already had PR set */ mfsrr1 %r1 mtcr %r1 mfsprg1 %r1 /* restore SP (might have been overwritten) */ bf 17,k_trap /* branch if PSL_PR is false */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping */ mfsprg2 %r29 mr %r28,%r27 ba s_trap Why would this code for possibly calling restore_kernsrs possibly be = executed twice back-to-back for realtrap's execution overall? Is this = deliberate for some reason? Could the realtrap code validly avoid the = doubled activity when it does not immediately jump to k_trap? Note that if it was possible for s_trap to take the "bf 17,k_trap" = branch after realtrap did its "ba s_trap" then %r1 for that s_trap use = would not have the stack pointer in it for k_trap's potential use (e.g., = in its use of FRAME_SETUP). restore_kernsrs does not touch %r1 and = k_trap takes %r1 as-is for use as a stack pointer in FRAME_SETUP. = Luckily it appears that s_trap would not take that branch in this = context. But if that last is true that means that s_trap's code definitely always = does call restore_kernsrs a second time when used from realtrap. = Wasteful? [And for realtrap it would seem that the "mfsrr1 %r1" definitely "might = have" overwritten %r1 (a.k.a. the Stack Pointer): The "might have" = comment seems a little odd. It is more like the SP would be needed in = the branch to k_trap case and so had to be put back in %r1 to cover = that.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 15:33:49 2014 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 DF16DA3 for ; Fri, 10 Oct 2014 15:33:48 +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 BA27E9FD for ; Fri, 10 Oct 2014 15:33:48 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s9AFNNHI025513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Oct 2014 08:23:24 -0700 Message-ID: <5437F9EB.3050302@freebsd.org> Date: Fri, 10 Oct 2014 08:23:23 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall? References: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> In-Reply-To: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZhl1VmBHvuleyMLE+Nk01HpDzvcmFlJqzTXBZBb4XS8Pxu2j/yTt4Bh7CP7Qp5j7U/z89Bfk2obqCL2QdYj4TRDGpbnO8hDHw= X-Sonic-ID: C;IF+zX5FQ5BG1xYR6lZB5Vg== M;dvgxYJFQ5BG1xYR6lZB5Vg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: Justin Hibbits 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, 10 Oct 2014 15:33:49 -0000 How does this end up being called twice? k_trap does not return (note no "l" in the branch instruction). They are separated, by the way, due to some slightly different logic for handling faults that need to end up in the kernel debugger. -Nathan On 10/10/14 08:04, Mark Millard wrote: > Based on 10.1-RC1 sources but probably long true.. > > s_trap in /usr/src/sys/powerpc/aim/trap_subr64.S starts with the following sequence of 8 lines of source immediately after the s_trap label (ignoring the unused u_trap label line, not shown below): > > s_trap: > bf 17,k_trap /* branch if PSL_PR is false */ > GET_CPUINFO(%r1) > ld %r1,PC_CURPCB(%r1) > mr %r27,%r28 /* Save LR, r29 */ > mtsprg2 %r29 > bl restore_kernsrs /* enable kernel mapping */ > mfsprg2 %r29 > mr %r28,%r27 > > > realtrap also has that exact instruction sequence starting a few instructions down in its code --but immeadiately followed by a branch to s_strap that ends up reexecuting that same instruction sequence (but in/at s_trap), presuming that the original "bd 17,k_trap" in realtrap is not taken: > > realtrap: > /* Test whether we already had PR set */ > mfsrr1 %r1 > mtcr %r1 > mfsprg1 %r1 /* restore SP (might have been > overwritten) */ > bf 17,k_trap /* branch if PSL_PR is false */ > GET_CPUINFO(%r1) > ld %r1,PC_CURPCB(%r1) > mr %r27,%r28 /* Save LR, r29 */ > mtsprg2 %r29 > bl restore_kernsrs /* enable kernel mapping */ > mfsprg2 %r29 > mr %r28,%r27 > ba s_trap > > Why would this code for possibly calling restore_kernsrs possibly be executed twice back-to-back for realtrap's execution overall? Is this deliberate for some reason? Could the realtrap code validly avoid the doubled activity when it does not immediately jump to k_trap? > > Note that if it was possible for s_trap to take the "bf 17,k_trap" branch after realtrap did its "ba s_trap" then %r1 for that s_trap use would not have the stack pointer in it for k_trap's potential use (e.g., in its use of FRAME_SETUP). restore_kernsrs does not touch %r1 and k_trap takes %r1 as-is for use as a stack pointer in FRAME_SETUP. Luckily it appears that s_trap would not take that branch in this context. > > But if that last is true that means that s_trap's code definitely always does call restore_kernsrs a second time when used from realtrap. Wasteful? > > > [And for realtrap it would seem that the "mfsrr1 %r1" definitely "might have" overwritten %r1 (a.k.a. the Stack Pointer): The "might have" comment seems a little odd. It is more like the SP would be needed in the branch to k_trap case and so had to be put back in %r1 to cover that.] > > > > > > > === > Mark Millard > markmi at dsl-only.net > > From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 16:28:23 2014 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 D885A403 for ; Fri, 10 Oct 2014 16:28:23 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 7ED25FCB for ; Fri, 10 Oct 2014 16:28:22 +0000 (UTC) Received: (qmail 8789 invoked from network); 10 Oct 2014 16:28:20 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Oct 2014 16:28:20 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Fri, 10 Oct 2014 12:28:20 -0400 (EDT) Received: (qmail 24760 invoked from network); 10 Oct 2014 16:28:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Oct 2014 16:28:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id CB2261C4056; Fri, 10 Oct 2014 09:28:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: powerpc64/GENERIC64: s_trap vs. realtrap, why does realtrap possibly execute restore_kernsrs twice in a row overall? From: Mark Millard In-Reply-To: <5437F9EB.3050302@freebsd.org> Date: Fri, 10 Oct 2014 09:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0780902E-CF13-402A-A17B-4A2484CE008F@dsl-only.net> References: <511C0B85-173F-4863-ACA5-0274C381E005@dsl-only.net> <5437F9EB.3050302@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Cc: Justin Hibbits , 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: Fri, 10 Oct 2014 16:28:24 -0000 On Oct 10, 2014, at 8:23 AM, Nathan Whitehorn = wrote: > How does this end up being called twice? k_trap does not return (note = no "l" in the branch instruction). They are separated, by the way, due = to some slightly different logic for handling faults that need to end up = in the kernel debugger. If I read the above right you have answered for when "bf 17,k_trap" is = taken in realtrap and so realtrap's "ba s_strap" is not even executed. = But I specified that my worry was for when "presuming that the original = 'bd 17,k_trap' in realtrap is not taken". May be showing the flow in sequential order (for both reading and = execution) starting at realtrap when "bf 17, k_trap" is not taken in the = following manor will help with interpretation of my point: Read = sequentially down the listing below where the conditional branches do = not jump to k_trap. It only flows there (no jump) after the code shown = for s_trap below for the case/context I was asking about unless I've = missed something. I've also added to the comments to help identify my = intended case. realtrap: /* Test whether we already had PR set */ mfsrr1 %r1 mtcr %r1 mfsprg1 %r1 /* restore SP (might have been overwritten) */ bf 17,k_trap /* branch if PSL_PR is false PRESUME PSL_PR IS = TRUE INSTEAD */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping <=3D=3D=3D = FIRST CALL */ mfsprg2 %r29 mr %r28,%r27 ba s_trap s_trap: bf 17,k_trap /* branch if PSL_PR is false STILL NO BRANCH? = */ GET_CPUINFO(%r1) ld %r1,PC_CURPCB(%r1) mr %r27,%r28 /* Save LR, r29 */ mtsprg2 %r29 bl restore_kernsrs /* enable kernel mapping <=3D=3D=3D = SECOND CALL */ mfsprg2 %r29 mr %r28,%r27 This would then finally flow into k_trap but my point has already = happened by this point. I see two calls to restore_kernsrs when I read = the above execution sequence when PSL_PR is TRUE for the first "bf = 17,k_trap" (so no jump). So far I do not see code executed for this = sequence that would make the second "bf 17,k_trap" jump when the first = one above did not. Did I miss something in restore_kernsrs that makes = the 2nd "bf 17,k_trap" jump when the first one does not? (I saw the logic for the kernel debugger vs. normal. I did not challenge = why the two alternatives exist. It just appears to me that there is some = redundant work done by one path through the code.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 17:24:36 2014 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 6B8B322B for ; Fri, 10 Oct 2014 17:24:36 +0000 (UTC) Received: from mail.titaniotecnologia.com.br (mail2.tsemredes.com.br [177.52.170.133]) by mx1.freebsd.org (Postfix) with ESMTP id E7E968A4 for ; Fri, 10 Oct 2014 17:24:34 +0000 (UTC) Received: (qmail 51497 invoked from network); 10 Oct 2014 14:24:36 -0300 Received: by simscan 1.4.0 ppid: 51490, pid: 51492, t: 0.0501s scanners: attach: 1.4.0 clamav: 0.98.1/m:55/d:18859 Received: from unknown (HELO ?192.168.25.169?) (felipe@felipeoliva.eti.br@177.96.70.8) de/crypted with TLSv1.2: DHE-RSA-AES128-SHA [128/128] DN=unknown by mail.titaniotecnologia.com.br with ESMTPSA; 10 Oct 2014 14:24:36 -0300 Message-ID: <54381648.5030900@felipeoliva.eti.br> Date: Fri, 10 Oct 2014 14:24:24 -0300 From: "Felipe N. Oliva" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Cross compile RB1100ahx2 Content-Type: text/plain; charset=windows-1252; 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, 10 Oct 2014 17:24:36 -0000 Regards, I want to do cross compiling from amd64 to powerpc(RouterBOARD 1100ahx2 processor P2020). Has anyone done this? Works well? Any tips? Thank you, -- Felipe N. Oliva From owner-freebsd-ppc@FreeBSD.ORG Fri Oct 10 21:20:30 2014 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 9B2FB95D for ; Fri, 10 Oct 2014 21:20:30 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 34631387 for ; Fri, 10 Oct 2014 21:20:29 +0000 (UTC) Received: (qmail 17155 invoked from network); 10 Oct 2014 21:20:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Oct 2014 21:20:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Fri, 10 Oct 2014 17:20:28 -0400 (EDT) Received: (qmail 7209 invoked from network); 10 Oct 2014 21:20:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Oct 2014 21:20:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 204011C4058; Fri, 10 Oct 2014 14:20:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A little new before-Copyright-notice/ofwcall crash information... [Still no solution, just more information] Date: Fri, 10 Oct 2014 14:20:26 -0700 Message-Id: <477A81CF-3222-4462-B25D-F46F0AA09D3B@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: Justin Hibbits 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, 10 Oct 2014 21:20:30 -0000 I was experimenting with trying to get more information on the "before = Copyright notice"/ofwcall PowerMac G5 hangs and accidentally got better = information than I expected. (At least if the "show registers" is to be = believed for SRR0.) First I'll give the results and what they refer to. Then how I got them. As part of the experiments I stuck in isync commands after the ofwcall = to after the mtmsrd just to prove that the same (relative) instruction = position would be reported with or without those: > Index: /usr/src/sys/powerpc/ofw/ofwcall64.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/ofw/ofwcall64.S (revision 272558) > +++ /usr/src/sys/powerpc/ofw/ofwcall64.S (working copy) > @@ -128,13 +128,22 @@ > bctrl > =20 > /* Reload stack pointer and MSR from the OFW stack */ > + isync > + isync > ld %r6,24(%r1) > + isync > + isync > ld %r2,16(%r1) > + isync > + isync > ld %r1,8(%r1) > + isync > + isync > =20 > /* Now set the real MSR */ > mtmsrd %r6 > isync > + isync > =20 > /* Sign-extend the return value from OF */ > extsw %r3,%r3 The result that I got was that the last isync above is where the SRR0 is = reported as pointing when the trap happens. (No multiple-fault problem = showed up so it did not point into the exception handling code.) With all the extra isyncs removed (the normal code having only one isync = in that area, the one just after the mtmsrd), the extsw instruction is = in that position and it is what SRR0 pointed to. So that aspect ended up = confirmed. The version of the code with the extra isyncs should have forced any of = the exceptions from the ld commands (and before) to happen before the = mtmsrd was executed. As near as I can tell the implication would be that = the mtmsrd itself is what is having an exception happen. SRR1: 0x1000000040101120 lr: 0x8a64e8 .ofwcall+0xa8 (i.e., just after the bctrl in both types = of code). =46rom all this I expect that ofwcall returned before the exception = happened. ctr: 0xff846d78 cr: 0x22000022 xer: 0 I expect that the reported dar and dsisr are garbage (probably a wrong = kind of trap to have them initialized). But they were listed as: dar: 0x810248fbc10250fb dsisr: 0xe102587f8802a648 I've no clue if openfirmware was well behaved about register values as = of when it returned to ofwcall. r6 in the list below does not look good = to me: a little more than r1's value, suggesting a stack address is = being displayed instead of an msrd value. But by the time of mtmsrd %r6 = execution r1 should no longer have the OFW stack address but one for the = kernel at the time. (Presumes openfirmware was well behaved.) r0: 0 r1: 0xbc0558 r2: 0xe18dd0 MP_ncpus r3: 0xd24450 r4: 0x8a64e8 .ofwcall+0xa8 (specific address could depend on other = variations in builds) r5: 0 r6: 0xbc0568 r7: 0xe5f63d ofw_real_mode r8: 0x1 r9: 0xe5f63d ofw_name_history_+0x15 (part of my crash information = dumping hacks) r10: 0x1c35ec0 r11: 0 r12: 0x22000022 r13: 0xddaf29 thread0 r14-r19: 0 r20: 0x10f6000 r21: 0x4 r22: 0x1801bd4 r23: 0x1803a28 r24: 0xc000000000008760 r25: 0xcd4a98 r26: 0xcf6758 r27: 0xcd4a98 r28: 0xe62690 emergency_buffer.7721+0x8 r29: 0x1874d0 ofw_name_history_pos (part of my information dumping = hacks) r30: 0x9000000000001032 r31: 0xc0000000000084a0 [ofw_name_history is how I earlier found the specific ofwcall that did = not return all the way without getting an associated exception. = ofw_name_history content is dumped by my DDB script that I forced to = exist and runs when the exception happens.] Now for the odd part of how I got to the above happening. Given the multiple-fault problem that was involved I decided to try to = get some information on which type(s) of exception(s) by making PC = values distinct: duplicating the code that contained the address being = reported so each use had its own copy. So I ended up with not just realtrap but realtrap1, realtrap2, and = realtrap3, for example, that look like: > +realtrap1: > +/* Test whether we already had PR set */ > + mfsrr1 %r1 > + mtcr %r1 > + mfsprg1 %r1 /* restore SP (might have been > + overwritten) */ > + bf 17,rt1_k_trap /* branch if PSL_PR is false = */ > + GET_CPUINFO(%r1) > + ld %r1,PC_CURPCB(%r1) > + mr %r27,%r28 /* Save LR, r29 */ > + mtsprg2 %r29 > + bl restore_kernsrs /* enable kernel mapping */ > + mfsprg2 %r29 > + mr %r28,%r27 > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > +rt1_k_trap: > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain Since the original reports where for an address inside FRAME_SETUP code, = I needed distinct copies of FRAME_SETUP to have unique PCs for the = different uses. (I could have used realtrap instead of having realtrap3 but ended up = with realtrap unused.) The trapagain code was after the reported fault place and so was not = duplicated. generictrap also got its own copy of such code (no label). That left alitrap as the only use of the original s_trap code. (It is = the only bla style use of s_trap in the original code and so I left that = alone.) After these changes I got the Show Registers results that I reported = above instead of SRR0 values from one of the exception handler paths. = (That is not what I expected.) The detailed changes to trap_subr64.S = were: > Index: /usr/src/sys/powerpc/aim/trap_subr64.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/aim/trap_subr64.S (revision 272558) > +++ /usr/src/sys/powerpc/aim/trap_subr64.S (working copy) > @@ -583,7 +583,7 @@ > /* Try to detect a kernel stack overflow */ > mfsrr1 %r31 > mtcr %r31 > - bt 17,realtrap /* branch is user mode */ > + bt 17,realtrap1 /* branch is user mode */ > mfsprg1 %r31 /* get old SP */ > clrrdi %r31,%r31,12 /* Round SP down to nearest = page */ > sub. %r30,%r31,%r30 /* SP - DAR */ > @@ -590,7 +590,7 @@ > bge 1f > neg %r30,%r30 /* modulo value */ > 1: cmpldi %cr0,%r30,4096 /* is DAR within a page of SP? = */ > - bge %cr0,realtrap /* no, too far away. */ > + bge %cr0,realtrap2 /* no, too far away. */ > =20 > /* Now convert this DSI into a DDB trap. */ > GET_CPUINFO(%r1) > @@ -628,6 +628,68 @@ > mr %r28,%r27 > ba s_trap > =20 > +realtrap1: > +/* Test whether we already had PR set */ > + mfsrr1 %r1 > + mtcr %r1 > + mfsprg1 %r1 /* restore SP (might have been > + overwritten) */ > + bf 17,rt1_k_trap /* branch if PSL_PR is false = */ > + GET_CPUINFO(%r1) > + ld %r1,PC_CURPCB(%r1) > + mr %r27,%r28 /* Save LR, r29 */ > + mtsprg2 %r29 > + bl restore_kernsrs /* enable kernel mapping */ > + mfsprg2 %r29 > + mr %r28,%r27 > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > +rt1_k_trap: > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > + > + > +realtrap2: > +/* Test whether we already had PR set */ > + mfsrr1 %r1 > + mtcr %r1 > + mfsprg1 %r1 /* restore SP (might have been > + overwritten) */ > + bf 17,rt2_k_trap /* branch if PSL_PR is false = */ > + GET_CPUINFO(%r1) > + ld %r1,PC_CURPCB(%r1) > + mr %r27,%r28 /* Save LR, r29 */ > + mtsprg2 %r29 > + bl restore_kernsrs /* enable kernel mapping */ > + mfsprg2 %r29 > + mr %r28,%r27 > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > +rt2_k_trap: > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > + > +realtrap3: > +/* Test whether we already had PR set */ > + mfsrr1 %r1 > + mtcr %r1 > + mfsprg1 %r1 /* restore SP (might have been > + overwritten) */ > + bf 17,rt3_k_trap /* branch if PSL_PR is false = */ > + GET_CPUINFO(%r1) > + ld %r1,PC_CURPCB(%r1) > + mr %r27,%r28 /* Save LR, r29 */ > + mtsprg2 %r29 > + bl restore_kernsrs /* enable kernel mapping */ > + mfsprg2 %r29 > + mr %r28,%r27 > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > +rt3_k_trap: > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > + > + > /* > * generictrap does some standard setup for trap handling to minimize > * the code that need be installed in the actual vectors. It expects > @@ -666,6 +728,20 @@ > mfsrr1 %r31 > mtcr %r31 > =20 > + bf 17,gt_k_trap /* branch if PSL_PR is false = */ > + GET_CPUINFO(%r1) > + ld %r1,PC_CURPCB(%r1) > + mr %r27,%r28 /* Save LR, r29 */ > + mtsprg2 %r29 > + bl restore_kernsrs /* enable kernel mapping */ > + mfsprg2 %r29 > + mr %r28,%r27 > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > +gt_k_trap: > + FRAME_SETUP(PC_TEMPSAVE) > + ba trapagain > + > s_trap: > bf 17,k_trap /* branch if PSL_PR is false = */ > GET_CPUINFO(%r1) > @@ -785,7 +861,7 @@ > ld %r31,(PC_DBSAVE+CPUSAVE_R31)(%r1) > mtsprg3 %r31 /* SPRG3 was clobbered by = FRAME_LEAVE */ > mfsprg1 %r1 > - b realtrap > + b realtrap3 > dbleave: > FRAME_LEAVE(PC_DBSAVE) > rfid >=20 Reverting this one file to the original code goes back to the historical = exception-in-exception-handler report by DDB's Show Register. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Oct 11 08:17:45 2014 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 98997DF2 for ; Sat, 11 Oct 2014 08:17:45 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33F2981B for ; Sat, 11 Oct 2014 08:17:45 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id d1so3865358wiv.12 for ; Sat, 11 Oct 2014 01:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Fk8u77pkJU9XSrBn7e7fCnd4G+qcEvGRFVAXxF0S6RE=; b=trlRB/E+N7fwcAJUmsU/ERW77eCBvrnMSOdaH1NAXtjx+25hIEJwQziH3b/QKLes/V pD+rEPkmHpOlZrXZY0ElUCsVDFGJH2baKLw5GDHJT4tIFCph66a1Q1sDaGBWnjqt9FIA K+fZ3q+n+bNiToLiRO4JptJ8dcPByDQQ0bLBcVtQISUDw+5yaPN04MgMbtMhdaLuvueE a3sExMaAmm0fXOEOamkKAcHTS7fC6wDCxft4lLAom2BPLefVOOHatwL9+1emfdtAKnm7 9gZ6a3+OHibWJp9bDHIB/G/taTA/1H2RR2TsZtreO1b4GrFUriyN+gfPoEPFpOvasKd7 j33A== X-Received: by 10.194.200.3 with SMTP id jo3mr9898563wjc.0.1413015463526; Sat, 11 Oct 2014 01:17:43 -0700 (PDT) Received: from [10.8.0.10] (eurynome.bytesized-hosting.com. [94.242.229.16]) by mx.google.com with ESMTPSA id q10sm9376851wjq.35.2014.10.11.01.17.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Oct 2014 01:17:42 -0700 (PDT) From: Matthias Schojohann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Booting FreeBSD 10 on an iBook G4 Message-Id: Date: Sat, 11 Oct 2014 10:17:39 +0200 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.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, 11 Oct 2014 08:17:45 -0000 Hello and good morning! I just installed FreeBSD 10 on my beloved old iBook G4 I have that known error, that my Mac boots into a white screen (FreeBSD = is the only OS installed). If i go to Open Firmware and tell him to boot hd; hd:0 it works=85which = is obviously pretty annoying ;) So how can i change that? I know it=92s possible but i can=92t seem to = find the answer online :/ Cheers, Matt= From owner-freebsd-ppc@FreeBSD.ORG Sat Oct 11 08:26:49 2014 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 6084EF5C for ; Sat, 11 Oct 2014 08:26:49 +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 E9B0E8E6 for ; Sat, 11 Oct 2014 08:26:47 +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 s9B8QXci093365; Sat, 11 Oct 2014 10:26:38 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <5438E9B9.9070909@fgznet.ch> Date: Sat, 11 Oct 2014 10:26:33 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthias Schojohann , freebsd-ppc@freebsd.org Subject: Re: Booting FreeBSD 10 on an iBook G4 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Sat, 11 Oct 2014 08:26:49 -0000 On 11.10.14 10:17, Matthias Schojohann wrote: > Hello and good morning! > I just installed FreeBSD 10 on my beloved old iBook G4 > I have that known error, that my Mac boots into a white screen (FreeBSD is the only OS installed). > If i go to Open Firmware and tell him to boot hd; hd:0 it works…which is obviously pretty annoying ;) > So how can i change that? I know it’s possible but i can’t seem to find the answer online :/ Boot into OF (at boot press 'alt-apple-O-F') set your boot device: > setenv boot-device sd1:2,\\:tbxi The sd1:2 should be replaced with your hd:partition where the loader/kernel sits. Obviously in your case: > setenv boot-device hd:0,\\:tbxi HTH, Andreas From owner-freebsd-ppc@FreeBSD.ORG Sat Oct 11 21:10:54 2014 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 8AA94C28 for ; Sat, 11 Oct 2014 21:10:54 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25F24922 for ; Sat, 11 Oct 2014 21:10:54 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hi2so4694488wib.14 for ; Sat, 11 Oct 2014 14:10:52 -0700 (PDT) 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=yS8RgD9X5UspLdnW4F35yB3GFebXTeYTxxpovq9VETo=; b=dYPooeSAWHm2OaWDFdrufee6oL7O0Ceh0DIEcPwbbTDi9peXQ+2VgCcRyWTAkaXfOx OUq3plOwDyysdQvfESs7MWPpICyp1yoUGAbA0bEtXa+0xjsiXmnQUgGWWXDmb8dV6dnQ sDzUaqifPX9Nc0THl+w3BE5rpuHCBnSk/MmBVClzjvMMEWAjVtPirzuXy6sn+4Vwgeh1 +QzSouYk53F+l0vtYbLnOND8wdl5qvS5fXv7fe/gDjcNH1xb4FEta5JcooJ59eKP4f2m TgRjq87ycH/Q1Q9Z2vItG3NVTWQ9tauMj7batyuvOjlJChdJzEdonIm4NHj3yDZx1xhC UG5A== MIME-Version: 1.0 X-Received: by 10.194.83.67 with SMTP id o3mr11773520wjy.31.1413061852320; Sat, 11 Oct 2014 14:10:52 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 11 Oct 2014 14:10:52 -0700 (PDT) In-Reply-To: <54381648.5030900@felipeoliva.eti.br> References: <54381648.5030900@felipeoliva.eti.br> Date: Sat, 11 Oct 2014 14:10:52 -0700 X-Google-Sender-Auth: eZ8xcQKltbiJwRfu0a_kzzGDJ6c Message-ID: Subject: Re: Cross compile RB1100ahx2 From: Adrian Chadd To: "Felipe N. Oliva" 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: Sat, 11 Oct 2014 21:10:54 -0000 Damn, I keep meaning to acquire one of these to run up as a test 11n AP. Nathan? ANy ideas? -a On 10 October 2014 10:24, Felipe N. Oliva wrote: > Regards, > > I want to do cross compiling from amd64 to powerpc(RouterBOARD 1100ahx2 > processor P2020). > > Has anyone done this? Works well? Any tips? > > Thank you, > -- > Felipe N. Oliva > > _______________________________________________ > 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"