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

[LinuxBIOS]

#70: fix util/getpir so that the output will compile
-----------------------------------------------------+----------------------
   Reporter:  Jon Dufresne   |          Owner:  somebody
       Type:  defect                                 |         Status:  new     
   Priority:  major                                  |      Milestone:          
  Component:  code                                   |        Version:  v2      
   Keywords:                                         |   Dependencies:          
Patchstatus:  there is no patch                      |  
-----------------------------------------------------+----------------------
 The file "irq_table.c" created by getpir needs an additional funciton in
 order to compile in a project. I patched getpir so this is taken care of
 automatically. I used a few different boars as an example

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

[ron minnich]

I'm not totally sure about this one. What we have done for a number of
reasons is let each board define this function. I think it's for the
usual reason -- some wacko board that breaks all the rules -- Jon, are
you sure this works in ALL cases -- that every single board can use
this standard function definition?

thanks

ron

On 12/19/06, LinuxBIOS  wrote:
> #70: fix util/getpir so that the output will compile
> -----------------------------------------------------+----------------------
>    Reporter:  Jon Dufresne   |          Owner:  somebody
>        Type:  defect                                 |         Status:  new
>    Priority:  major                                  |      Milestone:
>   Component:  code                                   |        Version:  v2
>    Keywords:                                         |   Dependencies:
> Patchstatus:  there is no patch                      |
> -----------------------------------------------------+----------------------
>  The file "irq_table.c" created by getpir needs an additional funciton in
>  order to compile in a project. I patched getpir so this is taken care of
>  automatically. I used a few different boars as an example

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

[Jon Dufresne]

Well doing a simple grep tells me that this function isn't universal,
however the majority of them define the function the way I did, which
is why I defined it that way. So no this is not universal.

I guess it is your call. If you want the standard function defined for
the developer and then if he/she wants can change it, or if you'd
prefer it not be defined at all. I don't see a strong argument either
way.

Jon

On 12/19/06, ron minnich  wrote:
> I'm not totally sure about this one. What we have done for a number of
> reasons is let each board define this function. I think it's for the
> usual reason -- some wacko board that breaks all the rules -- Jon, are
> you sure this works in ALL cases -- that every single board can use
> this standard function definition?
>
> thanks
>
> ron
>
> On 12/19/06, LinuxBIOS  wrote:
> > #70: fix util/getpir so that the output will compile
> > -----------------------------------------------------+----------------------
> >    Reporter:  Jon Dufresne   |          Owner:  somebody
> >        Type:  defect                                 |         Status:  new
> >    Priority:  major                                  |      Milestone:
> >   Component:  code                                   |        Version:  v2
> >    Keywords:                                         |   Dependencies:
> > Patchstatus:  there is no patch                      |
> > -----------------------------------------------------+----------------------
> >  The file "irq_table.c" created by getpir needs an additional funciton in
> >  order to compile in a project. I patched getpir so this is taken care of
> >  automatically. I used a few different boars as an example

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

[Stefan Reinauer]

* ron minnich  [061219 19:34]:
> I'm not totally sure about this one. What we have done for a number of
> reasons is let each board define this function. I think it's for the
> usual reason -- some wacko board that breaks all the rules -- Jon, are
> you sure this works in ALL cases -- that every single board can use
> this standard function definition?

It doesn't really matter. The PIRQ table you read out on any modern
board that comes with ACPI will not be complete, correct or working
anyways.

Stefan

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

[Jon Dufresne]

In that case this utility program is very misleading, at least to me.
Perhaps a large comment should be added to the .c file that either
gives a warning that it is incomplete or tips on what to add.

Jon

On 12/19/06, Stefan Reinauer  wrote:
> ron minnich  [061219 19:34]:
> > I'm not totally sure about this one. What we have done for a number of
> > reasons is let each board define this function. I think it's for the
> > usual reason -- some wacko board that breaks all the rules -- Jon, are
> > you sure this works in ALL cases -- that every single board can use
> > this standard function definition?
>
> It doesn't really matter. The PIRQ table you read out on any modern
> board that comes with ACPI will not be complete, correct or working
> anyways.
>
> Stefan

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

[Li-Ta Lo]

On Tue, 2006-12-19 at 17:17 -0500, Jon Dufresne wrote:
> In that case this utility program is very misleading, at least to me.
> Perhaps a large comment should be added to the .c file that either
> gives a warning that it is incomplete or tips on what to add.

There is no way for the utility to know if it is generating something
useful. There is zero intelligence in the utility and it just dumps
whatever it is in the memory in a human and compiler readable form.
This is a totally use at your own risk thing.

Ollie

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

[Tom Sylla]

Hm.

Why is that not in the README then? Maybe it is somehow clear to all
you LBers, but for someone new, the documentation is *extremely*
misleading. The tool itself says:

printf("Done, you can move the file to the LinuxBios tree now.\n");

That implies that it will just work. The resulting source also
admonishes the user:

"/* This file was generated by getpir.c, do not modify! \n   (but if
you do, please run checkpir on it to verify)\n",

which even implies more that it should "just work".

If the few sentences you wrote, and those of Stefan were in the
README, much less confusion would exist.

On 12/19/06, Li-Ta Lo  wrote:
> On Tue, 2006-12-19 at 17:17 -0500, Jon Dufresne wrote:
> > In that case this utility program is very misleading, at least to me.
> > Perhaps a large comment should be added to the .c file that either
> > gives a warning that it is incomplete or tips on what to add.
>
> There is no way for the utility to know if it is generating something
> useful. There is zero intelligence in the utility and it just dumps
> whatever it is in the memory in a human and compiler readable form.
> This is a totally use at your own risk thing.
>
> Ollie

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

[Peter Stuge]

On Tue, Dec 19, 2006 at 05:55:42PM -0500, Tom Sylla wrote:
> Maybe it is somehow clear to all you LBers

It may not be documented clearly because it is just one of so many
things that make factory BIOSes suck.

//Peter

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

[Uwe Hermann]

On Tue, Dec 19, 2006 at 05:55:42PM -0500, Tom Sylla wrote:
> If the few sentences you wrote, and those of Stefan were in the
> README, much less confusion would exist.

Ack. Patches welcome :)

Uwe.

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

[Corey Osgood]

Li-Ta Lo wrote:
> On Tue, 2006-12-19 at 17:17 -0500, Jon Dufresne wrote:
> > In that case this utility program is very misleading, at least to me.
> > Perhaps a large comment should be added to the .c file that either
> > gives a warning that it is incomplete or tips on what to add.
>
> There is no way for the utility to know if it is generating something
> useful. There is zero intelligence in the utility and it just dumps
> whatever it is in the memory in a human and compiler readable form.
> This is a totally use at your own risk thing.
>
> Ollie

So, how exactly do you know if it works or not, just try it? And if it
fails, how do you make it "just work", is there some method for figuring
out where it goes wrong? And finally, would disabling ACPI from the
factory BIOS (if there is such an option) help this?

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)? I've given
up on that particular board, because slot a cpus are so rare these days,
but the tyan s2507 (my next target) uses a chip with the same PCI ID.
I'll test the script on that once I get done recompiling the entire
system (god bless gentoo).

-Corey

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

[Jon Dufresne]

I have also noticed that the irq_tables.c that getpir gave me gives me
the wrong checksum. I don't know if this is an error in the pir of the
factory bios or the getpir. I'll have to look into this more. Just
another example of irq_tables.c not being right.

Jon

On 12/19/06, Corey Osgood  wrote:
> Li-Ta Lo wrote:
> > On Tue, 2006-12-19 at 17:17 -0500, Jon Dufresne wrote:
> > > In that case this utility program is very misleading, at least to me.
> > > Perhaps a large comment should be added to the .c file that either
> > > gives a warning that it is incomplete or tips on what to add.
> >
> > There is no way for the utility to know if it is generating something
> > useful. There is zero intelligence in the utility and it just dumps
> > whatever it is in the memory in a human and compiler readable form.
> > This is a totally use at your own risk thing.
> >
> > Ollie
>
> So, how exactly do you know if it works or not, just try it? And if it
> fails, how do you make it "just work", is there some method for figuring
> out where it goes wrong? And finally, would disabling ACPI from the
> factory BIOS (if there is such an option) help this?
>
> 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)? I've given
> up on that particular board, because slot a cpus are so rare these days,
> but the tyan s2507 (my next target) uses a chip with the same PCI ID.
> I'll test the script on that once I get done recompiling the entire
> system (god bless gentoo).
>
> -Corey

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

[Stefan Reinauer]

* Jon Dufresne  [061220 03:44]:
> I have also noticed that the irq_tables.c that getpir gave me gives me
> the wrong checksum. I don't know if this is an error in the pir of the
> factory bios or the getpir. I'll have to look into this more. Just
> another example of irq_tables.c not being right.

How did you know it is wrong?

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

[Stefan Reinauer]

* Corey Osgood  [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

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

[Jon Dufresne]

When you run getpir a message is printed that says "Checksum is ok!" I
don't get this message. Just in case I wasn't seeing it for some
reason I modified getpir to print "Checksum is bad!" in the opposite
case. I see this message when I run it. Also everytime I run LinuxBIOS
it tells me the pirq checksum is bad and tells me what the right one
is. If I change it at LB's requrest I no longer get the error durring
boot.

Jon

On 12/20/06, Stefan Reinauer  wrote:
> Jon Dufresne  [061220 03:44]:
> > I have also noticed that the irq_tables.c that getpir gave me gives me
> > the wrong checksum. I don't know if this is an error in the pir of the
> > factory bios or the getpir. I'll have to look into this more. Just
> > another example of irq_tables.c not being right.
>
> How did you know it is wrong?

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

[Corey Osgood]

Stefan Reinauer wrote:
> 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

Will do, thanks for the info (especially the reference).
> > I've given
> > up on that particular board, because slot a cpus are so rare these days,
>
> Did you get RAM stable?

I never even got the southbridge working correctly, I could only get
serial output after a soft reboot from the original bios. I suspect it
might have been that I needed special cpu init for the k7, which is
present in v1, but it isn't worth implementing in v2 just for this
motherboard. AMD (as I'm sure some of you know) supplies docs for the k6
and k8 on cpu init, but doesn't for the k7, making things very
difficult. The northbridge is the amd 751, which amd has also all but
destroyed the docs on, so I decided it was time to find another toy, and
a dual p3 is definitely a better toy :D

-Corey

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

[Al Boldi]

Corey Osgood wrote:
> > Did you get RAM stable?
>
> I never even got the southbridge working correctly, I could only get
> serial output after a soft reboot from the original bios. I suspect it
> might have been that I needed special cpu init for the k7, which is
> present in v1, but it isn't worth implementing in v2 just for this
> motherboard.

Why is it not possible to translate v1 inits to v2?

Thanks!

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

[Segher Boessenkool]

> AMD (as I'm sure some of you know) supplies docs for the k6
> and k8 on cpu init, but doesn't for the k7, making things very
> difficult.

#21656, but only available under NDA I think?
> The northbridge is the amd 751, which amd has also all but
> destroyed the docs on

#21910, on AMD's public website just fine, perhaps not
too easy to find, but it's there (look in the "historical"
section).

Segher

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

[LinuxBIOS]

#70: fix util/getpir so that the output will compile
------------------------------------------------------+---------------------
    Reporter:  Jon Dufresne   |         Owner:  somebody        
        Type:  defect                                 |        Status:  new             
    Priority:  major                                  |     Milestone:                  
   Component:  code                                   |       Version:  v2              
  Resolution:                                         |      Keywords:                  
Dependencies:                                         |   Patchstatus:  patch needs work
------------------------------------------------------+---------------------
Changes (by uwe):

* patchstatus:  there is no patch => patch needs work

Comment:

Please re-post the patch (in Trac, or maybe better on the mailing list)
 with your sign-off. See http://linuxbios.org/Development_Guidelines#Sign-
 off_Procedure for details.