LS1043 interrupt-map fixup bug in u-boot?

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LS1043 interrupt-map fixup bug in u-boot?

2,378件の閲覧回数
sp_qoriq
Contributor III

Is there an bug in the logic how the legacy interrupt routing is fixed up in the u-boot? I'm referring to the  `_fdt_fixup_pci_msi()` routine, in the `arch/arm/cpu/armv8/fsl-layerscape/fdt.c` file:

if (rev > REV1_0) {
tmp[1][6] = cpu_to_fdt32(val + 1);
tmp[2][6] = cpu_to_fdt32(val + 2);
tmp[3][6] = cpu_to_fdt32(val + 3);
} else {
tmp[1][6] = cpu_to_fdt32(val);
tmp[2][6] = cpu_to_fdt32(val);
tmp[3][6] = cpu_to_fdt32(val);
}

Looking at the documentation, Table 5-1, Interrupt Assignments, all 4 legacy interrupts (INTA, INTB, INTC, INTD) are routed to same interrupt number in rev1_1. So, shouldn't the first line in the above code above be:

if (rev > REV1_0) {
tmp[1][6] = cpu_to_fdt32(val);
tmp[2][6] = cpu_to_fdt32(val);
tmp[3][6] = cpu_to_fdt32(val);
} else {

tmp[1][6] = cpu_to_fdt32(val + 1);
tmp[2][6] = cpu_to_fdt32(val + 2);
tmp[3][6] = cpu_to_fdt32(val + 3);
}

I hope I'm wrong; can someone correct me please? Thanks.

ラベル(1)
0 件の賞賛
返信
5 返答(返信)

1,780件の閲覧回数
sp_qoriq
Contributor III

This bug is fixed in the following u-boot commit: correct PICe INTx fixup,

PavelChubakov‌, you can consider the issue closed now.

0 件の賞賛
返信

1,780件の閲覧回数
Pavel
NXP Employee
NXP Employee

It is not a bug.

Look at the AN5315 Application Note:

https://www.nxp.com/webapp/Download?colCode=AN5315&location=null

 

See also the following pages:

https://u-boot.denx.narkive.com/f10wsl3M/patch-v6-2-2-armv8-fsl-layerscape-fdt-fixup-ls1043a-rev1-ms...

 

http://u-boot.10912.n7.nabble.com/RESEND-V7-1-2-armv8-ls1043a-fixup-GIC-offset-for-ls1043a-rev1-td27...


Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 件の賞賛
返信

1,780件の閲覧回数
sp_qoriq
Contributor III

Can you please clarify your original answer? Thanks.

0 件の賞賛
返信

1,780件の閲覧回数
sp_qoriq
Contributor III

Hi Pavel,

I have looked at the application note and understand the difference in how MSI is implemented between rev1.0 and rev1.1 of the LS1043a silicon. But, the above piece of code fixes up the "legacy" interrupts. Even the legacy interrupt mapping is different between the two revisions of the CPU. Rev1.0 of the CPU has 4 dedicated lines, one each for INTA, INTB,INTC and INTD. In rev1.1, all 4 of the legacy PCI interrupts are multiplexed to "single" interrupt line. But, the logic as implemented in the piece of code I mentioned above does exactly REVERSE of that.

As I mentioned in my second post, with the u-boot code as is, 3 of 4 PCIe functions are not getting enumerated because of interrupt conflict. This should be true when you plug in any PCIe device with 4+ functions supporting only the legacy PCI interrupts to the NXP reference board. Otherwise, how do you explain this enumeration failure (please see the log from my 2nd post)?

thanks,

-Shiva

0 件の賞賛
返信

1,780件の閲覧回数
sp_qoriq
Contributor III

Bump; can any of the NXP FAEs please reply?

I have a PCIe-USB controller connected to PCIe slot of the LS1043a reference design board. This controller implements 4 EHCI controllers as 4 PCIe functions. With the default u-boot, only one of the controllers is getting enumerated. Other 3 controllers fail to get enumerated because of interrupt conflict. I have tried even LSDK_1803 u-boot as well; and this problem persists. I have attached the boot log for your reference.

0 件の賞賛
返信