Re: SmartFirmware interrupts

[Matt Sealey <matt%genesi-usa.com@localhost>]

Frank Wille wrote:
> Matt Sealey wrote:
>
> > [...]
> > only thing stopping you from having a port is to STOP relying on the
> > Open Firmware client interface for abstraction and implement the
> > interrupt controller.
>
> Hm. Which information does SmartFirmware provide about it? The only thing I
> found was "8259-IRQ at f1000cb4". This is for the ISA interrupts?

It's connected in a cascade to the Marvell chip. You do not need to know how
the Marvell PIC works. Just use the 8259 (as is present in every PC known
to man..)

However I am not talking about Pegasos. You guys can, and should, forget
Pegasos for now :)

> Maybe it's because I'm just a beginner, but, are there any other interrupt
> controllers (in the north bridge?)? And how do I know about their registers
> and addresses?
>
> Or how about the interrupts of PCI devices? Other OF implementations have
> properties like "interrupt-map", "#interrupt-cells", "AAPL,interrupts", etc.
> But in SmartFirmware there is nothing. How do I know which interrupt a
> device was assigned to?

I really thought these were present. At least, the interrupt-tree is implemented
in a development firmware (properly!) but what is present on the Efika and
Pegasos is enough to boot.

On Efika, interrupts are *really fixed*, you cannot just assign an interrupt
dynamically to some other peripheral. The MPC5200BUM tells you which ones..

> > Too much time has been wasted on trying to expose a
> > network device or a block device from the device tree... the OpenBSD
> > port to Pegasos was not this complicated, even in the slightest.
>
> I had a look at the OpenBSD port. It definitely accesses the Marvell
> registers directly, e.g. c78, c7c, cf8, cfc, 118, 11c. Base address of the
> chip seems to be f1000000.

These are all PCI address remap registers etc.; not relevant to proper OS
operation since the information is pretty much all in the device tree and
any quirks the firmware puts in there *are not for you* :)

Case in point: Linux doesn't touch 'em.

Poking around too much in the chipset is a good reason for the system to
kick you in the ass.

--
Matt Sealey <matt%genesi-usa.com@localhost>
Genesi, Manager, Developer Relations