j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Wed, Apr 4, 2012 at 20:15, Artyom Tarasenko email@example.com wrote:
On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl firstname.lastname@example.org wrote:
On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter email@example.com wrote:
On 2012-Apr-4 13:30 , Artyom Tarasenko wrote:
Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus?
On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000
What is mapped to what?
I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them.
These are documented at least as far back as the Safari binding, in section 188.8.131.52 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is:
child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec
Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33.
So, basically, without these properties, software would have no way to tell what CPU interrupt is pulled when the device irq becomes active, right?
The interrupt-map-mask is simply a mask applied to the child information it's defined as
child.hi child.mid child.lo child.intrspec
Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.
Nice explanation. I read the Open Firmware draft interrupt mapping document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), but I was more confused after reading it than before.
Hm. Since it's a part of a standard specification, the other machines (i.e. PPC) might need these properties as well?
Probably. There used to be PPC OF device tree dumps in this site but it's no longer there: http://penguinppc.org/historical/dev-trees-html/
-- Regards, Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu