Date: Sun, 10 Jan 1999 17:06:37 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Wilko Bulte <wilko@yedi.iaf.nl> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: porting to EB64+ / Alpine Message-ID: <Pine.BSF.4.01.9901101702370.543-100000@herring.nlsystems.com> In-Reply-To: <199901101656.RAA05315@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Jan 1999, Wilko Bulte wrote: > As Doug Rabson wrote... > > On Sat, 9 Jan 1999, Wilko Bulte wrote: > > > > > As Doug Rabson wrote... > > > > > > > > sio0: type 16550A > > > > > sio1: reserved for low-level i/o > > > > > panic: possible stack overflow > > > > > > > > > > panic > > > > > Stopped at Debugger..ng+0x24: ldq ra,0(sp) > > > > > <0xfffffc0000578230> <ra=0xfffffc00004 > > > > > 698b8,sp=0xfffffc0000578230> > > > > > db> > > > > > > > > > > I have also seen 'panic: clock not attached'. As I'm trying to find my way > > > > > around in the kernel source tree I appreciate any hints. > > > > > > > > This usually happens if an interrupt is enabled but not handled. The > > > > interrupt exception tries to return but is immediately reentered with a > > > > few bytes less stack. > > > > > > Interrupts... (I did not have any interrupt mapping setup ;-) I'm trying > > > to get an understanding of how that works now. > > It seems you don't really need a mapping setup, the SRM seems to do that > for you on the EB64+ (???? here). Ideally we shouldn't need to generate the mapping for any platforms and SRM would program the intline of the pci config space with the right number. This happens for newer systems but not for old ones. > > > > Somewhat related question: I would appreciate the output of SHOW CONF > > > of a genuine EB64+. My Aspen Alpine is different enough to make this > > > interesting. > > > > I imagine that SRM had enabled a few pci interrupts for booting and this > > is what was interrupting. Most of the platform code (e.g. > > dec_st550.c) disables all the interrupts that it doesn't know about to > > avoid this. > > This was the golden tip. I disabled all interrupts except for the ISA-PCI > bridge (is this right BTW?). Now the Alpine is happily running FreeBSD: It sounds right (for an apecs based platform) as long as you don't lose something important like the clock :-). > > alpine#w > 5:47PM up 36 mins, 2 users, load averages: 0.00, 0.00, 0.00 > USER TTY FROM LOGIN@ IDLE WHAT > root p0 yedi 5:41PM - w > root p1 yedi 5:44PM 3 -sh (sh) > alpine#uname -a > FreeBSD alpine.iaf.nl 3.0-CURRENT FreeBSD 3.0-CURRENT #4: Sun Jan 10 > 15:11:45 CET 1999 root@axp33.iaf.nl:/usr/src/sys/compile/GENERIC alpha > alpine# > > There are a few things I don't understand, like why the 100Mbit DE500 card > does not want to work in the Alpine. > > Anyway, I'll have it build world as a test. In the meantime I can finally > read the EB64+ tech manual ;-) ;-) Nice to see the beast up and running - we'll have to get the support into the tree. I forget, do you have commit privs? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9901101702370.543-100000>