[Top] [All Lists]

Re: yet another DECstation kernel

Subject: Re: yet another DECstation kernel
From: Paul Antoine <>
Date: Tue, 10 Feb 1998 10:00:56 +1100 (EST)
In-reply-to: <> from "Stu Allen" at Feb 9, 98 02:24:19 pm
Organization: Softway Pty Ltd
Stu Allen wrote:

> Well, I'm officially bummed.  My hopes were really up with the note
> about "periodic interrupts", but for naught.


> I tried the patch on my little DECsystem 5100, and here are the results:
> 1) The memory sizing routine is broken on this box.  (You get a
> stack dump).  This isn't from the latest patch, but I needed to fix
> this in order to boot.)  I ended up having to hard-code my memory
> size, just as I did in Paul's last tree.  This _may_ be related to
> #3 below.

Hmmm... Harald's clever code depends on being able to catch an
address/bus error when accessing memory that doesn't exist.
Otherwise, the prom code tries to query the boot prom.  I'm assuming
neither of these methods works with the 5100.

> 2) The 5100 returns "0" for the console environment variable, so I
> had to modify the console detection code (easy change).  I see that
> a new patch for this code was just posted; I'll have to take a look
> at that.

Yes, check if it uses the 'osconsole' env. variable instead.  Of
course, if your boot prom can store env. variables then you could
simply create one...

> 3) The kernel gets as far as "Calculating delay loop" and then it
> sits forever.  I think what is happening is that the timer interrupt
> isn't.  Sound logical?

Nope - it's probably interrupting, but just going somewhere else.

> So I get as far as I did with Paul's last tree, but no further.  Any
> hints on what I might look at?  I'm assuming that the interrupt
> vectors aren't being set up right, or maybe the interrupts aren't
> being enabled?

Nope - hopefully just that the int is coming in on another priority...
I'd say that the hardware in the 5100 is different enough that it
routes timer interrupts to a different vector.

One way to check would be to twiddle the interrupt tables so that all
hardware int's point to the timer code.  Then if you see the bogomips
appear you'll know that the timer itself is o.k.

You would then need to twiddle to code some more so that it will print
out which one got the timer interrupt, and hence you will know which
it's on for the 5100.

This all assumes that the timer is directly connected to a MIPs
interrupt, which is a reasonable first guess; otherwise it may be
connected through some hardware you have to turn on, and you'll have
to find docs to help with that.

Paul M. Antoine,                                        Net:
Softway Pty Ltd                                         WWW:
PO Box 305, Strawberry Hills, NSW 2012, Australia       Tel: +61 2 9698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia Fax: +61 2 9699 9174

<Prev in Thread] Current Thread [Next in Thread>