[coreboot] alix1c current state

[Carl-Daniel Hailfinger]

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