No PCIe INTx generated by wifi module

[AXEL2]

Hello,

We are using the Intel provided coreboot 566288-apollo-lake-coreboot-mr4-tgz.zip/
566285-apollo-lake-soc-fsp-mr5-tgz.zip with an "in-house" developped board based
on the Intel x5-E3930 CPU (Apollo Lake).

This board was designed using the Intel Oxbow-Hill CRB and it works really fine with
one exception: we don't have any INTx (legacy emulation) interrupts generated by an
Atheros ath9k wifi module installed on the Mini-PCIe expansion connector which is
behind the CPU's PCIe-A0 PCe-to-PCIe bridge.

We use a Linux Ubuntu as the main OS.

I mention that Linux uses explicitely the INTx for the ath9k wifi module since it has
this limitation and it can't use MSI/MSI-X.

Do you have any solution to solve this problem for the Intel provided coreboot/Fsp ?

Thanking you in advance,
Best regards,

Jacky Bourbon,

[Diego_INTEL]

Hello @AXEL2,

Thank you for contacting Intel Embedded Community.

Apollo Lake is no longer being supported and unfortunately many documents are not available anymore.

I understand that Apollo Lake supports some interrupt methods, there was a document that may be of help, document #559811 - Apollo Lake Platform Intel Architecture Firmware Specification (Volume 2 of 2).

"Section 10 - Interrupts and IRQs".

Unfortunately, I looked for the document in RDC and it is no longer available. I'm mentioning the document just in case, but there is not much we can do, my apologies.

Best regards,

@Diego_INTEL 

[AXEL2]

Hello Diego,

Thank you for the answer and for indicating us the document.  Fortunately we have it  but doesn't seem to give us the solution. In the meantime I performed the following experiment: I disabled the Linux MSI/MSI-X usage at grub level with the "nomsi" setting. Indeed, linux doesn't use MSI/MSI-X anymore. All internal Apollo Lake devices (e.g. igd, xhci, etc) continue to WORK FINE with the INTx system. Only the two external devices, the i210 Ethernet Controller and the ath9k wifi module, which are behind the PCIe-to-PCIe bridges DONT WORK with the INTx system. It seems that the PCIe-to-PCIe bridge either doesn't forward the INTx assertion/deasserion at all or those transactions maybe have a wrong content. I can't find any information about this subject at the PCIe-to-PCIe bridge level (if the problem is there, of course).

I also looked at the ACPI tables in Intel  provided MR4 coreboot and they seem ok. I'm stuck for the moment.

Any idea is welcome.

Thank you and best regards,

Jacky

[Diego_INTEL]

Hello @AXEL2,

It seems that the PCIe bridge is not supported in the Apollo Lake platform. I looked internally and found that Apollo Lake does not have the Subtractive Decoding Agent which allows the use of PCIe for legacy usage.

Best regards,

@Diego_INTEL 

[AXEL2]

Hello Diego,

Thank you for the answer.
I don't think it's a hardware limitation but a problem coming
from the Intel provided 566288-apollo-lake-coreboot-mr4-tgz.zip.

I performed the following test:
Using a Conga-QA5 module having an x5-E3930 Atom processor and 2GB RAM,
as AXEL "in house" board has, but being driven by an AMI BIOS, we have no problems of INTx
generation with the ath9k module on the same Linux Ubuntu.

Here you find the PIRQ and PIR registers dump coming from AXEL "in house" board
after booting with the Intel provided 566288-apollo-lake-coreboot-mr4-tgz.zip.

I don't know which software part of the coreboot initialized them with these values.
Maybe the FSP blob or some TXE firmware ? Can't find it in the coreboot source code.

PIRQ register values
--------------------
pirqa_reg=0x03 //R_PCH_PCR_ITSS_PIRQA_ROUT (offset 0x3100)
pirqb_reg=0x04 //R_PCH_PCR_ITSS_PIRQB_ROUT (offset 0x3101)
pirqc_reg=0x05 //R_PCH_PCR_ITSS_PIRQC_ROUT (offset 0x3102)
pirqd_reg=0x06 //R_PCH_PCR_ITSS_PIRQD_ROUT (offset 0x3103)
pirqe_reg=0x07 //R_PCH_PCR_ITSS_PIRQE_ROUT (offset 0x3104)
pirqf_reg=0x09 //R_PCH_PCR_ITSS_PIRQF_ROUT (offset 0x3105)
pirqg_reg=0x0a //R_PCH_PCR_ITSS_PIRQG_ROUT (offset 0x3106)
pirqh_reg=0x0b //R_PCH_PCR_ITSS_PIRQH_ROUT (offset 0x3107)

PIR register values
-------------------
pir_reg=0x0000 //R_PCH_PCR_ITSS_PIR0_INTR (offset 0x3140)
pir_reg=0x7777 //R_PCH_PCR_ITSS_PIR1_INTR (offset 0x3142)
pir_reg=0x3333 //R_PCH_PCR_ITSS_PIR2_INTR (offset 0x3144)
pir_reg=0x5555 //R_PCH_PCR_ITSS_PIR3_INTR (offset 0x3146)
pir_reg=0x0000 //R_PCH_PCR_ITSS_PIR4_INTR (offset 0x3148)
pir_reg=0x4444 //R_PCH_PCR_ITSS_PIR5_INTR (offset 0x314a)
pir_reg=0x5476 //R_PCH_PCR_ITSS_PIR6_INTR (offset 0x314c)
pir_reg=0x1111 //R_PCH_PCR_ITSS_PIR7_INTR (offset 0x314e)
pir_reg=0x2222 //R_PCH_PCR_ITSS_PIR8_INTR (offset 0x3150)
pir_reg=0x3333 //R_PCH_PCR_ITSS_PIR9_INTR (offset 0x3152)
pir_reg=0x4444 //R_PCH_PCR_ITSS_PIR10_INTR (offset 0x3154)
pir_reg=0x0000 //R_PCH_PCR_ITSS_PIR11_INTR (offset 0x3156)
pir_reg=0x3210 //R_PCH_PCR_ITSS_PIR12_INTR (offset 0x3158)

I'll try to dump the same registers on the Conga-QA5 module with AMI BIOS and
compare their contents with those found on AXEL "in house" board shown above.

Kind Regards,
Jacky Bourbon