On 08.02.2008 06:54, ron minnich wrote: > This patch (which is NOT signed off) adds (or tries to) PIRQ support > for the alix1c. > > it crashes and burns badly, however, I don' t know why. Marc, is > 0xf0000 set up as memory in the v3 port? I am not sure. >
I still have the suspicion that the VSA doesn't like us. Can you try latest svn (should have all your patches except the PIRQ one) and vendor BIOS and run lspci -nnvvvxxx for both under Linux? While interrupt stuff will surely not be identical, I hope we find something else to take a look at. Oh, and a possibly nice VSA stress test: run lspci -xxx in a tight loop for a few minutes. Hm. Looking again at your patch, it seems there is some unmerged stuff besides PIRQ in it. We might want to merge that as well. > It dies at a strange point: > PCI: devfn 0x9, bad id 0xffffffff > PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000(c) > PCI: devfn 0xa > pci_scan_get_dev: list is 0x00087eb8, *list is 0x0000b060 > pci_scan_get_dev: check dev southbridge > pci_scan_get_dev: check dev southbridge it has devfn 0x78 > pci_scan_get_dev: check dev superio > superio: Unknown device path type: 0 > pci_scan_get_dev: child superio() not a pci device: it's type 0 > PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) > new_device: devcnt 1 > > I can't see why it would die here. At the same time, I am not sure > that we're not losing what's in the serial FIFO. Lots of FIFO action > here. In fact, to help serial out run faster, I do this: > cat /dev/ttyS0 > instead of running minicom! > > I have seen minicom buffering almost 30-40 seconds of serial output > once I turn the alix off. Or, something is buffering it. Flow control > is OFF in minicom. > Hm. Add banner printing to crucial points in pci_scan_dev? That should help if you are fighting with a FIFO issue. > Note that if I comment out this line: > select PIRQ_TABLE > in mainboard/pcengines/Kconfig, this bios builds and runs fine. > > weird. > This is a crucial piece of information. It means we die here (unless we trigger bugs elsewhere due to alignment/memory layout/memory contents): > --- arch/x86/archtables.c (revision 578) > +++ arch/x86/archtables.c (working copy) > @@ -79,8 +79,13 @@ > post_code(POST_STAGE2_ARCH_WRITE_TABLES_ENTER); > > /* This table must be betweeen 0xf0000 & 0x100000 */ > -// rom_table_end = write_pirq_routing_table(rom_table_end); > -// rom_table_end = (rom_table_end + 1023) & ~1023; > + /* we need to make a decision: create empty functions > + * in .h files if the cpp variable is undefined, or #ifdef? > + */ > +#ifdef CONFIG_PIRQ_TABLES > Add a few banner prints here. > + rom_table_end = write_pirq_routing_table(rom_table_end); > Boom. A few more banner prints here. > + rom_table_end = (rom_table_end + 1023) & ~1023; > +#endif > > /* Write ACPI tables */ > /* write them in the rom area because DSDT can be large (8K on epia-m) > which > Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
