[LinuxBIOS] #70: fix util/getpir so that the output will compile

Stefan Reinauer stepan at coresystems.de
Wed Dec 20 12:12:18 CET 2006


* Corey Osgood <corey_osgood at verizon.net> [061220 03:40]:
> So, how exactly do you know if it works or not, just try it? 

yes. there is no other way.

> And if it fails, how do you make it "just work", is there some method
> for figuring out where it goes wrong? 

I have seen one machine where the PIRQ created was for a
_completely_ different machine. On others, the factory bios just fails
to create a _working_ version. After ACPI became state of the art, the
information is just not reliable anymore. It might just work and you're
lucky. Or it might just not. In that case the error might go from typo
in routing information all the way to totally bogus data with a pirq
header.

> And finally, would disabling ACPI from the factory BIOS (if there is
> such an option) help this?
 
It might. I have no idea about their code paths. If you can still use
the box with acpi=off, it's a first indicator for pirq correctness.

The safest way is still implementing a simple ACPI DSDT. Have a look at
LinuxBIOSv2/src/mainboard/via/epia-m/dsdt.asl for  a sample of doing IRQ
routing in ACPI. Its not more complex than mptable+pirq

> Also, hate to hijack this, but I just noticed something from my work on
> the FIC SD11, in my irq_tables.c (generated by get_pir.c), it set the
> device ID of the southbridge (via vt686a) to 0x586, when it should have
> been 0x0686, according to everything I know about this board (manuals,
> lspci, etc). Is there some known bug in get_pir.c that could have caused
> this (perhaps when dealing with a PCI ID beginning with 0)?

No, this is weird and looks like an error when in fact it is not.

get_pir.c does not do anything with the information. It just dumps what
it finds. So if it says 0x586 then that is what the factory bios vendor 
chose to put in there.

And actually not without a reason: If you look at the pirq parsing and
interrupt init code in Linux, you see that it only knows a very limited
number of interrupt controllers. 

Linux takes the information from the pirq table and hammers it into the
interrupt controller. To make that work, it has to know the register
layout of that interrupt controller.

So when you read 0x586 as the device id, you can assume that the real
meaning of that value is: make the OS use the vt586 register layout of
the interrupt controller. In fact, the vt686 is compatible to the vt586 
in that regard, so the value is fine. So, instead of just numbering the
methods 0...x they chose pseudo device ids to identify the different
init methods.

> I've given
> up on that particular board, because slot a cpus are so rare these days,

Did you get RAM stable? 


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/




More information about the coreboot mailing list