[coreboot] alix1c current state
c-d.hailfinger.devel.2006 at gmx.net
Fri Feb 8 13:45:09 CET 2008
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.
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 @@
> /* 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);
A few more banner prints here.
> + rom_table_end = (rom_table_end + 1023) & ~1023;
> /* Write ACPI tables */
> /* write them in the rom area because DSDT can be large (8K on epia-m) which
More information about the coreboot