Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
ron minnich [mailto:rminn...@gmail.com] wrote: ]On Tue, May 13, 2014 at 5:29 AM, Peter Stuge pe...@stuge.se wrote: ] ] That's an important question, but I believe the answer is no. ] ]That's all I wanted to know, to start. ] ]So why don't we just get that CL in and see where we go from there. ] ]Thanks all. And sorry if I was too hard on kolibrios. It's totally ]wonderful that they are building a from-the-bottom-up OS that gives ]people a close view of how things really work. ] ]ron Thank you and everyone for all the ideas and suggestions. Rudolf pointed out that coreboot already has an option for setting up the PCI config space 3C register: CONFIG_PIRQ_ROUTE. This initially looked like the proper way to enable the PIC mode routing code. On the other hand, experiments suggest this might not be the best way to do it. Testing Ubuntu with the E350M1 OEM BIOS gives these results for the south bridge SATA controller: grub options: acpi=off noapic debugger: clear SATA controller 3C register before Ubuntu boot. result: ahci :00:11.0: can't find IRQ for PCI INT A; please try using pci=biosirq irq 10: nobody cared (try booting with the irqpoll option) Disabling IRQ #10 ata4.00: qc timeout (cmd 0xa1) grub options: acpi=off noapic debugger: clear SATA controller PIC routing before Ubuntu boot. result: SATA operation is extremely slow. Apparently the SATA ISR is called occasionally due to interrupt sharing. In PIC mode with acpi=off, the OS can only look at the MPS table or PIR table for interrupt info. These don't tell the OS what interrupt BIOS has assigned. In addition, the tables don't give enough info to allow the OS to program the interrupt itself. So to make Ubuntu work in PIC mode using MPS or PIR tables, both the 3C register and SB routing register must be setup by BIOS. This leads to an argument that CONFIG_PIRQ_ROUTE shouldn't exist. Instead, the PIC routing and 3C reporting should be done any time the MPS or PIR tables are included. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
ron minnich wrote: Why shouldn't coreboot do legacy initialization? What is the reason to be *less* compatible than possible? The main question I had was whether enabling this set of interrupts could negatively impact other payloads. That's an important question, but I believe the answer is no. If the answer would be yes, how would all the software which we use as payloads work with a legacy firmware? The ones which aren't *exclusively* payloads (depthcharge comes to mind as an exception) were originally running on top of a legacy firmware instead of after coreboot, and they work. The goal of linuxbios and coreboot was always to do as little as possible, not act like a BIOS. I understand your point and I agree with what you mean, but I don't know if I agree that configuring interrupt routers lies squarely in the legacy BIOS domain. But we might decide that indeed it does, in which case we'll have to push PIC configuration into all payloads; ie. SeaBIOS and libpayload at a very minimum. What about APIC config? Why would we do one and not the other? By their very design, they are compatible with each other. This is why Windows XP can be installed in either Standard PC or ACPI PC mode, and work, on machines with a firmware which configures both PIC and APIC. Simple example: if we enable all these interrupts, and a non-kolibrios payload boots, is there a chance that a broadcast packet could be picked up by the NIC and interrupt the non-kolibrios payload? Hang on - is enabling interrupts equivalent to configuring the interrupt controller? I know that's not the case at least with the PIC. I guess neither with the APIC. Is there anything in there that is a one-way initialization that might make it harder for for _MP_, ACPI, MSI, or MSI-X? I don't think we should include a solution which goes in such a direction unless it is only very temporary. The things you mention are all younger than the PIC, so they have already been designed to live alongside the legacy hardware. I just want to hear that the answer is no. I have yet to hear it. It's a pretty simple question. And it's a good one. I do believe that the answer is no. And the question remains: why is it kolibrios can't just read the $PIR and/or _MP_ like everything else has somehow managed to do for 15 years? It would be interesting to know exactly where it reads the interrupt number. It might e.g. be calling the PCI BIOS services, and SeaBIOS might be reading from a register which hasn't been programmed. (I'm not saying this is the case, it's only one possibility.) Why are we doing these config writes in coreboot when the OS should do them? And why are we doing this for *one* OS? I'm not sure that the OS should do them. And maybe more OSes need it, just that they haven't been tested yet. I would certainly welcome research into the matter, which is neccessary to build the required data model for coreboot. The NIC bus number is hard-coded at the moment. This needs fixing if the NIC bus number can change. Are you seriously telling me you want coreboot to hardware the bus number for a NIC? That's a terrible idea. No, I'm not telling you that I want that. I'm telling you that coreboot needs to model hardware init completely and accurately. It doesn't yet. In general, we've tended not to set up too much interrupt hardware for a simple reason: we do have lots of payloads, and the odds are very good if you do too much setup - you're wasting time I can't take this too seriously, since it's a matter of a few register writes. - you're doing the wrong thing for the payload - it may confuse the payload you eventually boot. These are essentially the same point. I'm not at all sure that configuring the PIC can ever be the wrong thing for any piece of software which runs on a PC derivative. Finally, we actually always tried from the beginning to no setup up IRQs. And boy how much trouble has been caused by that design decision. :\ The emphasis was on creating the tables that let the payload do the right thing. Which might have been fine, except unfortunately the payloads never learned to use the tables, and the system doesn't just worktm. Communicating IRQ info to the kernel is what we've done; We must of course still. actually configuring the PIC is a violation of the early design goals. I either disagree with it being a violation, or I think the early design goals were broken in this aspect. I'm not sure which it is at this point, it could be either! Thanks //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
On Tue, May 13, 2014 at 5:29 AM, Peter Stuge pe...@stuge.se wrote: That's an important question, but I believe the answer is no. That's all I wanted to know, to start. So why don't we just get that CL in and see where we go from there. Thanks all. And sorry if I was too hard on kolibrios. It's totally wonderful that they are building a from-the-bottom-up OS that gives people a close view of how things really work. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
ron minnich wrote: I'm not really happy that we're doing all this PIC setup for one OS, It's not for one OS, Ron. PIC setup is part of the PC legacy. Please remember that coreboot is more than Chrome OS' firmware of choice. It's been quite some time since I've had to use PIC mode at all. Thanks to the efforts of Paul and Scott we were using it quite a bit at LinuxTag. KolibriOS booting from flash in a blink of an eye is an impressive demo. You should try it in qemu. It makes the coreboot point extremely clear, and was quite a valuable things to have. Why can't the Kolibrios just use modern standards? Please stay on point; PC firmware. Another way to explain what I mean is with a counter-question: Why shouldn't coreboot do legacy initialization? What is the reason to be *less* compatible than possible? It's bizarre, to say the least, to be booting a kernel written in assembly from firmware written in C. I think it makes a lot of sense. It demonstrates how complexity has shifted from OS into firmware over the decades. I find it hard to believe that we want this patch. I want this patch and more. I want a data and API model within coreboot which allows common code for the three reporting mechanisms to call platform-specific code to program them automatically, when the respective tables have been enabled by Kconfig. They need to be enabled by default and perhaps hidden behind CONFIG_EXPERT. Scott Duplichan wrote: This is needed for all operating systems that support PIC mode. For example, Ubuntu 13.10 with boot option acpi=off fails. With the attached revised patch, it works. To me it's a no-brainer to accept this patch and build on it. This is an important aspect where coreboot does a much worse job than it could, for no real reason. It is OK with me to take no action on the patch. I disagree. I think this is a very important patch. Thank you. the patch is here in the mailing list archives, and anyone who really wants PIC mode will find it. The patch probably needs sanitization and additional testing anyway. I would love for this patch to be pushed to Gerrit. Scott, can you do that easily, or would you prefer if I do it? I want you as the author to give a +2 before it is submitted. If this policy hasn't already been implemented then a workaround is for you to give a -2 immediately after pushing the commit. Thank you! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
On Mon, May 12, 2014 at 09:13:26PM +0200, Peter Stuge wrote: ron minnich wrote: I'm not really happy that we're doing all this PIC setup for one OS, It's not for one OS, Ron. PIC setup is part of the PC legacy. Please remember that coreboot is more than Chrome OS' firmware of choice. It's been quite some time since I've had to use PIC mode at all. Thanks to the efforts of Paul and Scott we were using it quite a bit at LinuxTag. KolibriOS booting from flash in a blink of an eye is an impressive demo. You should try it in qemu. It makes the coreboot point extremely clear, and was quite a valuable things to have. I can can confirm that it was an impressive demo for our visitors! Thanks to Scott and Paul also from me. I think this patch should go in. Regards, Björn pgpLlt21ZZ0WW.pgp Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
On Mon, May 12, 2014 at 12:13 PM, Peter Stuge pe...@stuge.se wrote: Why shouldn't coreboot do legacy initialization? What is the reason to be *less* compatible than possible? The main question I had was whether enabling this set of interrupts could negatively impact other payloads. The goal of linuxbios and coreboot was always to do as little as possible, not act like a BIOS. Simple example: if we enable all these interrupts, and a non-kolibrios payload boots, is there a chance that a broadcast packet could be picked up by the NIC and interrupt the non-kolibrios payload? Is there anything in there that is a one-way initialization that might make it harder for for _MP_, ACPI, MSI, or MSI-X? I just want to hear that the answer is no. I have yet to hear it. It's a pretty simple question. And the question remains: why is it kolibrios can't just read the $PIR and/or _MP_ like everything else has somehow managed to do for 15 years? Why are we doing these config writes in coreboot when the OS should do them? And why are we doing this for *one* OS? Especially given this grotesque example: The NIC bus number is hard-coded at the moment. This needs fixing if the NIC bus number can change. Are you seriously telling me you want coreboot to hardware the bus number for a NIC? That's a terrible idea. In general, we've tended not to set up too much interrupt hardware for a simple reason: we do have lots of payloads, and the odds are very good if you do too much setup - you're wasting time - you're doing the wrong thing for the payload - it may confuse the payload you eventually boot. So, I'd like to hear the answer to my first question. Finally, we actually always tried from the beginning to no setup up IRQs. The emphasis was on creating the tables that let the payload do the right thing. Communicating IRQ info to the kernel is what we've done; actually configuring the PIC is a violation of the early design goals. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
Hi all, 1) we should provide at least the MP-Table. There is a still lot of OS without ACPI support (various homebrew OS, RTOS etc) which don't want to carry the ACPICA just to get idea how to route IRQs... 2) if we want to setup the PCI for PIC we need to do: a) setup the PCI router (just couple of regs in the SB) This is done by: pirq_assign_irqs() b) setup the ELCR (0x4d0/0x4d1) set IRQs to level, this is done by: i8259_configure_irq_trigger() c) setup the 0x3c values in the PCI regs this is done by: pirq_route_irqs() which does the job if CONFIG_PIRQ_ROUTE Oh yes coreboot knows how to do that if PIR table is present in quite generic way. Setting this up should not break things, except that AMD SB700 or similar needs to disable the IRQ routing to PIC in ASL code in _PIC method. I don't know if this necessary. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
Like I say, if it's not going to do harm, and you all want it, submit the CL. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
Hi Scott! The NIC bus number is hard-coded at the moment. This needs fixing if the NIC bus number can change. The bus number of the NIC changed from 03:00.0 to 04:00.0 when I plugged a PCIe card into the board. Tried that maybe two weeks ago. Regards Felix -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
Scott Duplichan [mailto:sc...@notabs.org] wrote:
[...]
]As for the mouse problem, I think it may be PIC interrupt
]routing related. I see our PIR table is incomplete and also
]the legacy interrupting route reporting registers in PCI
]config space are not filled in. I will look at that tomorrow.
I got the USB mouse working by setting up the PIC interrupt
routing and reporting. For now the changes are in mptable.c.
They may need to be relocated to a better place. The NIC
bus number is hard-coded at the moment. This needs fixing
if the NIC bus number can change.
KolibriOS reads PCI config offset 3C to find PIC interrupt
routing, so these must be filled in. The same values must
be programmed into the SB800 PIC mode interrupt routing
registers. In addition, a change to the legacy mode
edge-level control register setting is needed. An updated
archive is here:
http://notabs.org/coreboot/e350m1-kolibri-001.7z
An mptable.c patch is attached.
diff --git a/src/mainboard/asrock/e350m1/mptable.c
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..b6c5b76 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
extern u32 bus_type[256];
extern u32 sbdn_sb800;
+// SB800 interrupt routing register values: APIC mode
u8 intr_data[] = {
[0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
[0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT
from Serial irq */
@@ -45,6 +46,16 @@ u8 intr_data[] = {
0x10,0x11,0x12,0x13
};
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F, // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F, // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x10
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x20
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F}; // 0x30
+
static void *smp_write_config_table(void *v)
{
struct mp_config_table *mc;
@@ -75,6 +86,12 @@ static void *smp_write_config_table(void *v)
outb(intr_data[byte], 0xC01);
}
+ // progran the SB800 PIC mode interrupt routing register values
+ for (byte = 0x0; byte sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+ }
+
/* I/O Ints:TypePolarityTrigger Bus ID IRQAPIC ID PIN#
*/
#define IO_LOCAL_INT(type, intr, apicid, pin) \
smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH,
bus_isa, (intr), (apicid), (pin));
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
/* There is no extension information... */
+ // program interrupt line registers for legacy OS use
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 1)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x04, 0)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x11, 0)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 0)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 2)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 0)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 2)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 1)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 2)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 5)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 0)), 0x3C, 0x0B);
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 2)), 0x3C, 0x0A);
+ pci_write_config32(dev_find_slot(3, PCI_DEVFN(0x00, 0)), 0x3C, 0x0B);
+
+ // program slave PIC edge-level control register
+ outb (0x0C, 0x4D1);
+
/* Compute the checksums */
return mptable_finalize(mc);
}
Thanks,
Scott
legacy-interrupts.patch
Description: Binary data
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
So, how would these changes affect other payloads? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
ron minnich [mailto:rminn...@gmail.com] wrote: ]So, how would these changes affect other payloads? ] ]ron The patch adds programming and one reporting mechanism for PIC mode PCI interrupt routing for the ASRock E350M1 board only. Without the patch, PIC mode PCI interrupt routing is not programmed and not reported. There are several ways an OS can find PIC mode interrupt routing for PCI devices: 1) $PIR table 2) ACPI 3) PCI config space interrupt line registers This change adds reporting method 3. Reporting methods 1 and 2 are incomplete or unimplemented for this board. This patch programs PIC mode PCI interrupt routing to match the OEM BIOS. Without the patch, PIC mode PCI interrupt routing is unprogrammed. The changes affect an OS or other code that uses PCI interrupts in PIC mode. APIC mode is unaffected. From what I can remember, older mainstream operating systems normally use the ACPI method to find PIC mode interrupt routing. They might fall back to $PIR or even the config space line register method I suppose. I see some coreboot boards support the ACPI method of reporting (and modifying) PIC mode PCI interrupts. However I don't see this this code in E350M1 project. As a result, an OS such as Windows 2000 may or may not see improvement with this patch. I didn't try it. Linux still supports PIC mode PCI interrupt routing through grub options. I did not test that either. It seems interest in PIC mode interrupts has waned since multicore processors have become popular. A limitation of PIC mode interrupts is that all PCI interrupts are handled by the BSP core and cannot be routed to AP cores. I know of one application that uses PIC mode PCI interrupts and finds them from the config space line register. It is the interrupt test portion of the Broadcom b57diag utility. For operating systems, Windows dropped PIC mode starting with XP x64 edition if I remember correctly. XP 32-bit defaults to APIC mode, but can be switched to PIC mode during installation. After XP, all PIC mode is gone. For linux, PIC mode is still supported, but the default was switched to APIC mode several years ago. I believe there was a time with 32-bit Linux used PIC mode but 64-bit used APIC mode. This is from memory so I could be a little off. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
Thanks, that's a great explanation. Generally, we've tried to avoid too much hardware setup in coreboot; that's the job of the kernel. I'm not really happy that we're doing all this PIC setup for one OS, written in assembly. It's been quite some time since I've had to use PIC mode at all. Why can't the Kolibrios just use modern standards? And why all this effort for an OS written in assembly anyway? Unix v6 kernels were the same size as Kolibrios. They were written in C. That was 40 years ago. It's bizarre, to say the least, to be booting a kernel written in assembly from firmware written in C. Hence, I find it hard to believe that we want this patch. But I'm wrong a lot, so if I am here too, just let me know. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix
ron minnich [mailto:rminn...@gmail.com] wrote:
]Thanks, that's a great explanation. Generally, we've tried to avoid
]too much hardware setup in coreboot; that's the job of the kernel.
The PIC mode interrupt routing configuration must be done by
BIOS because proprietary southbridge registers are used. The
register definitions are not even consistent across different
AMD southbridge models. An OEM BIOS does this configuration.
]I'm not really happy that we're doing all this PIC setup for one OS,
]written in assembly.
This is needed for all operating systems that support PIC mode.
For example, Ubuntu 13.10 with boot option acpi=off fails. With
the attached revised patch, it works.
]It's been quite some time since I've had to use PIC mode at all.
]
]Why can't the Kolibrios just use modern standards? And why all this
]effort for an OS written in assembly anyway?
]
]Unix v6 kernels were the same size as Kolibrios. They were written in
]C. That was 40 years ago. It's bizarre, to say the least, to be
]booting a kernel written in assembly from firmware written in C.
]
]Hence, I find it hard to believe that we want this patch. But I'm
]wrong a lot, so if I am here too, just let me know.
It is OK with me to take no action on the patch. The reason is
that the patch is here in the mailing list archives, and anyone
who really wants PIC mode will find it. The patch probably needs
sanitization and additional testing anyway.
]ron
Patch revisions:
1) With the current code, CONFIG_GENERATE_ACPI_TABLES=1 causes
the PCI interrupts to be omitted from the mptable. With the
revised patch, the mptable always includes PCI interrupts. This
solves the Ubuntu acpi=off problem of can't find IRQ for PCI
INT A; probably buggy MP table.
2) Add PIC mode PCI interrupt values for SATA and IDE devices.
Without this, Ubuntu setup cannot read the CD-ROM.
3) Use 00 for unused PIC mode routing entries rather than 1F.
This is for consistency with the APIC mode table.
Thanks,
Scott
diff --git a/src/mainboard/asrock/e350m1/mptable.c
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..f45385e 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
extern u32 bus_type[256];
extern u32 sbdn_sb800;
+// SB800 interrupt routing register values: APIC mode
u8 intr_data[] = {
[0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
[0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT
from Serial irq */
@@ -45,6 +46,20 @@ u8 intr_data[] = {
0x10,0x11,0x12,0x13
};
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F, // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F, // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, // 0x10
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, 0x00, // 0x20
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x00, // 0x30
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x38
+0x0A, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x40
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // 0x48
+0x0B, 0x0A, 0x0B, 0x0A}; // 0x50
+
static void *smp_write_config_table(void *v)
{
struct mp_config_table *mc;
@@ -75,6 +90,12 @@ static void *smp_write_config_table(void *v)
outb(intr_data[byte], 0xC01);
}
+ // program the SB800 PIC mode interrupt routing register values
+ for (byte = 0x0; byte sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+ }
+
/* I/O Ints:TypePolarityTrigger Bus ID IRQAPIC ID PIN#
*/
#define IO_LOCAL_INT(type, intr, apicid, pin) \
smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH,
bus_isa, (intr), (apicid), (pin));
@@ -84,12 +105,8 @@ static void *smp_write_config_table(void *v)
/* PCI interrupts are level triggered, and are
* associated with a specific bus/device/function tuple.
*/
-#if !CONFIG_GENERATE_ACPI_TABLES
#define PCI_INT(bus, dev, fn, pin) \
-smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW,
(bus), (((dev)2)|(fn)), apicid_sb800, (pin))
-#else
-#define PCI_INT(bus, dev, fn, pin)
-#endif
+ smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW,
(bus), (((dev)2)|(fn)), apicid_sb800, (pin))
/* APU Internal Graphic Device*/
PCI_INT(0x0, 0x01, 0x0, intr_data[0x02]);
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
/* There is no extension information... */
+ // program interrupt line registers for legacy OS use
+ pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+
