From owner-freebsd-sparc Sun Dec 23 7:27:46 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 7425237B405 for ; Sun, 23 Dec 2001 07:27:40 -0800 (PST) Received: (qmail 8918 invoked by uid 0); 23 Dec 2001 15:27:39 -0000 Received: from p5086f0d7.dip.t-dialin.net (HELO forge.local) (80.134.240.215) by mail.gmx.net (mp009-rz3) with SMTP; 23 Dec 2001 15:27:39 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16IAXX-00013b-00; Sun, 23 Dec 2001 16:27:51 +0100 Date: Sun, 23 Dec 2001 16:27:51 +0100 From: Thomas Moestl To: Jamey Wood Cc: freebsd-sparc@freebsd.org Subject: Re: compiling a sparc64 kernel? Message-ID: <20011223162751.C659@crow.dom2ip.de> References: <1483c13c42.13c421483c@smi.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1483c13c42.13c421483c@smi.sun.com>; from Jamey.Wood@Sun.COM on Sat, Dec 22, 2001 at 07:01:51PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2001/12/22 at 19:01:51 -0800, Jamey Wood wrote: > I've been trying for a few days to build the sparc64 kernel, > but kept running into compiler errors (detailed notes below). > I put in some hacks to get everything to compile, but the resulting > kernel doesn't look to get as far into a boot as the binary version I > downloaded per tmm's sparc64 README. Note that I've got an Ultra 1 > (so I understand the boot won't get very far because of no sbus > support, which is where I'm hoping I might be able to help the port). Cool! > For me, tmm's kernel results in: > > /kernel data=0x202fb8+0xdfdc0 syms=[0x8+0x36210+0x8+0x2887c] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0030000. > sparc64_init: mdp=0xc0344000 kmdp=0xc0344000 boothowto=0 > envp=0xc0342000 end=0x0 > panic: trap_dmmu_miss: vmspace NULL > Debugger("panic") > Stopped at 0xc018479c: ta %xcc, 1 Hmmm, well, it should get quite a bit farther. Can you please post a backtrace of that panic? > And my custom-compiled version (with the potentially bogus hacks > I explain in detail below) gets: > > /kernel data=0x134ab8+0x4d2b8 syms=[0x8+0x255c0+0x8+0x1b653] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0028000. > > RED State Exception > > TL=0000.0000.0000.0005 TT=0000.0000.0000.0080 > TPC=0000.0000.c002.4200 TnPC=0000.0000.c002.4204 > TSTATE=0000.0099.5800.1506 > TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 > TPC=0000.0000.c002.4d50 TnPC=0000.0000.c002.4d54 > TSTATE=0000.0099.5804.1406 > TL=0000.0000.0000.0003 TT=0000.0000.0000.0068 > TPC=0000.0000.c002.82a8 TnPC=0000.0000.c002.82ac > TSTATE=0000.0099.5800.1506 > TL=0000.0000.0000.0002 TT=0000.0000.0000.0034 > TPC=0000.0000.c00e.3dac TnPC=0000.0000.c00e.3db0 > TSTATE=0000.0099.5800.1605 > TL=0000.0000.0000.0001 TT=0000.0000.0000.004e > TPC=000 > > > > I'm trying to compile from a 5.0-current system (updated buildworld > >from yesterday), using tmm's toolchain. > > I'm just looking for an understanding of how to cleanly compile a > kernel that'll get as far into the boot as the tmm version. Thanks in > advance for any help. Jake has committed fixes for these build problems yesterday. If this problem still persists, you can debug such crashes that drop you back into the firmware by using e.g. the gdb that is included in the toolchain archive to find the instruction that caused the trap (the kernel runs at trap level 1 after the early initialization, so depending on the point of crash the interesting tpc is stored in the trap registers for trap level 1 or 2). - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Dec 23 11:29:33 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id CA67037B417; Sun, 23 Dec 2001 11:29:28 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id fBNJY8683079; Sun, 23 Dec 2001 14:34:08 -0500 (EST) (envelope-from jake) Date: Sun, 23 Dec 2001 14:34:08 -0500 From: Jake Burkholder To: Thomas Moestl Cc: Jamey Wood , freebsd-sparc@FreeBSD.ORG Subject: Re: compiling a sparc64 kernel? Message-ID: <20011223143408.A82980@locore.ca> References: <1483c13c42.13c421483c@smi.sun.com> <20011223162751.C659@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011223162751.C659@crow.dom2ip.de>; from tmm@FreeBSD.ORG on Sun, Dec 23, 2001 at 04:27:51PM +0100 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Dec 23, 2001 at 04:27:51PM +0100, Thomas Moestl said words to the effect of; > On Sat, 2001/12/22 at 19:01:51 -0800, Jamey Wood wrote: > > I've been trying for a few days to build the sparc64 kernel, > > but kept running into compiler errors (detailed notes below). > > I put in some hacks to get everything to compile, but the resulting > > kernel doesn't look to get as far into a boot as the binary version I > > downloaded per tmm's sparc64 README. Note that I've got an Ultra 1 > > (so I understand the boot won't get very far because of no sbus > > support, which is where I'm hoping I might be able to help the port). > > Cool! > > > For me, tmm's kernel results in: > > > > /kernel data=0x202fb8+0xdfdc0 syms=[0x8+0x36210+0x8+0x2887c] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/kernel]... > > calling autoload > > nothing to autoload yet. > > post autoload > > jumping to kernel entry at 0xc0030000. > > sparc64_init: mdp=0xc0344000 kmdp=0xc0344000 boothowto=0 > > envp=0xc0342000 end=0x0 > > panic: trap_dmmu_miss: vmspace NULL > > Debugger("panic") > > Stopped at 0xc018479c: ta %xcc, 1 > > Hmmm, well, it should get quite a bit farther. Can you please post a > backtrace of that panic? Hmm, indeed. The end=0x0 is puzzling and might cause problems. > > > And my custom-compiled version (with the potentially bogus hacks > > I explain in detail below) gets: > > > > /kernel data=0x134ab8+0x4d2b8 syms=[0x8+0x255c0+0x8+0x1b653] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/kernel]... > > calling autoload > > nothing to autoload yet. > > post autoload > > jumping to kernel entry at 0xc0028000. > > > > RED State Exception > > > > TL=0000.0000.0000.0005 TT=0000.0000.0000.0080 > > TPC=0000.0000.c002.4200 TnPC=0000.0000.c002.4204 > > TSTATE=0000.0099.5800.1506 > > TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 > > TPC=0000.0000.c002.4d50 TnPC=0000.0000.c002.4d54 > > TSTATE=0000.0099.5804.1406 > > TL=0000.0000.0000.0003 TT=0000.0000.0000.0068 > > TPC=0000.0000.c002.82a8 TnPC=0000.0000.c002.82ac > > TSTATE=0000.0099.5800.1506 > > TL=0000.0000.0000.0002 TT=0000.0000.0000.0034 > > TPC=0000.0000.c00e.3dac TnPC=0000.0000.c00e.3db0 > > TSTATE=0000.0099.5800.1605 > > TL=0000.0000.0000.0001 TT=0000.0000.0000.004e > > TPC=000 > > > > > > > > I'm trying to compile from a 5.0-current system (updated buildworld > > >from yesterday), using tmm's toolchain. > > > > I'm just looking for an understanding of how to cleanly compile a > > kernel that'll get as far into the boot as the tmm version. Thanks in > > advance for any help. A kernel from cvs should work ok, except it won't have support for pci devices (which I imagine you don't need anyway). You may need to add support for the openfirmware console to GENERIC, device ofw_console. If it doesn't drop to the prom, but you don't get any output past the loader, try that. I'm away from home for a few days (holidays, back on the 26th), so I don't have full access to my test machine, but I'll do what I can to help. To do development you really want the code from perforce. I've requested that the sparc64 branch be exported via cvsup on cvsup10, but I don't know how long that will take to get setup. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Dec 23 12:45:35 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by hub.freebsd.org (Postfix) with ESMTP id 5A0E037B416 for ; Sun, 23 Dec 2001 12:45:31 -0800 (PST) Received: from esunmail ([129.147.58.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04236 for ; Sun, 23 Dec 2001 13:46:22 -0700 (MST) Received: from smi.sun.com ([127.0.0.1]) by esunmail.central.sun.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GOT00E41DJPQ5@esunmail.central.sun.com> for freebsd-sparc@freebsd.org; Sun, 23 Dec 2001 13:43:01 -0700 (MST) Received: from [192.18.102.132] by esunmail.central.sun.com (mshttpd); Sun, 23 Dec 2001 12:43:01 -0800 Date: Sun, 23 Dec 2001 12:43:01 -0800 From: Jamey Wood Subject: Re: compiling a sparc64 kernel? To: freebsd-sparc@freebsd.org Message-id: <1513fe0e8.e0e81513f@smi.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for the responses and tips. A new cvsup does get things compiling for me, as you both suggested. > > Hmmm, well, it should get quite a bit farther. Can you please > post a > > backtrace of that panic? > > Hmm, indeed. The end=0x0 is puzzling and might cause problems. I'm new at a lot of this, so I hope this is the trace info you guys need (from Thomas's kernel): /kernel data=0x202fb8+0xdfdc0 syms=[0x8+0x36210+0x8+0x2887c] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel]... calling autoload nothing to autoload yet. post autoload jumping to kernel entry at 0xc0030000. sparc64_init: mdp=0xc0344000 kmdp=0xc0344000 boothowto=0 envp=0xc0342000 end=0x0 panic: trap_dmmu_miss: vmspace NULL Debugger("panic") Stopped at 0xc018479c: ta %xcc, 1 db> trace (null)() at 0xc00ca80c (null)() at 0xc018a2e8 (null)() at 0xc0189e78 (null)() at 0xc00310d4 (null)() at 0xc0031300 (null)() at 0xc0183ffc (null)() at 0xc0030034 > A kernel from cvs should work ok, except it won't have support for pci > devices (which I imagine you don't need anyway). You may need to add > support for the openfirmware console to GENERIC, device ofw_console. > If it doesn't drop to the prom, but you don't get any output past the > loader, try that. After adding defice ofw_console, I do get a little output from my custom kernel on boot: /kernel data=0x1352b8+0x4d2f8 syms=[0x8+0x257e8+0x8+0x1b762] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel]... calling autoload nothing to autoload yet. post autoload jumping to kernel entry at 0xc0028000. sparc64_init: mdp=0xc01c6000 kmdp=0xc01c6000 boothowto=0 envp=0xc01c4000 end=0x0 Copyrigh It just hangs right there, however. I tried sening a break, hoping to get to the ok or db prompt to do a trace, but even that didn't work. I had to power-cycle the U1 to get out of that wedged state. And trying it all again gives the same result. > I'm away from home for a few days (holidays, back on the 26th), so > I don't > have full access to my test machine, but I'll do what I can to help. Thanks. I'm just about to leave home for the same period, so I won't be online at all until the 26th. > To do development you really want the code from perforce. I've > requested that > the sparc64 branch be exported via cvsup on cvsup10, but I don't > know how long > that will take to get setup. Okay. I'll keep an eye out for news on this. --Jamey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sun Dec 23 20:55:17 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 6CFA737B405 for ; Sun, 23 Dec 2001 20:55:14 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id fBO4xsG84446; Sun, 23 Dec 2001 23:59:54 -0500 (EST) (envelope-from jake) Date: Sun, 23 Dec 2001 23:59:54 -0500 From: Jake Burkholder To: Jamey Wood Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: compiling a sparc64 kernel? Message-ID: <20011223235953.B84343@locore.ca> References: <1513fe0e8.e0e81513f@smi.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1513fe0e8.e0e81513f@smi.sun.com>; from Jamey.Wood@Sun.COM on Sun, Dec 23, 2001 at 12:43:01PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Dec 23, 2001 at 12:43:01PM -0800, Jamey Wood said words to the effect of; > Thanks for the responses and tips. A new cvsup does get things > compiling for me, as you both suggested. > > > > Hmmm, well, it should get quite a bit farther. Can you please > > post a > > > backtrace of that panic? > > > > Hmm, indeed. The end=0x0 is puzzling and might cause problems. > > I'm new at a lot of this, so I hope this is the trace info you guys > need (from Thomas's kernel): > > /kernel data=0x202fb8+0xdfdc0 syms=[0x8+0x36210+0x8+0x2887c] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0030000. > sparc64_init: mdp=0xc0344000 kmdp=0xc0344000 boothowto=0 > envp=0xc0342000 end=0x0 > panic: trap_dmmu_miss: vmspace NULL > Debugger("panic") > Stopped at 0xc018479c: ta %xcc, 1 > db> trace > (null)() at 0xc00ca80c > (null)() at 0xc018a2e8 > (null)() at 0xc0189e78 > (null)() at 0xc00310d4 > (null)() at 0xc0031300 > (null)() at 0xc0183ffc > (null)() at 0xc0030034 Yes, the idea is to now use nm or gdb to find which symbols these addresses refer to. > > > A kernel from cvs should work ok, except it won't have support for pci > > devices (which I imagine you don't need anyway). You may need to add > > support for the openfirmware console to GENERIC, device ofw_console. > > If it doesn't drop to the prom, but you don't get any output past the > > loader, try that. > > After adding defice ofw_console, I do get a little output from my custom > kernel on boot: > > /kernel data=0x1352b8+0x4d2f8 syms=[0x8+0x257e8+0x8+0x1b762] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0028000. > sparc64_init: mdp=0xc01c6000 kmdp=0xc01c6000 boothowto=0 > envp=0xc01c4000 end=0x0 > Copyrigh > > It just hangs right there, however. I tried sening a break, hoping to > get to the ok or db prompt to do a trace, but even that didn't work. I > had to power-cycle the U1 to get out of that wedged state. And trying > it all again gives the same result. Hmm. I was hoping you'd get to a mount root prompt. My first guess at what's happening is that the timer chip in the ultra 1 is generating interrupts which are not being handled properly by the kernel. So you get an interrupt storm. You could try setting the pil to something high (say 14), on entry to the kernel in locore.s, which may get a little further. Really we need a driver for the timer chip, which should be easy to nab from netbsd. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Dec 24 4:37:16 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 994CC37B417 for ; Mon, 24 Dec 2001 04:37:02 -0800 (PST) Received: (qmail 12755 invoked by uid 0); 24 Dec 2001 12:36:59 -0000 Received: from pd9e16ead.dip.t-dialin.net (HELO forge.local) (217.225.110.173) by mail.gmx.net (mp020-rz3) with SMTP; 24 Dec 2001 12:36:59 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16IULy-0000Ls-00; Mon, 24 Dec 2001 13:37:14 +0100 Date: Mon, 24 Dec 2001 13:37:14 +0100 From: Thomas Moestl To: Jamey Wood Cc: freebsd-sparc@freebsd.org Subject: Re: compiling a sparc64 kernel? Message-ID: <20011224133714.A451@crow.dom2ip.de> References: <1513fe0e8.e0e81513f@smi.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1513fe0e8.e0e81513f@smi.sun.com>; from Jamey.Wood@Sun.COM on Sun, Dec 23, 2001 at 12:43:01PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 2001/12/23 at 12:43:01 -0800, Jamey Wood wrote: > I'm new at a lot of this, so I hope this is the trace info you guys > need (from Thomas's kernel): > > /kernel data=0x202fb8+0xdfdc0 syms=[0x8+0x36210+0x8+0x2887c] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0030000. > sparc64_init: mdp=0xc0344000 kmdp=0xc0344000 boothowto=0 > envp=0xc0342000 end=0x0 > panic: trap_dmmu_miss: vmspace NULL > Debugger("panic") > Stopped at 0xc018479c: ta %xcc, 1 > db> trace > (null)() at 0xc00ca80c > (null)() at 0xc018a2e8 > (null)() at 0xc0189e78 > (null)() at 0xc00310d4 > (null)() at 0xc0031300 > (null)() at 0xc0183ffc > (null)() at 0xc0030034 Hmmm, this looks like an interrupt has happened in a window of time where interrupts are enabled, but the interrupt table is not yet initialized. The attached patch (against the code in CVS) should help. With it applied, you should get a message warning about a stray interrupt. > After adding defice ofw_console, I do get a little output from my custom > kernel on boot: > > /kernel data=0x1352b8+0x4d2f8 syms=[0x8+0x257e8+0x8+0x1b762] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0028000. > sparc64_init: mdp=0xc01c6000 kmdp=0xc01c6000 boothowto=0 > envp=0xc01c4000 end=0x0 > Copyrigh > > It just hangs right there, however. I tried sening a break, hoping to > get to the ok or db prompt to do a trace, but even that didn't work. I > had to power-cycle the U1 to get out of that wedged state. And trying > it all again gives the same result. Hmmm. This could be a consequence of the bug above. Does it still happen this way with the patch applied? - thomas Index: sparc64/machdep.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/sparc64/machdep.c,v retrieving revision 1.25 diff -u -r1.25 machdep.c --- sparc64/machdep.c 23 Dec 2001 07:02:23 -0000 1.25 +++ sparc64/machdep.c 24 Dec 2001 11:47:17 -0000 @@ -178,7 +178,6 @@ bufinit(); vm_pager_bufferinit(); - intr_init(); tick_start(clock, tick_hardclock); EVENTHANDLER_REGISTER(shutdown_final, sparc64_shutdown_final, NULL, @@ -277,13 +276,35 @@ */ tick_stop(); + /* Initialize the interrupt tables. */ + intr_init(); + /* * Force trap level 1 and take over the trap table. */ + ps = rdpr(pstate); + wrpr(pstate, ps, PSTATE_IE); wrpr(tl, 0, 1); wrpr(tba, tl0_base, 0); /* + * Put the pcpu pointer in the alternate and interrupt %g7 also. + * pcpu is tied to %g7. We could therefore also use assignments to + * pcpu here. + * The alternate %g6 additionally points to a small per-cpu stack that + * is used to temporarily store global registers in special spill + * handlers. + */ + wrpr(pstate, ps, PSTATE_AG | PSTATE_IE); + __asm __volatile("mov %0, %%g6" : : "r" + (&__pcpu.pc_alt_stack[ALT_STACK_SIZE - 1])); + __asm __volatile("mov %0, %%g7" : : "r" (&__pcpu)); + wrpr(pstate, ps, PSTATE_IG | PSTATE_IE); + __asm __volatile("mov %0, %%g6" : : "r" (&__pcpu.pc_iq)); + __asm __volatile("mov %0, %%g7" : : "r" (&intr_vectors)); + wrpr(pstate, ps, 0); + + /* * Map and initialize the message buffer (after setting trap table). */ for (off = 0; off < round_page(MSGBUF_SIZE); off += PAGE_SIZE) @@ -310,24 +331,6 @@ * Initialize the per-cpu pointer so we can set curproc. */ pcpup = &__pcpu; - - /* - * Put the pcpu pointer in the alternate and interrupt %g7 also. - * pcpu is tied to %g7. We could therefore also use assignments to - * pcpu here. - * The alternate %g6 additionally points to a small per-cpu stack that - * is used to temporarily store global registers in special spill - * handlers. - */ - ps = rdpr(pstate); - wrpr(pstate, ps, PSTATE_AG); - __asm __volatile("mov %0, %%g6" : : "r" - (&__pcpu.pc_alt_stack[ALT_STACK_SIZE - 1])); - __asm __volatile("mov %0, %%g7" : : "r" (&__pcpu)); - wrpr(pstate, ps, PSTATE_IG); - __asm __volatile("mov %0, %%g6" : : "r" (&__pcpu.pc_iq)); - __asm __volatile("mov %0, %%g7" : : "r" (&intr_vectors)); - wrpr(pstate, ps, 0); /* * Initialize curproc so that mutexes work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Mon Dec 24 5:46:58 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 950C937B419 for ; Mon, 24 Dec 2001 05:46:54 -0800 (PST) Received: (qmail 24151 invoked by uid 0); 24 Dec 2001 13:46:52 -0000 Received: from pd9e16ead.dip.t-dialin.net (HELO forge.local) (217.225.110.173) by mail.gmx.net (mp006-rz3) with SMTP; 24 Dec 2001 13:46:52 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16IVRc-0001bo-00; Mon, 24 Dec 2001 14:47:08 +0100 Date: Mon, 24 Dec 2001 14:47:08 +0100 From: Thomas Moestl To: Jamey Wood Cc: freebsd-sparc@freebsd.org Subject: Re: compiling a sparc64 kernel? Message-ID: <20011224144708.B451@crow.dom2ip.de> References: <1513fe0e8.e0e81513f@smi.sun.com> <20011224133714.A451@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011224133714.A451@crow.dom2ip.de>; from tmoestl@gmx.net on Mon, Dec 24, 2001 at 01:37:14PM +0100 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 2001/12/24 at 13:37:14 +0100, Thomas Moestl wrote: > On Sun, 2001/12/23 at 12:43:01 -0800, Jamey Wood wrote: > > It just hangs right there, however. I tried sening a break, hoping to > > get to the ok or db prompt to do a trace, but even that didn't work. I > > had to power-cycle the U1 to get out of that wedged state. And trying > > it all again gives the same result. > > Hmmm. This could be a consequence of the bug above. Does it still > happen this way with the patch applied? I just noticed that I forgot to commit a change that adds a compiler flag that is needed to build working kernels (-mcmodel=medlow). I've just committed it, you will need to update your tree to get the change, re-run config, do a 'make clean depend' (using the appropriate 'make' wrapper if needed) and rebuild the kernel. I've also attached another uncommitted patch that is needed to make console input using ofw_console work correctly. Sorry for the breakage. - thomas diff -ur freebsd/sys/dev/ofw/ofw_console.c sparc64/sys/dev/ofw/ofw_console.c --- freebsd/sys/dev/ofw/ofw_console.c Thu Sep 13 17:30:38 2001 +++ sparc64/sys/dev/ofw/ofw_console.c Sun Nov 4 01:14:36 2001 @@ -121,11 +121,7 @@ error = (*linesw[tp->t_line].l_open)(dev, tp); if (error == 0 && setuptimeout) { - polltime = hz / OFW_POLL_HZ; - if (polltime < 1) { - polltime = 1; - } - + polltime = hz / 4; ofw_timeouthandle = timeout(ofw_timeout, tp, polltime); } @@ -286,7 +282,7 @@ { unsigned char ch; - if (OF_read(stdin, &ch, 1) != 0) { + if (OF_read(stdin, &ch, 1) > 0) { return (ch); } diff -ur freebsd/sys/dev/ofw/openfirm.c sparc64/sys/dev/ofw/openfirm.c --- freebsd/sys/dev/ofw/openfirm.c Sun Nov 25 14:51:25 2001 +++ sparc64/sys/dev/ofw/openfirm.c Thu Nov 22 20:14:56 2001 @@ -93,7 +93,7 @@ OF_printf(const char *fmt, ...) { va_list va; - char buf[1024]; + static char buf[1024]; va_start(va, fmt); vsprintf(buf, fmt, va); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Thu Dec 27 14:17:37 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by hub.freebsd.org (Postfix) with ESMTP id 9111A37B405 for ; Thu, 27 Dec 2001 14:17:15 -0800 (PST) Received: from esunmail ([129.147.58.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19639 for ; Thu, 27 Dec 2001 15:18:10 -0700 (MST) Received: from smi.sun.com ([127.0.0.1]) by esunmail.central.sun.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GP000GN1WGKCY@esunmail.central.sun.com> for freebsd-sparc@freebsd.org; Thu, 27 Dec 2001 15:14:44 -0700 (MST) Received: from [192.18.102.130] by esunmail.central.sun.com (mshttpd); Thu, 27 Dec 2001 14:14:44 -0800 Date: Thu, 27 Dec 2001 14:14:44 -0800 From: Jamey Wood Subject: Re: compiling a sparc64 kernel? To: freebsd-sparc@freebsd.org Message-id: <1874114671.1467118741@smi.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hmm. I was hoping you'd get to a mount root prompt. My first > guess at > what's happening is that the timer chip in the ultra 1 is generating > interrupts which are not being handled properly by the kernel. So you > get an interrupt storm. You could try setting the pil to > something high > (say 14), on entry to the kernel in locore.s, which may get a > little further. Setting pil to 14 does get me all the way to a mountroot prompt: sparc64_init: mdp=0xc01ba000 kmdp=0xc01ba000 boothowto=0 envp=0xc01b8000 end=0x0 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #36: Thu Dec 27 14:51:00 GMT 2001 woodjr@buddy:/usr/src/sys/sparc64/compile/sparc64 Preloaded elf kernel "/kernel" at 0xc01ba000. Timecounter "tick" frequency 166986609 Hz CPU: unknown; please e-mail the following value together with the exact name of your processor to . version register: <0x22001040000507> nexus0: nexus0: , type (unknown) (no driver attached) nexus0: , type sbus (no driver attached) rn_init: radix functions require max_keylen be set Mounting root from ufs:/dev/md0c Root mount failed: 22 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0a ? List valid disk boot devices Abort manual input Mountroot> > Really we need a driver for the timer chip, which should be easy > to nab from netbsd. The netbsd driver appears to be in their arch/sparc64/sparc64/clock.c. I'm having a little trouble understanding the FreeBSD device probing semantics to take a stab at porting it... It looks like the probe should work by looking for "counter-timer" in the OFW? What I don't understand is where that probing should occur and where the device attach should occur? From what I can see, the counter-timer device_t currently gets passed to nexus_probe_nomatch where the "no driver attached" messages get printed to the console. I've experimented with trying to create a skeleton driver and registering it with: DRIVER_MODULE(timer, nexus, timer_driver, timer_devclass, 0, 0); This does get my skeleton's probe method get called, but it just gets passed the nexus0 device_t, and I'm not clear on how to get at the children (e.g. the "counter-timer"). I even tried to hack it by including bus_private.h and then walking its children with: TAILQ_FOREACH(child, &dev->children, link) { printf("CHILD: %s\n", DEVICENAME(child)); } But appatantly there are no children, as no iterations occur. Can you point me in the right direction for how and where the probe should really be happening? Perhaps an example of how you guys attach the pci bus would explain it? Thanks, Jamey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Fri Dec 28 16:35:17 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by hub.freebsd.org (Postfix) with ESMTP id 4B72137B41A for ; Fri, 28 Dec 2001 16:35:12 -0800 (PST) Received: (from jake@localhost) by k6.locore.ca (8.11.6/8.11.6) id fBT0alA10549; Fri, 28 Dec 2001 19:36:47 -0500 (EST) (envelope-from jake) Date: Fri, 28 Dec 2001 19:36:47 -0500 From: Jake Burkholder To: Jamey Wood Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: compiling a sparc64 kernel? Message-ID: <20011228193647.A9752@locore.ca> References: <1874114671.1467118741@smi.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1874114671.1467118741@smi.sun.com>; from Jamey.Wood@Sun.COM on Thu, Dec 27, 2001 at 02:14:44PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Thu, Dec 27, 2001 at 02:14:44PM -0800, Jamey Wood said words to the effect of; > > > Hmm. I was hoping you'd get to a mount root prompt. My first > > guess at > > what's happening is that the timer chip in the ultra 1 is generating > > interrupts which are not being handled properly by the kernel. So you > > get an interrupt storm. You could try setting the pil to > > something high > > (say 14), on entry to the kernel in locore.s, which may get a > > little further. > > Setting pil to 14 does get me all the way to a mountroot prompt: Ok, cool. This is a stopgap at best, I mostly wanted to see what was going on. Thomas would like you to try the patch he posted as well, which may print a stray interrupt message. Revert the above change first. > CPU: unknown; please e-mail the following value together > with the exact name of your processor to > . > version register: <0x22001040000507> :) We've got a fix for this as well. > > Really we need a driver for the timer chip, which should be easy > > to nab from netbsd. > > The netbsd driver appears to be in their arch/sparc64/sparc64/clock.c. > I'm having a little trouble understanding the FreeBSD device probing > semantics to take a stab at porting it... It looks like the probe > should work by looking for "counter-timer" in the OFW? Yes, that's the timer chip. What I think you should do is use whatever means necessary to disable the timer early while the kernel is still running on the openfirmware trap table. Right around the tick_stop() in sparc64_init(). You'll need to find the physical address of the timer's registers by traversing the openfirmware device tree and fiddle them using stxa() with asi ASI_PHYS_BYPASS_EC_WITH_EBIT. Look at how the nexus device does it in nexus_probe() (sparc64/sparc64/nexus.c). The timerreg.h header from netbsd seems to have definitions for the timer registers (timerreg_4u). From what I've read in comments it seems that there are 2, one of which is enabled by the firmware. We'd also like to see the properties of the timer openfirmware device node and of the sbus node itself. From the ok prompt do "cd /" and then "ls" and then navigate through the devices using "cd" until you find it, and then do ".properties". > > What I don't understand is where that probing should occur and where > the device attach should occur? From what I can see, the counter-timer > device_t currently gets passed to nexus_probe_nomatch where the "no > driver attached" messages get printed to the console. > > I've experimented with trying to create a skeleton driver and > registering it with: > > DRIVER_MODULE(timer, nexus, timer_driver, timer_devclass, 0, 0); > > This does get my skeleton's probe method get called, but it just gets > passed the nexus0 device_t, and I'm not clear on how to get at the > children (e.g. the "counter-timer"). I even tried to hack it by > including bus_private.h and then walking its children with: > > TAILQ_FOREACH(child, &dev->children, link) { > printf("CHILD: %s\n", DEVICENAME(child)); > } > > But appatantly there are no children, as no iterations occur. > > Can you point me in the right direction for how and where the probe > should really be happening? Perhaps an example of how you guys attach > the pci bus would explain it? You mean you did this in the probe method itself? probe is supposed to return (0) if the device is right or (ENXIO) if not. In attach you will be passed the device_t of the device itself. The code for the psycho upa to pci bridge is in sparc64/pci/psycho.c, which attaches to the nexus (in cvs). Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Dec 29 12: 7: 2 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by hub.freebsd.org (Postfix) with ESMTP id 7184137B416 for ; Sat, 29 Dec 2001 12:06:59 -0800 (PST) Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15060 for ; Sat, 29 Dec 2001 13:06:40 -0700 (MST) Received: from smi.sun.com ([127.0.0.1]) by esunmail.central.sun.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GP4004PWFRGD3@esunmail.central.sun.com> for freebsd-sparc@freebsd.org; Sat, 29 Dec 2001 13:04:28 -0700 (MST) Received: from [192.18.102.130] by esunmail.central.sun.com (mshttpd); Sat, 29 Dec 2001 12:04:28 -0800 Date: Sat, 29 Dec 2001 12:04:28 -0800 From: Jamey Wood Subject: Re: compiling a sparc64 kernel? To: freebsd-sparc@freebsd.org Message-id: <1710517c0b.17c0b17105@smi.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Setting pil to 14 does get me all the way to a mountroot prompt: > > Ok, cool. This is a stopgap at best, I mostly wanted to see what > was going on. Thomas would like you to try the patch he posted > as well, which may print a stray interrupt message. Revert the > above change first. With just Thomas's patch (and _not_ setting pil to 14), I get: Booting [/kernel]... calling autoload nothing to autoload yet. post autoload jumping to kernel entry at 0xc0028000. sparc64_init: mdp=0xc01ba000 kmdp=0xc01ba000 boothowto=0 envp=0xc01b8000 end=0x0 Copyri RED State Exception TL=0000.0000.0000.0005 TT=0000.0000.0000.0080 TPC=0000.0000.c002.4200 TnPC=0000.0000.c002.4204 TSTATE=0000.0000.5000.1507 TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 TPC=0000.0000.c002.4d18 TnPC=0000.0000.c002.4d1c TSTATE=0000.0000.5004.1407 TL=0000.0000.0000.0003 TT=0000.0000.0000.0068 TPC=0000.0000.c002.8798 TnPC=0000.0000.c002.879c TSTATE=0000.0000.5000.1507 TL=0000.0000.0000.0002 TT=0000.0000.0000.0010 TPC=0000.0000.c00d.80c0 TnPC=0000.0000.c00d.80c4 TSTATE=0000.0000.5000.1606 TL=0000.0000.0000.0001 TT=0000.0000.0000.004e TPC=0000.0000.c00d.7bb4 TnPC=0000.0000.c00d.7bb8 TSTATE=0000.00a5.0000.1605 > > It looks like the probe > > should work by looking for "counter-timer" in the OFW? > > Yes, that's the timer chip. What I think you should do is use > whatever means necessary to disable the timer early while the > kernel is still running on the openfirmware trap table. Right > around the tick_stop() in sparc64_init(). You'll need to find > the physical address of the timer's registers by traversing the > openfirmware device tree and fiddle them using stxa() with asi > ASI_PHYS_BYPASS_EC_WITH_EBIT. Look at how the nexus device does > it in nexus_probe() (sparc64/sparc64/nexus.c). The timerreg.h > header from netbsd seems to have definitions for the timer registers > (timerreg_4u). From what I've read in comments it seems that there > are 2, one of which is enabled by the firmware. Thanks. I'll try to play around with this. > We'd also like to see the properties of the timer openfirmware > device node and of the sbus node itself. From the ok prompt do > "cd /" and then "ls" and then navigate through the devices using > "cd" until you find it, and then do ".properties". Here's that output: ok pwd /counter-timer@1f,3c00 ok .properties address fffc7c00 fffc5860 fffc3060 interrupts 000007f0 000007f1 reg 000001fe 00003c00 00000000 00000020 000001fe 00003860 00000000 00000010 000001fe 00003060 00000000 00000010 name counter-timer --Jamey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message From owner-freebsd-sparc Sat Dec 29 17:42:26 2001 Delivered-To: freebsd-sparc@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id B875737B417 for ; Sat, 29 Dec 2001 17:42:20 -0800 (PST) Received: (qmail 15090 invoked by uid 0); 30 Dec 2001 01:42:19 -0000 Received: from pd9e16d94.dip.t-dialin.net (HELO forge.local) (217.225.109.148) by mail.gmx.net (mp015-rz3) with SMTP; 30 Dec 2001 01:42:19 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16KUzj-0000px-00; Sun, 30 Dec 2001 02:42:35 +0100 Date: Sun, 30 Dec 2001 02:42:35 +0100 From: Thomas Moestl To: Jamey Wood Cc: freebsd-sparc@freebsd.org Subject: Re: compiling a sparc64 kernel? Message-ID: <20011230024235.A461@crow.dom2ip.de> References: <1710517c0b.17c0b17105@smi.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1710517c0b.17c0b17105@smi.sun.com>; from Jamey.Wood@Sun.COM on Sat, Dec 29, 2001 at 12:04:28PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2001/12/29 at 12:04:28 -0800, Jamey Wood wrote: > > > Setting pil to 14 does get me all the way to a mountroot prompt: > > > > Ok, cool. This is a stopgap at best, I mostly wanted to see what > > was going on. Thomas would like you to try the patch he posted > > as well, which may print a stray interrupt message. Revert the > > above change first. > > With just Thomas's patch (and _not_ setting pil to 14), I get: > > Booting [/kernel]... > calling autoload > nothing to autoload yet. > post autoload > jumping to kernel entry at 0xc0028000. > sparc64_init: mdp=0xc01ba000 kmdp=0xc01ba000 boothowto=0 > envp=0xc01b8000 end=0x0 > Copyri > RED State Exception > > TL=0000.0000.0000.0005 TT=0000.0000.0000.0080 > TPC=0000.0000.c002.4200 TnPC=0000.0000.c002.4204 > TSTATE=0000.0000.5000.1507 > TL=0000.0000.0000.0004 TT=0000.0000.0000.0010 > TPC=0000.0000.c002.4d18 TnPC=0000.0000.c002.4d1c > TSTATE=0000.0000.5004.1407 > TL=0000.0000.0000.0003 TT=0000.0000.0000.0068 > TPC=0000.0000.c002.8798 TnPC=0000.0000.c002.879c > TSTATE=0000.0000.5000.1507 > TL=0000.0000.0000.0002 TT=0000.0000.0000.0010 > TPC=0000.0000.c00d.80c0 TnPC=0000.0000.c00d.80c4 > TSTATE=0000.0000.5000.1606 > TL=0000.0000.0000.0001 TT=0000.0000.0000.004e > TPC=0000.0000.c00d.7bb4 TnPC=0000.0000.c00d.7bb8 > TSTATE=0000.00a5.0000.1605 Hmmm, I must have overlooked something. Can you please decode the tpc addresses (using gdb from the s64-toolchain archive or nm)? If they are not making sense, please comment out all instructions that modify %tl in exception.s and look at the addresses again (this will break things later on, but for early crashes it makes debugging a lot easier because the original trap registers are preserved). Thanks, - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message