Artyom Tarasenko | 4 Apr 19:30 2012
Picon

sun4u interrupt-map

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.

Artyom

--

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

Tarl Neustaedter | 4 Apr 19:59 2012
Picon

Re: sun4u interrupt-map

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 5.2.1.4 (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.
(Continue reading)

Blue Swirl | 4 Apr 21:58 2012
Picon

Re: sun4u interrupt-map

On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2 <at> tarl.net> 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
> 5.2.1.4 (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
(Continue reading)

Artyom Tarasenko | 4 Apr 22:15 2012
Picon

Re: sun4u interrupt-map

On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel@...> wrote:
> On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2@...> 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
>> 5.2.1.4 (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
(Continue reading)

Blue Swirl | 4 Apr 22:39 2012
Picon

Re: sun4u interrupt-map

On Wed, Apr 4, 2012 at 20:15, Artyom Tarasenko <atar4qemu <at> gmail.com> wrote:
> On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel <at> gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2 <at> tarl.net> 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
>>> 5.2.1.4 (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
(Continue reading)

Tarl Neustaedter | 4 Apr 22:25 2012
Picon

Re: sun4u interrupt-map

On 2012-Apr-4 16:15 , Artyom Tarasenko wrote:
> So, basically, without these properties, software would have no way to
> tell what CPU interrupt is pulled when the device irq becomes active,
> right?

That's correct. The normal, default, cases work fine - where the 
interrupts are routed along the same paths as the data. These properties 
let us work around the cases where hardware engineers decided to wire 
things differently.

>>
>> >
>> >  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?

Only if they have hardware where interrupts are routed in strange ways.

This originally came about when we wanted separate interrupts for a 
bunch of small devices which were all connected through the same bridge 
- and normal behaviour would have muxed several of these interrupts onto 
overlapping A/B/C/D interrupt lines. By routing the interrupts directly 
into pins giving us unique interrupts, we avoided having OS software 
having to poll each of several devices on every interrupt.

Note that these interrupt properties aren't actually used by Openboot - 
they're just passed along to make life easier on Solaris (and other 
clients).
(Continue reading)

Artyom Tarasenko | 5 Apr 00:15 2012
Picon

Re: sun4u interrupt-map

On Wed, Apr 4, 2012 at 7:59 PM, Tarl Neustaedter <tarl-b2@...> 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
> 5.2.1.4 (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
(Continue reading)

Tarl Neustaedter | 5 Apr 00:37 2012
Picon

Re: sun4u interrupt-map

On 2012-Apr-4 18:15 , Artyom Tarasenko wrote:
>> >  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.
> And what are child.hi and child.lo? Is it the physical address, stored
> in the reg property?

Yes. It's bus-binding specific. I don't remember what the parent bus of 
the PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI 
root complex. It should be from the reg property of that same PCI node.

> But then the filter (address&   0x3e) == 0x3c can potentially hit
> really a lot of devices?

In this case, the mask of 0x3e (0011.1110) presumably indicates there 
are only five meaningful bits in the child address that should be used 
for comparison. Interestingly, by having a zero in the intrspec field, 
presumably it only allows one interrupt (zero) to be mapped in this case.

Kristen Eisenberg | 5 Apr 18:33 2012
Picon

[PATCH] Support any build directory

On Sat, Sep 3, 2011 at 10:58 AM, Andreas Färber <andreas.faerber at web.de> wrote:
> Am 28.08.2011 um 17:28 schrieb Blue Swirl:
>
>> Detect source path from switch-arch call path. Always use absolute
>> paths. Fix bootstrap.c so that for absolute paths, in addition to
>> include directives (-I), the bare path is checked.

Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de
- Billige Flüge vergleichen
<div><div>
<div>On Sat, Sep 3, 2011 at 10:58 AM, Andreas F&auml;rber &lt;andreas.faerber at web.de&gt; wrote:<br>&gt; Am 28.08.2011 um 17:28 schrieb Blue Swirl:<br>&gt;<br>&gt;&gt; Detect source path from switch-arch call path. Always use absolute<br>&gt;&gt; paths. Fix bootstrap.c so that for absolute paths, in addition to<br>&gt;&gt; include directives (-I), the bare path is checked.</div>
<div><br></div>
<div>

<div class="MsoNormal"><span lang="DE">Kristen Eisenberg</span></div>

<div class="MsoNormal"><span lang="DE">Billige Fl&uuml;ge</span></div>

<div class="MsoNormal"><span lang="DE">Marketing GmbH</span></div>

<div class="MsoNormal"><span lang="DE">Emanuelstr. 3,</span></div>

<div class="MsoNormal"><span lang="DE">10317 Berlin</span></div>

<div class="MsoNormal"><span lang="DE">Deutschland</span></div>

<div class="MsoNormal"><span lang="DE">Telefon: +49 (33)</span></div>

<div class="MsoNormal"><span lang="DE">5310967</span></div>

<div class="MsoNormal"><span lang="DE">Email:</span></div>

<div class="MsoNormal"><span lang="DE">utebachmeier at</span></div>

<div class="MsoNormal"><span lang="DE">gmail.com</span></div>

<div class="MsoNormal"><span lang="DE">Site:</span></div>

<div class="MsoNormal"><span lang="DE">http://flug.airego.de</span></div>

<div class="MsoNormal">- Billige Fl&uuml;ge vergleichen</div>
</div>
</div></div>
Artyom Tarasenko | 5 Apr 23:37 2012
Picon

Re: sun4u interrupt-map

On Thu, Apr 5, 2012 at 12:37 AM, Tarl Neustaedter <tarl-b2@...> wrote:
> On 2012-Apr-4 18:15 , Artyom Tarasenko wrote:
>>>
>>> >  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.
>>
>> And what are child.hi and child.lo? Is it the physical address, stored
>> in the reg property?
>
>
> Yes. It's bus-binding specific. I don't remember what the parent bus of the
> PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI root
> complex. It should be from the reg property of that same PCI node.
>
>> But then the filter (address&   0x3e) == 0x3c can potentially hit
>>
>> really a lot of devices?
>
>
> In this case, the mask of 0x3e (0011.1110) presumably indicates there are
> only five meaningful bits in the child address that should be used for
> comparison. Interestingly, by having a zero in the intrspec field,
> presumably it only allows one interrupt (zero) to be mapped in this case.

I gave the following shot:

0 > show-devs
ffe1a2b0 /
( ... )
ffe29140 /pci <at> 1fe,0 (pci)
ffe299a8 /pci <at> 1fe,0/pci <at> 1 (pci)
ffe2a060 /pci <at> 1fe,0/pci <at> 1,1 (pci)
ffe2aeb8 /pci <at> 1fe,0/ebus <at> 3
ffe2bb00 /pci <at> 1fe,0/ebus <at> 3/su <at> 0,1 (serial)
( ... )

ok
cd /pci <at> 1fe,0/ebus
000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+
ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property

0000001f encode-int 00ffffff encode-int encode+ 00000003 encode-int encode+
" interrupt-map-mask" property

cd /pci <at> 1fe,0/ebus <at> 3/su
1 encode-int " interrupts" property
device-end

And Linux's of_device_64 interprets it the following way:

/pci <at> 1f,0: direct translate 7f0 --> 1
/pci <at> 1f,0: direct translate 7ee --> 1
/pci <at> 1f,0: direct translate 7ef --> 1
/pci <at> 1f,0: direct translate 7e5 --> 1

^^^^^ This is strange but is the same regardless my interrupt-map try above.

/pci <at> 1f,0/ebus <at> 3/su <at> 1fe,20003f8: Apply [/pci <at> 1f,0/ebus <at> 3:1] imap --> [NULL:1]

^^^^^ Have I done something wrong, or more interrupt mappings  is needed?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

--

-- 
OpenBIOS                 http://openbios.org/
Mailinglist:  http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you


Gmane