The URL for the Cox/Weinigel thread about PIRQ tables on the geode gx1 is at: http://lkml.org/lkml/2002/7/5/104
I'm doing a little bit more analysis of the problem now. I've been looking at the following block of code from 2.6.10's pci/irq.c. First of all, LB states this during bootup: --- Checking IRQ routing tables... /bios/freebios/src/arch/i386/lib/pirq_routing.c: 30:check_pirq_routing_table() - irq_routing_table located at: 0x00008740 done. Copying IRQ routing tables to 0xf0000...done. Verifing priq routing tables copy at 0xf0000...failed Wrote linuxbios table at: 00000500 - 00000664 checksum f9fe --- I'm not sure why the copy to 0xf0000 failed. That's kinda odd but I'll live with it for now. Now, I put some debug in the kernel code to see whether it found the pirq table and I saw:
--- no pirq_table so calling pcibios_get_irq_routing_table pirq_table=00000000 ---
coming from pcibios_irq_init. So based on the code appended below, I believe that the kernel isn't finding the pirq table. And I think this is because the kernel's pirq_find_routing_table function only looks from __va(0xf0000) to __va(0x100000) whereas LB puts it at 0000500. The second attempt that the kernel makes to get the PIRQ table is with pcibios_get_irq_routing_table and that fails too. I need to look at that, but first I think I'll look into why the copy to f0000 fails. In the meantime, any advice?
--- static int __init pcibios_irq_init(void) { DBG("PCI: IRQ init\n");
if (pcibios_enable_irq || raw_pci_ops == NULL) return 0;
dmi_check_system(pciirq_dmi_table);
pirq_table = pirq_find_routing_table();
#ifdef CONFIG_PCI_BIOS if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) { printk(KERN_WARNING "no pirq_table so calling pcibios_get\n"); pirq_table = pcibios_get_irq_routing_table(); printk(KERN_WARNING "pirq_table=%p\n",pirq_table); } #endif if (pirq_table) { printk(KERN_WARNING "had pirq_table\n"); pirq_peer_trick(); pirq_find_router(&pirq_router); if (pirq_table->exclusive_irqs) { int i; for (i=0; i<16; i++) if (!(pirq_table->exclusive_irqs & (1 << i)))
pirq_penalty[i] += 100; } /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ if (io_apic_assign_pci_irqs) { printk(KERN_WARNING "using io_apic to assign irqs\n"); pirq_table = NULL; } }
pcibios_enable_irq = pirq_enable_irq;
pcibios_fixup_irqs(); return 0; } ---
--- "Ronald G. Minnich" rminnich@lanl.gov wrote:
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Strike that. The issue is somewhere with copy_pirq_routing_table. IE: why does the copy to f0000 fail. I had assumed that the 500 address was an alternate location that the table was copied to. So now, I'm looking at that f000 failure.
--- ramesh bios ramesh_bios@yahoo.com wrote:
http://www.clustermatic.org/mailman/listinfo/linuxbios
__________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/
On Tue, 1 Mar 2005, ramesh bios wrote:
the copy to f0000 fails because shadow ram is not set up.
You can fix this one of two ways. One is to figure out how to enable shadow ram. The second is to make the payload uncompressed. The copy will still fail but linux will find the PIRQ table anyway.
ron
On Tue, 1 Mar 2005, ramesh bios wrote:
!#@$!#@$!$@#!@
Can you make it so the payload is NOT compressed?
ron