IRQ routing: how to do the mainboard_picr_data/_intr_data structures?
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change: https://review.coreboot.org/c/coreboot/+/46587/ When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated. Best regards, Mike Banon
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux? On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
Still need your help, friend On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2@gmail.com> wrote:
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux?
On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
Can you give following output with coreboot and OEM bios. lspci -vvvk dmesg cat /proc/interrupt On Thu, 5 Nov, 2020, 6:29 pm Mike Banon, <mikebdp2@gmail.com> wrote:
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2@gmail.com> wrote:
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux?
On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Dear Naresh, please check the attached archive for these files (and tell if there's anything else I need to show) On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki <naresh.solanki.2011@gmail.com> wrote:
Can you give following output with coreboot and OEM bios. lspci -vvvk dmesg cat /proc/interrupt
On Thu, 5 Nov, 2020, 6:29 pm Mike Banon, <mikebdp2@gmail.com> wrote:
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2@gmail.com> wrote:
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux?
On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Mike, I see that IRQ routing that you set in Coreboot is different then that in UEFI bios. I recommend you first try to match them. Required data is already available in the dump you took. Also this link can be of help: https://gist.github.com/mcastelino/4acda7c2407f1c51e68f3f994d8ffc98 IRQ routing is mandatory for non-MSI capable devices so make sure you best match them with UEFI bios for now. There might be some other issues other than IRQ routing but you can focus on them later as they dont seem critical. Please let me know how it goes. Regards, Naresh G Solanki On Mon, Nov 9, 2020 at 7:43 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear Naresh, please check the attached archive for these files (and tell if there's anything else I need to show)
On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki <naresh.solanki.2011@gmail.com> wrote:
Can you give following output with coreboot and OEM bios. lspci -vvvk dmesg cat /proc/interrupt
On Thu, 5 Nov, 2020, 6:29 pm Mike Banon, <mikebdp2@gmail.com> wrote:
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2@gmail.com> wrote:
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux?
On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com>
wrote:
Dear friends, I'm trying to properly program the IRQ tables for
Lenovo
G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Naresh G. Solanki
Thank you very much for your advice, dear Naresh, I will try matching the UEFI routing. Dear Elyes, huge thanks to you for telling me about "getpir" utility - never heard about it before!
this old "getpir" utility may help you ;) You may have to run: coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677
What I already discovered: *) To activate the irq_tables.c / intel_irq_routing_table code, I need to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I don't see it having any visible effect on the IRQ routing: instead, maybe this intel_irq_routing_table is supposed to be a reflection of this routing? *) By adding to mainboard.c / mainboard_pirq_data structure these lines {NB_PCIE_PORT3_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.3 */ /* 0:04.00 / 2:00.00 - IRQ 3 */ {NB_PCIE_PORT4_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.4 */ /* 0:05.00 / 3:00.00 - IRQ 3 */ I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00 devices, which are behind the 0:04.00 and 0:05.00 bridges respectively. And this assignment is even visible by KolibriOS now! But I don't know if it's normal that a lot of devices are sharing the same IRQ 3 now, is it bad? *) For a moment I thought that only _pirq_data structure matters, and set the contains of picr_data/_intr_data to all 0x1F to check this though. But a laptop can't boot with such a change ;-) What I have trouble understanding: what is the relationship between mainboard_picr_data/_intr_data, _pirq_data, and intel_irq_routing_table? If I got the intel_irq_routing_table with getpir - how to convert its' contents to these other tables so that they match each other? Best regards, Mike Banon On Tue, Nov 10, 2020 at 5:52 PM Naresh G. Solanki <naresh.solanki.2011@gmail.com> wrote:
Hi Mike,
I see that IRQ routing that you set in Coreboot is different then that in UEFI bios. I recommend you first try to match them. Required data is already available in the dump you took.
Also this link can be of help: https://gist.github.com/mcastelino/4acda7c2407f1c51e68f3f994d8ffc98
IRQ routing is mandatory for non-MSI capable devices so make sure you best match them with UEFI bios for now.
There might be some other issues other than IRQ routing but you can focus on them later as they dont seem critical.
Please let me know how it goes.
Regards, Naresh G Solanki
On Mon, Nov 9, 2020 at 7:43 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear Naresh, please check the attached archive for these files (and tell if there's anything else I need to show)
On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki <naresh.solanki.2011@gmail.com> wrote:
Can you give following output with coreboot and OEM bios. lspci -vvvk dmesg cat /proc/interrupt
On Thu, 5 Nov, 2020, 6:29 pm Mike Banon, <mikebdp2@gmail.com> wrote:
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2@gmail.com> wrote:
Although I found this article https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if it applies to mainboard_picr_data/_intr_data : considering a problem from my previous msg - where a copy-paste of old picr/intr data structures gave the bad results. Could you please clarify if this article is still valid for these new data structures? If not, how to get the correct values for mainboard_picr_data/_intr_data using Linux?
On Tue, Oct 20, 2020 at 6:23 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, I'm trying to properly program the IRQ tables for Lenovo G505S, because the old IRQ routing is bad and doesn't work for a simple OS like Kolibri. Full details are in the comments under this change:
https://review.coreboot.org/c/coreboot/+/46587/
When I used the old picr_data/intr_data values of G505S for the new structures, I got only 1 IRQ working. However, with a copy-paste of AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some problems. Please advise how to compose mainboard_picr_data/_intr_data and also a intel_irq_routing_table, your help will be very much appreciated.
Best regards, Mike Banon
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Naresh G. Solanki
Hi Mike, On 10.11.20 19:22, Mike Banon wrote:
Thank you very much for your advice, dear Naresh, I will try matching the UEFI routing.
I wouldn't expect too much. If things are configurable in the chipset (they usually are these days) it's possible that coreboot configures them differently and then the tables have to differ too.
this old "getpir" utility may help you ;) You may have to run: coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677
What I already discovered: *) To activate the irq_tables.c / intel_irq_routing_table code, I need to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I don't see it having any visible effect on the IRQ routing: instead, maybe this intel_irq_routing_table is supposed to be a reflection of this routing?
I would only give these things a look if you are 200% sure that you need it. Basically no major OS has used these in two decades, hence most of it in coreboot is untested and broken. I wouldn't be surprised if there isn't a single case of correct PIRQ tables in the tree. You should check what KolibriOS actually uses. If it's not ACPI there are these three options (that I know about): * MP table * PIRQ tables * INT_LINE registers in each PCI device' configuration space The latter is both exceptionally simple and fragile. It ignores that the OS could make any changes at runtime. The expected IRQ number for each PCI device is simply written into that register by the firmware. It's ignored by the hardware but can be read by the OS. Here's a simple example: * Assuming there's a device PCI 03:00.0 triggering PCI INTA. * The chipset is configured to translate that to PIRQ_B. * PIRQ_B is configured to trigger IRQ 4. * Then coreboot would just write 4 into INT_LINE of 03:00.0. The OS could then pick that 4 up and it would work as long as nothing changes the PIRQ configuration. As all the PIRQ information is lost, the OS can't optimize things; but KolibriOS probably wouldn't want to?
*) By adding to mainboard.c / mainboard_pirq_data structure these lines {NB_PCIE_PORT3_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.3 */ /* 0:04.00 / 2:00.00 - IRQ 3 */ {NB_PCIE_PORT4_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.4 */ /* 0:05.00 / 3:00.00 - IRQ 3 */ I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00 devices, which are behind the 0:04.00 and 0:05.00 bridges respectively. And this assignment is even visible by KolibriOS now! But I don't know if it's normal that a lot of devices are sharing the same IRQ 3 now, is it bad?
If sharing is bad depends on the type of devices. As long as they are all PCI devs, it should work (maybe not at maximum efficiency). But if, for instance, it's shared with a legacy UART port, that couldn't work (different mode of IRQ, level vs. edge triggered). I'm not 100% sure, but it seems that with these lines you can control how an interrupt INTA (/B/C/D) message (PCIe always uses in-band messages) is interpreted by the chipset. It looks like you tell it INTA (the most used one) will trigger PIRQ_A, INTB PIRQ_B, etc. If it's really configurable (otherwise I don't see why there should be such a table), you could try to shuffle these around. e.g. { NB_PCIE_PORT4_DEVFN, { PIRQ_B, PIRQ_C, PIRQ_D, PIRQ_A } }, Hope that helps, Nico
Hi Nico, thank you very much for your kind help, it really helped to advance! Please could you answer a small question: While cleaning up some code I noticed there are Misc,Misc0,Misc1,Misc2 interrupts - with the following "magic" values respectively: mainboard_picr_data: [0x08] = 0x5A,0xF1,0x00,0x00, mainboard_intr_data: [0x08] = 0x00,0x00,0x00,0x00, I tried replacing all these values by 0x1F ("unused") : the _intr_data 0x1F values got reverted to 0x00 during the boot time, while the _picr_data 0x1F values stayed - but caused a SeaBIOS to hang while booting (so I had to unbrick a laptop). Do you have any guess: from where these 0x5A,0xF1,0x00,0x00 values for Misc interrupts come from, and why are they essential for a SeaBIOS to work? Bolton FCH BIOS Dev Guide doesn't tell anything about them, just mentions their offsets. Best regards, Mike On Wed, Nov 11, 2020 at 2:43 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Mike,
On 10.11.20 19:22, Mike Banon wrote:
Thank you very much for your advice, dear Naresh, I will try matching the UEFI routing.
I wouldn't expect too much. If things are configurable in the chipset (they usually are these days) it's possible that coreboot configures them differently and then the tables have to differ too.
this old "getpir" utility may help you ;) You may have to run: coreboot/util$ git revert 6c90f3334e65ff4b0ff4900df77bc33d53beb677
What I already discovered: *) To activate the irq_tables.c / intel_irq_routing_table code, I need to enable CONFIG_HAVE_PIRQ_TABLE and CONFIG_GENERATE_PIRQ_TABLE. But I don't see it having any visible effect on the IRQ routing: instead, maybe this intel_irq_routing_table is supposed to be a reflection of this routing?
I would only give these things a look if you are 200% sure that you need it. Basically no major OS has used these in two decades, hence most of it in coreboot is untested and broken. I wouldn't be surprised if there isn't a single case of correct PIRQ tables in the tree.
You should check what KolibriOS actually uses. If it's not ACPI there are these three options (that I know about):
* MP table * PIRQ tables * INT_LINE registers in each PCI device' configuration space
The latter is both exceptionally simple and fragile. It ignores that the OS could make any changes at runtime. The expected IRQ number for each PCI device is simply written into that register by the firmware. It's ignored by the hardware but can be read by the OS. Here's a simple example:
* Assuming there's a device PCI 03:00.0 triggering PCI INTA. * The chipset is configured to translate that to PIRQ_B. * PIRQ_B is configured to trigger IRQ 4. * Then coreboot would just write 4 into INT_LINE of 03:00.0.
The OS could then pick that 4 up and it would work as long as nothing changes the PIRQ configuration. As all the PIRQ information is lost, the OS can't optimize things; but KolibriOS probably wouldn't want to?
*) By adding to mainboard.c / mainboard_pirq_data structure these lines {NB_PCIE_PORT3_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.3 */ /* 0:04.00 / 2:00.00 - IRQ 3 */ {NB_PCIE_PORT4_DEVFN, {PIRQ_A, PIRQ_B, PIRQ_C, PIRQ_D}}, /* x4 PCIe: 02.4 */ /* 0:05.00 / 3:00.00 - IRQ 3 */ I got the interrupts assigned to Ethernet 2:00.00 and WiFi 3:00.00 devices, which are behind the 0:04.00 and 0:05.00 bridges respectively. And this assignment is even visible by KolibriOS now! But I don't know if it's normal that a lot of devices are sharing the same IRQ 3 now, is it bad?
If sharing is bad depends on the type of devices. As long as they are all PCI devs, it should work (maybe not at maximum efficiency). But if, for instance, it's shared with a legacy UART port, that couldn't work (different mode of IRQ, level vs. edge triggered).
I'm not 100% sure, but it seems that with these lines you can control how an interrupt INTA (/B/C/D) message (PCIe always uses in-band messages) is interpreted by the chipset. It looks like you tell it INTA (the most used one) will trigger PIRQ_A, INTB PIRQ_B, etc. If it's really configurable (otherwise I don't see why there should be such a table), you could try to shuffle these around. e.g.
{ NB_PCIE_PORT4_DEVFN, { PIRQ_B, PIRQ_C, PIRQ_D, PIRQ_A } },
Hope that helps, Nico
Hi Mike! The PIRQ_MISC registers in the indirect I/O address space with 0xc00 being the index register aren't IRQ numbers; those configuration bits. To get an idea, have a look at the interrupt routing register chapter of for example AMD publication number 45482 [1]. Not sure if that's the exact one you'll need, but it should be a good starting point. Regards Felix [1] https://www.amd.com/system/files/TechDocs/45482.pdf page 319
Felix, thank you very much - this is exactly what I needed! Also now found a "51192_Bolton_FCH_RRG.pdf" with slightly newer (but similar) info. Dear friends, thank you so much for your kind help! Now this important work is completed for G505S and you're welcome to take a look at https://review.coreboot.org/c/coreboot/+/47852 . Maybe we can fix the IRQs for some other AMD fam15h boards in a similar way. Best regards, Mike Banon On Wed, Nov 18, 2020 at 2:14 AM Felix Held <felix-coreboot@felixheld.de> wrote:
Hi Mike!
The PIRQ_MISC registers in the indirect I/O address space with 0xc00 being the index register aren't IRQ numbers; those configuration bits. To get an idea, have a look at the interrupt routing register chapter of for example AMD publication number 45482 [1]. Not sure if that's the exact one you'll need, but it should be a good starting point.
Regards Felix
[1] https://www.amd.com/system/files/TechDocs/45482.pdf page 319 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
participants (4)
-
Felix Held -
Mike Banon -
Naresh G. Solanki -
Nico Huber