-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I will leave for a holiday today. Its difficult to answer that without the patch at hand.
The ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
Means that:
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
For some reason this is wrong. You have same line in the orig bios? If yes there is still smth wrong with APIC. Please check:
Assigned: PCI: 00:10.4 10 * [0xfebffd00 - 0xfebffdff] mem Assigned: PCI: 00:10.5 10 * [0xfebffe00 - 0xfebffeff] mem Assigned: PCI: 00:12.0 14 * [0xfebfff00 - 0xfebfffff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: fec00000 size: 300 align: 8 gran: 0 done
This looks like the mem resources are setup from too high overlaping the IOAPIC with some hardware. No good. Move all resource bases bellow f0000000. You will need to adjust the northbridge.c and put the PCI resource limit to the address above most likely. Others can help here.
Also it seems that you created something in half:
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 *12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12), disabled. ACPI: PCI Interrupt Link [ATAI] (IRQs *20) ACPI: PCI Interrupt Link [USBI] (IRQs *21) ACPI: PCI Interrupt Link [VT8I] (IRQs *22) ACPI: PCI Interrupt Link [NICI] (IRQs *23)
This means you route half of IRQs through APIC and second half through the 8259. Why not route all of them through APIC. Check M2V-MX se board _PRT methods.
INTA# to IRQ16 INTB# to IRQ17 INTC# to IRQ18 INTD# to IRQ19
uhci_hcd 0000:00:10.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. <<---- Whoops !!
Yes maybe but I think all USBs are routed to IRQ21 so it must be smth else. Like the resource conflict I mentioned above. If VT8237R apic is enabled (and it is) this is routed like this:
IDE (Native Mode)/SATA IRQ & INTE to IRQ20 USB IRQ (all 5 functions) and INTF to IRQ21 AC'97 / MC'97 IRQ and INTG to IRQ22 LAN IRQ and INTH to IRQ23
So I would recommend to boot now with init=/bin/bash and provide
cat /proc/iomem cat /proc/interrupts lspci -vvvxxx
I'm going to be most likely AFK for a week so hopefully others can try to help.
Most likely is the resource conflict in game. Also check if the APIC messages should be routed by extra bus or as part of FSB messages (there is some bit for that on 0xfec000smth) I think FSB routing is fine for VIA CPU too but not sure.
rest looks OK to me. Please provide the WIP patch next time so one can see how you set things up.
Thanks,
Rudolf
Hi Rudolf,
Thanks for the reply.
I agree that it seems very like a resource conflict or the irq delivery method that is wrong.
See below for detailed responses.
Jon
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: 23 July 2009 17:05 To: Harrison, Jon (SELEX GALILEO, UK) Cc: coreboot@coreboot.org Subject: Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
*** WARNING ***
This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I will leave for a holiday today. Its difficult to answer that without the patch at hand.
The ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
Means that:
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
For some reason this is wrong. You have same line in the orig bios? [Yes] If yes there is still smth wrong with APIC. Please check:
Assigned: PCI: 00:10.4 10 * [0xfebffd00 - 0xfebffdff] mem Assigned: PCI: 00:10.5 10 * [0xfebffe00 - 0xfebffeff] mem Assigned: PCI: 00:12.0 14 * [0xfebfff00 - 0xfebfffff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: fec00000 size: 300 align: 8 gran: 0 done <-- This is a reservation for the IOAPIC
This looks like the mem resources are setup from too high overlaping the IOAPIC with some hardware. No good. Move all resource bases bellow f0000000. You will need to adjust the northbridge.c and put the PCI resource limit to the address above most likely. Others can help here.
--> Don't think this is the issue IOAPIC starts at 0xfecxxxxx and is reserved --> correctly. Perhaps the allocation is unecessary / confusing though.
Also it seems that you created something in half:
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 *12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12), disabled. ACPI: PCI Interrupt Link [ATAI] (IRQs *20) ACPI: PCI Interrupt Link [USBI] (IRQs *21) ACPI: PCI Interrupt Link [VT8I] (IRQs *22) ACPI: PCI Interrupt Link [NICI] (IRQs *23)
This means you route half of IRQs through APIC and second half through the 8259. Why not route all of them through APIC. Check M2V-MX se board _PRT methods.
INTA# to IRQ16 INTB# to IRQ17 INTC# to IRQ18 INTD# to IRQ19
--> It might look that way but the they are routed to GSI 10 to 12 --> on the IOAPIC. The only rationale is that this matches what --> Award does on this board. I guess I could change this but --> not convinced that it'll make any difference.
uhci_hcd 0000:00:10.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. <<---- Whoops !!
Yes maybe but I think all USBs are routed to IRQ21 so it must be smth else. Like the resource conflict I mentioned above. If VT8237R apic is enabled (and it is) this is routed like this:
IDE (Native Mode)/SATA IRQ & INTE to IRQ20 USB IRQ (all 5 functions) and INTF to IRQ21 AC'97 / MC'97 IRQ and INTG to IRQ22 LAN IRQ and INTH to IRQ23
So I would recommend to boot now with init=/bin/bash and provide
cat /proc/iomem cat /proc/interrupts lspci -vvvxxx
--> Ok. Good idea. I guess this may reveal something.
I'm going to be most likely AFK for a week so hopefully others can try to help.
Most likely is the resource conflict in game. Also check if the APIC messages should be routed by extra bus or as part of FSB messages (there is some bit for that on 0xfec000smth) I think FSB routing is fine for VIA CPU too but not sure.
--> Yes this sound most likely to me. Reg dump from Award config says VT8237R --> uses serial bus rather than FSB. Which I've copied and makes me think that --> there is some other setup in IOAPIC or LAPIC that needs to match.
rest looks OK to me. Please provide the WIP patch next time so one can see how you set things up.
--> Will do. Didn't do it this time because the patch is pretty unwieldy at --> this time.
Thanks,
Rudolf
SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************
Ahh Haa !!
Finally, I have managed to get the IRQs through to the processor.
Proper setup for APIC Serial Bus delivery.
Now I get an smp_error_interrupt during kernel init, with a "received illegal vector" status.
I'll call this progress though.
Guessing that either in Serial Bus mode the IRQs should be disabled from boot (Current VT8237R IOAPIC init emables IRQ 0 from boot, but is in FSB mode...) until the kernel has time to sort out IRQ vectors or there is something else missing (perhaps in the MP tables to allow things to get setup properly ?)
Jon
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: 23 July 2009 17:05 To: Harrison, Jon (SELEX GALILEO, UK) Cc: coreboot@coreboot.org Subject: Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
*** WARNING ***
This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I will leave for a holiday today. Its difficult to answer that without the patch at hand.
The ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC
Means that:
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
For some reason this is wrong. You have same line in the orig bios? If yes there is still smth wrong with APIC. Please check:
Assigned: PCI: 00:10.4 10 * [0xfebffd00 - 0xfebffdff] mem Assigned: PCI: 00:10.5 10 * [0xfebffe00 - 0xfebffeff] mem Assigned: PCI: 00:12.0 14 * [0xfebfff00 - 0xfebfffff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: fec00000 size: 300 align: 8 gran: 0 done
This looks like the mem resources are setup from too high overlaping the IOAPIC with some hardware. No good. Move all resource bases bellow f0000000. You will need to adjust the northbridge.c and put the PCI resource limit to the address above most likely. Others can help here.
Also it seems that you created something in half:
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 *12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12), disabled. ACPI: PCI Interrupt Link [ATAI] (IRQs *20) ACPI: PCI Interrupt Link [USBI] (IRQs *21) ACPI: PCI Interrupt Link [VT8I] (IRQs *22) ACPI: PCI Interrupt Link [NICI] (IRQs *23)
This means you route half of IRQs through APIC and second half through the 8259. Why not route all of them through APIC. Check M2V-MX se board _PRT methods.
INTA# to IRQ16 INTB# to IRQ17 INTC# to IRQ18 INTD# to IRQ19
uhci_hcd 0000:00:10.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ. <<---- Whoops !!
Yes maybe but I think all USBs are routed to IRQ21 so it must be smth else. Like the resource conflict I mentioned above. If VT8237R apic is enabled (and it is) this is routed like this:
IDE (Native Mode)/SATA IRQ & INTE to IRQ20 USB IRQ (all 5 functions) and INTF to IRQ21 AC'97 / MC'97 IRQ and INTG to IRQ22 LAN IRQ and INTH to IRQ23
So I would recommend to boot now with init=/bin/bash and provide
cat /proc/iomem cat /proc/interrupts lspci -vvvxxx
I'm going to be most likely AFK for a week so hopefully others can try to help.
Most likely is the resource conflict in game. Also check if the APIC messages should be routed by extra bus or as part of FSB messages (there is some bit for that on 0xfec000smth) I think FSB routing is fine for VIA CPU too but not sure.
rest looks OK to me. Please provide the WIP patch next time so one can see how you set things up.
Thanks,
Rudolf
SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************
-
Harrison, Jon (SELEX GALILEO, UK) -
Rudolf Marek