Re: Can't get my PC164 to boot

David A Rusling (
Tue, 26 Nov 1996 10:34:27 +0000

Jay Estabrook said:

> No, MILO does not use SRM PALcode. Only the Evaluation Board PALcode sets
> are available as source, which is what the MILOs are built with. And yes,
> those boxes that aren't EB's are run with modified EB PALcode, like AVANTI
> and MIKASA.
> The EB PALcodes are pretty simple, as they don't worry much about
> interrupts, expecting the kernel to take care of finding the interrupt
> summary registers and dispatching to the appropriate handler. See all the
> grotty details in arch/alpha/kernel/irq.c.
> When configured for running under SRM console and PALcode, the interrupt
> handling of the kernel expects to be told *which* interrupt has occurred.
> One can't, unfortunately, use the non-SRM interrupt handling routines, like
> alcor_and_xlt_device_interrupt(), when running under SRM, as the interrupt
> summary registers have been changed by the SRM PALcode when *it* decodes the
> interrupt, and so will no longer indicate the appropriate state. However,
> the update_hw() routine needs to know all the grotty details about where the
> interrupt registers are, under SRM as well as MILO, to properly manage the
> interrupt mask.
> Note that the AXPpci33 (NONAME) PALcode built into that MILO, actually
> delivers interrupts the same way as SRM PALcode, so the same kernel will
> run under MILO and SRM PALcodes.
> Someday, get Dave Rusling to explain why its beneficial to have the kernel
> know all the interrupt details, as under the EB PALcode.
> --Jay++

OK, I'll rise to the bait. Jay says it himself when he makes the point that even
in the SRM case the kernel has to know an awful lot about the configuration of the
interrupt handling/routing.

Almost every AXP system produced so far has different interrupt handling and routing.
Personally I think that several hardware designers should be taken out and shot for
randomly reinventing interrupt handling. There are a lot of grotty things about the
general PC architecture but at least you can pretty much rely on a consistant aproach
from one Intel box to another. Take a look at /arch/i386/kernel/irq.c and compare that
with /arch/alpha/kernel/irq.c and you'll see that the Alpha case is a lot more confusing.
I would, in a better world, favour a bank of interrupt masks and registers at known I/O
locations but even that does not help you with routing the PCI interrupts to those
registers. Again that differs from board to board, see /arch/alpha/kernel/bios32.c for

So, for each AXP based system, there has to be software somewhere which understands how
to set interrupts and how to figure out what caused interrupts. This interrupt handling
code cannot all live in the PALcode as it is 'architected' - you may note that Digital
Unix running on the same boxes as Linux also has different kernels for the different
boxes. It has them for exactly the same reasons as Linux does - to route and handle
interrupts. This is despite having SRM PALcode which only helps with the interrupt
delivery and is not freely redistributable. In other words, we couldn't use the SRM
PALcode with Linux and not use the SRM.

I believe that the interrupt handling software should be in the kernel. That way,
it's all in one place and it's easier to write/debug/port/understand. However, in
the early days of AXP Linux we used to have multi-platform kernels by including
all of the interrupt handling for each {CPU, support chipset} combination in a single
kernel and using the HWRPB information set up by MILO to call the correct interrupt
handler. Maybe we should re-invent this mechanism.


David A Rusling Principal Engineer
European Semiconductor Applications Digital Equipment Co Ltd.,
Engineering PO Box 121,
Imperial Way,
Worton Grange
Reading RG2 0TU
Linux, Alpha, StrongArm, PCI Tel: UK-(0)1734-204380
Fax: UK-(0)1734-203133

To unsubscribe: send e-mail to with
'unsubscribe' as the subject.  Do not send it to

Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices