[LinuxBIOS] question about Config.lb

[Ben Hewson]

I have a question about Config.lb that I hope someone can help me with. 
This is in order to get ACPI working on the EPIA board.

Ok in the mainboard Config.lb as part of the southbridge there is the 
following line.

device pci 11.0 on              # Southbrdge
    :
    :
    device pnp 2e.a off end        #  ACPI

What I want to know is what exactly does "device pnp 2e.a off end        
#  ACPI" do ?

I notice that there are other device lines above this to do with com 
ports and keyboard
and they have io and irq lines as part of the device. Is this needed for 
the ACPI line ?

What exactly does the 2e.a refer to ?

further down there is also

device pci 11.4 on end        # ACPI

this I have turned to "ON" and the ACPI is now being configured.

many thanks for any help
Ben

[ron minnich]

On 5/28/07, Ben Hewson  wrote:
> device pnp 2e.a off end        #  ACPI

it's a pnp (multi-function) device
The pnp can not be probed as PCI is, so we tell Config.lb that the
base address is 2e
(PNP devices usually appear at 2e or 4e)
On base address 2e, it is device 0xa
It is not enabled -- this is a common enable setting, at byte 0x30 in
the pnp device
config space for all pnp devices.

Since it is off, there are no real parameters to program it.
End ends the block.

I will be glad when we move to dts syntax :)

Why does this enable ACPI? I wonder if this comment is a mistake. We
would have to look at the chip itself to see.
> device pci 11.4 on end        # ACPI
>
> this I have turned to "ON" and the ACPI is now being configured.

great, an ACPI-knowledgeable person will have to tell us what an ACPI
device does. My ignorance is unlimited in this area .

I am just glad OLPC does not do ACPI -- maybe OLPC will help kill ACPI
in the long run :-)

thanks

ron

[Ben Hewson]

ron minnich wrote:
> On 5/28/07, Ben Hewson  wrote:
> > device pnp 2e.a off end        #  ACPI
>
> it's a pnp (multi-function) device
> The pnp can not be probed as PCI is, so we tell Config.lb that the
> base address is 2e
> (PNP devices usually appear at 2e or 4e)
> On base address 2e, it is device 0xa
> It is not enabled -- this is a common enable setting, at byte 0x30 in
> the pnp device
> config space for all pnp devices.
>
> Since it is off, there are no real parameters to program it.
> End ends the block.
>
> I will be glad when we move to dts syntax :)
>
> Why does this enable ACPI? I wonder if this comment is a mistake. We
> would have to look at the chip itself to see.
> > device pci 11.4 on end        # ACPI
> >
> > this I have turned to "ON" and the ACPI is now being configured.
>
> great, an ACPI-knowledgeable person will have to tell us what an ACPI
> device does. My ignorance is unlimited in this area .

Don't think that is me, sort of getting the hang of it, but it is slow 
going and I haven't even started on the ASL file yet.

What is the process for adding a #define in the Config.lb/Options.lb files.

I would like to declare an ACPI_IOBASE and possibly a HW_MONITOR_IOBASE  
that get used in 2 different files.
Now I could #include a common file using a relative path but this seems 
messy to me as one file is in mainboard and the other in southbridge or 
even just hard code them.

Ideally it would be nice to include these as an option in 
Config.lb/Options.lb,
but obviously it may be of limited use. The EPIA-M mainboard could make 
use of it, not sure about the other examples though.

Oh also while it is not an error as such in 
src/southbridge/via/vt8235/vt8235_lpc.c  (EPIA-M)

there are the following 2 lines (115-116)
    // Set ACPI base address to IO 0x4000
    pci_write_config16(dev, 0x88, 0x0401);

Now I know it is probably a bit anal (pardon the language) but I hate 
comments that don't match the code. I am just as guilty of this as the 
next person, where I write an initial comment and then later change the 
code but leave the comment the same. It just makes it harder for anyone 
coming along later.
So shall I submit a patch or just forget it ?

Is I/O port 0x400-0x480 safe to use ? seems very low down address wise.
> I am just glad OLPC does not do ACPI -- maybe OLPC will help kill ACPI
> in the long run :-)
>
> thanks
>
> ron

thanks
Ben

[ron minnich]

On 5/29/07, Ben Hewson  wrote:
> there are the following 2 lines (115-116)
>     // Set ACPI base address to IO 0x4000
>     pci_write_config16(dev, 0x88, 0x0401);

so is it setting it to 401? or ...

what's the chip do? This might actually be setting it to 4000 ...

ron

[Ben Hewson]

ron minnich wrote:
> On 5/29/07, Ben Hewson  wrote:
> > there are the following 2 lines (115-116)
> > // Set ACPI base address to IO 0x4000
> > pci_write_config16(dev, 0x88, 0x0401);
>
> so is it setting it to 401? or ...
>
> what's the chip do? This might actually be setting it to 4000 ...
>
> ron

well it is strange. the code further on accesses the power management 
registers from 0x400. both the vt8231 & vt8235 set the bottom bit, don't 
ask me why, or if it is consistant with other chipsets.

from the 8235 datasheet

Offset 8B-88 – Power Management I/O Base .................RW
31-16 Reserved ........................................ always reads 0
15-7 Power Management I/O Register Base Address
Port Address for the base of the 128-byte Power
Management I/O Register block, corresponding to
AD[15:7]. See “Power Management I/O Space
Registers” in this document for definitions of the
registers in the Power Management I/O Register
Block
6-0 0000001b

if it wasn't for the code further down that uses outw() from 0x400 
onwards I wouldn't have commented on it.

anyway I will declare an extern for the base io as that is how it is 
done in at least one of the AMD based examples.