20 Oct
2020
20 Oct
'20
5:23 p.m.
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
24 Oct
24 Oct
10:15 a.m.
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(a)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
5 Nov
5 Nov
1:59 p.m.
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2(a)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(a)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
6:08 p.m.
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(a)gmail.com> wrote:
Still need your help, friend
On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2(a)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(a)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(a)coreboot.org
To unsubscribe send an email to coreboot-leave(a)coreboot.org
9 Nov
9 Nov
3:03 p.m.
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(a)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(a)gmail.com> wrote:
>
> Still need your help, friend
>
> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2(a)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(a)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(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
10 Nov
10 Nov
3:52 p.m.
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(a)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(a)gmail.com> wrote:
--
Best regards,
Naresh G. Solanki
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(a)gmail.com> wrote:
>
> Still need your help, friend
>
> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2(a)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(a)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(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
7:22 p.m.
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(a)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(a)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(a)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(a)gmail.com> wrote:
>> >>
>> >> Still need your help, friend
>> >>
>> >> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon <mikebdp2(a)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(a)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(a)coreboot.org
>> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org
>
>
>
> --
> Best regards,
> Naresh G. Solanki
11 Nov
11 Nov
12:43 a.m.
Hi Mike,
On 10.11.20 19:22, Mike Banon wrote:
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?
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? *) 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
17 Nov
17 Nov
9:20 p.m.
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(a)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
18 Nov
18 Nov
12:13 a.m.
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
21 Nov
21 Nov
9:02 p.m.
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(a)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(a)coreboot.org
> To unsubscribe send an email to coreboot-leave(a)coreboot.org
251
days inactive
283
days old
10 comments
4 participants
participants (4)
-
Felix Held -
Mike Banon -
Naresh G. Solanki -
Nico Huber