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

[Andriy Gapon]

On 09/10/2016 13:02, Andriy Gapon wrote:
> 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.

Apologies, the above references are actually for the HT 1.0 document.
In the HT 3.0 document the tables are 150 and 152.

> 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).

More tests show that individual APIC IDs can also be used in addition to the
broadcast ID.

> 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