Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
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.ma...@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 - 0xfebf] mem PCI_DOMAIN: allocate_resources_mem: next_base: fec0 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 f000. 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 0xfecx 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 :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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpoijwACgkQ3J9wPJqZRNUqUACgqTxXlnbgyQa2jrFkwrECogh8 iKAAn2TtACws0090J7KhBbC3fSE1Nprc =eOhh -END PGP SIGNATURE- 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.
[coreboot] #145: Fix CMOS handling
#145: Fix CMOS handling -+-- Reporter: oxygene| Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: coreboot |Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | -+-- CMOS handling isn't very good at this time. Example: The fallback image uses hardcoded values for serial port configuration, normal image uses CMOS values. If normal is booted, and the CMOS values are invalid, serial is dead, and the boot might misbehave as the wrong IO port is used. Alternative: Compile a defaults table for CMOS values, and use that if the checksum of the CMOS data is wrong (and maybe even unconditionally in fallback) But, do not overwrite CMOS with that table, as the data in there should probably stay (eg. when switching between vendor BIOS and coreboot in testing scenarios). Just use that table as an alternative data source. This could also eliminate a couple of #ifs, if the non-CMOS variant of code just uses the default table. Marked as defect, as the broken serial console actually happened several times, and confused people. The proposed solution is an enhancement, but nevermind... -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/145 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
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.ma...@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 - 0xfebf] mem PCI_DOMAIN: allocate_resources_mem: next_base: fec0 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 f000. 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 :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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpoijwACgkQ3J9wPJqZRNUqUACgqTxXlnbgyQa2jrFkwrECogh8 iKAAn2TtACws0090J7KhBbC3fSE1Nprc =eOhh -END PGP SIGNATURE- 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
Sooo. I've added MPtables and masked IRQ0 from boot but still get APIC error on CPU0: 40(40) Which seems to mean illegal vector recieved Any suggestions on how to track down what the interrupt source is of the illegal vector ? Is there a kernel command line option that will turn on more verbose APIC output ? Thanks, Jon -- Message: 5 Date: Fri, 24 Jul 2009 10:04:29 +0100 From: Harrison, Jon (SELEX GALILEO, UK) jon.harri...@selexgalileo.com To: Rudolf Marek r.ma...@assembler.cz Cc: coreboot@coreboot.org Subject: Re: [coreboot] IOAPIC Initialisation - How much do you have to do ?? Message-ID: 8e520a5e7fb8d647bfda039f6031c1c6059d5...@desmdswms201.des.grplnk.net Content-Type: text/plain; charset=us-ascii 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 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IOAPIC Initialisation - How much do you have to do ??
Harrison, Jon (SELEX GALILEO, UK) napsal(a): Sooo. I've added MPtables and masked IRQ0 from boot but still get APIC error on CPU0: 40(40) Hi, seems like I'm bit online ;) Check if bit 7 on 48h 7 APIC FSB Fixed at Low DW It changes how the APIC is delivered. Also if external bus is used, you will need to check the pin multiplexer/multifunction is setup correctly. Is there a kernel command line option that will turn on more verbose APIC output ? Yes but not help apic=debug maybe Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] solved - Re: fam10/h8dmr: extreme slowness in CBFS memset /memcpy
On Tue, Jul 21, 2009 at 08:23:22AM -0600, Myles Watson wrote: It's actually just a plain byte-by-byte assignment in c, see src/lib/memset.c. It would be interesting to see if you make it 4 bytes at a time if it is 4x faster. We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? Hmm, we tried adding it here src/cpu/amd/car/clear_init_ram.c in function set_init_ram_access, which already sets an mtrr. I always wondered about that one. The thing that makes it hard to debug is that it will read back correctly even if it hasn't taken effect. Thanks - will see if I can try some of these things. Good luck, So - you're not going to believe this. Compiler issue. I was compiling with gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 on 32 bit. I noticed that about one in every 10 burn/boot cycles or so, the slowness would not be there. So I switched back to gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-8ubuntu2) on 32 bit, and it's gone altogether, every time. Is anyone else using gcc 4.3 (32 bit) to compile coreboot? Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
