[coreboot] AMD platform: IO-APIC => Local APIC delivery modes

Andriy Gapon avg at FreeBSD.org
Sun Oct 9 12:02:05 CEST 2016


On 08/10/2016 23:04, Andriy Gapon wrote:
> On 08/10/2016 20:35, Rudolf Marek wrote:
>> Andriy Gapon wrote:
[...]
>> This has to do about Hypertransportspecification. Please have a look to
>>
>> Table 103. x86 Interrupt Request Packet Format (HT spec version 1.1)
>> There is this MT3 explained.
> 
> Thank you for the pointer!  I will have a look.
> 
>>> I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg 62h of
>>> device 20 function 0 in SB7x0 caught my eye.  Namely, K8_INTR, MT3_Set and
>>> MT3_Auto bits.  They all are about K8 INTR [NMI] message.
>>> On my system the register is set to 0x24, that is K8_INTR is set, but MT3_Set
>>> and MT3_Auto are not...
>>
>> So, this just helps to generate right format to HT bus... maybe the CPU is
>> confused... and you will need to change it. Now it should be more clear what the
>> MT3 means.
> 
> I will try to map those to the HT protocol details.

The HyperTransport Specification is very enlightening.
Thank you, Rudolf, for setting me on that path!
I used version 3.0 found here http://www.hypertransport.org/ht-3-0-link-spec.
Especially useful is Appendix F.1 Interrupts, particularly tables 106 and 108.

The document and some experiments allowed me to understand one important thing.
Both PIC and APIC interrupts are delivered over HyperTransport.  There are no
special physical wires for the PIC interrupts.

Figuring out the MT3_Set and MT3_Auto bits was very easy.
The bits affect only the PIC interrupts, they have no effect on the I/O APIC
interrupts.
On the SB700+Athlon system those bits are unset and that means that MT[3] of the
HyperTransport messages (Message Type, bit 3) is zero.  In turn, that means that
the PIC interrupts are delivered as normal ExtINT interrupts as if they were
coming from the I/O APIC.  That explains why LintEn has the effect on the PIC
interrupts.
The bits are named slightly differently in the SB800 documentation. They are
Mts_set and Mts_auto and they belong to PMIO PM_Reg 08h.
But they have exactly the same function.
On the SB850+Phenom system Mts_set is 1 and Mts_auto is 0.  So, MT[3] is one for
the PIC interrupt messages.  That means that their type is 'Legacy PIC ExtInt
(LINT0)', not the regular ExtInt.  That's why LintEn does not affect them.

So, the above explains everything I see with the PIC interrupts, but does not
explain the problems with the I/O APIC interrupts.  And here I made a wild
guess... and it seems to be correct.

I set Delivery Mode in the redirection table to the HyperTransport defined NMI
message type, 0_011, and it worked!
This is the redirection entry I used: 0xff00000000000300 (note that the
destination is set to the broadcast address as required by Table 106).

There is an apparent bug in the AMD southbridges. Despite what the APIC
specification says and what Table 108 of the HyperTransport 3.0 specification
reiterates, the delivery mode bits are copied as-is into the HyperTransport
messages.  That's not a problem for fixed, lowest priority and SMI interrupts
where the bits are exactly the same.  But the APIC NMI mode gets interpreted as
INIT which explains the problems I was with it.  Also, it seems that APIC ExtINT
mode (111) is an undefined value for the HyperTransport message type, but
messages with that type get treated as normal interrupts.

Rudolf, thank you very much again!
I hope that the findings will help other people too.

-- 
Andriy Gapon



More information about the coreboot mailing list