iasl

iasl

[sjb]

Hi all ..

.. long story, and I shan't bother you with the details ;-)

Is there such a thing as a version of iasl that doesn't depend on glibc 
2.3 and will work with glibc 2.2? And, if so, could someone point me in 
the right direction to download a copy?

Many thanks!

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Thu, May 08, 2003 at 03:46:40PM +0000, sjb wrote:
> Hi all ..
> 
> .. long story, and I shan't bother you with the details ;-)
> 
> Is there such a thing as a version of iasl that doesn't depend on glibc 
> 2.3 and will work with glibc 2.2? And, if so, could someone point me in 
> the right direction to download a copy?
> 
> Many thanks!
> 

grab acpica-unix from intel site instead, untar, go to 'compiler' directory,
'make' and hopefully you will get iasl.

I do have trouble with bison version 1.75, but I guess that my bison
is broken ? With bison 1.31, all seems to be OK.
Plus, I got some random core dump with the latest one? 

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Ducrot Bruno wrote:

> grab acpica-unix from intel site instead, untar, go to 'compiler' directory,
> 'make' and hopefully you will get iasl.

D'oh! Why didn't I think of that?! *8-)

> I do have trouble with bison version 1.75, but I guess that my bison
> is broken ? With bison 1.31, all seems to be OK.
> Plus, I got some random core dump with the latest one? 

Well .. mine compiled cleanly and ..

ottaky@vaio:~/acpi> ./iasl -tc dsdt.asl

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030424 [May  7 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b

dsdt.asl   529:                 Field(ECR_, AnyAcc, Lock, Preserve) {
Error    1048 -                          ^ Host Operation Region 
requires ByteAcc access

dsdt.asl  1288:             Field(PIUC, DWordAcc, Lock, Preserve) {
Error    1047 -                      ^ Access width is greater than 
region size

dsdt.asl  2122:             If(\_OSI) {
Error    1028 -  Too few arguments ^  (\_OSI requires 1)

dsdt.asl  2123:                 "Windows 2001"
Error    1037 -                  parse error ^

ASL Input:  dsdt.asl - 2157 lines, 75307 bytes, 1552 keywords
Compilation complete. 4 Errors, 0 Warnings, 0 Remarks, 381 Optimizations

So, I guess the 1st error is fixable by changing "AnyAcc" for "ByteAcc". 
Not sure about no.s 2 & 3 ...and WTF is "Windows 2001" doing in there?!

Any DSDT gurus out there? This is from a Sony Vaio U1 BTW.

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Fri, May 09, 2003 at 04:17:25PM +0000, sjb wrote:
> Ducrot Bruno wrote:
> 
> >grab acpica-unix from intel site instead, untar, go to 'compiler' 
> >directory,
> >'make' and hopefully you will get iasl.
> 
> D'oh! Why didn't I think of that?! *8-)
> 
> >I do have trouble with bison version 1.75, but I guess that my bison
> >is broken ? With bison 1.31, all seems to be OK.
> >Plus, I got some random core dump with the latest one? 
> 
> Well .. mine compiled cleanly and ..
> 
> ottaky@vaio:~/acpi> ./iasl -tc dsdt.asl
> 
> Intel ACPI Component Architecture
> ASL Optimizing Compiler / AML Disassembler version 20030424 [May  7 2003]
> Copyright (C) 2000 - 2003 Intel Corporation
> Supports ACPI Specification Revision 2.0b
> 
> dsdt.asl   529:                 Field(ECR_, AnyAcc, Lock, Preserve) {
> Error    1048 -                          ^ Host Operation Region 
> requires ByteAcc access

It should be ByteAcc instead of AnyAcc

> dsdt.asl  1288:             Field(PIUC, DWordAcc, Lock, Preserve) {
> Error    1047 -                      ^ Access width is greater than 
> region size

Hard to tell.  Need the PIUC definition:

OperationRegion(PIUC, ..., ..., ...)

and all the Field(s) (with their content) which
look like 

Field(PIUC, ...) {
...
}


(but if PIUC is a OP defined as a PCI_Config, I would say that it should be
ByteAcc, or WordAcc.  I doubt that it have to be DWordAcc).

> 
> dsdt.asl  2122:             If(\_OSI) {
> Error    1028 -  Too few arguments ^  (\_OSI requires 1)
> 
> dsdt.asl  2123:                 "Windows 2001"
> Error    1037 -                  parse error ^

It should be

	If(\_OSI("Windows 2001")) {

and you may have to add:
extern (\_OSI)
(but I am not sure if it is OK with latest iasl).

BTW, could you try 'iasl -d mydsdt' in order to disassemble your DSDT, and
check if 'If (\_OSI ("Windows 2001"))' is correct ?

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Ducrot Bruno wrote:

> It should be
> 
> 	If(\_OSI("Windows 2001")) {
> 
> and you may have to add:
> extern (\_OSI)
> (but I am not sure if it is OK with latest iasl).
> 
> BTW, could you try 'iasl -d mydsdt' in order to disassemble your DSDT, and
> check if 'If (\_OSI ("Windows 2001"))' is correct ?

I did and it appears to produce better output than acpidump ...

It decompiled that "Windows 2001" line correctly as

                 If (\_OSI ("Windows 2001"))
                 {
                     Store (0x04, OSTP)
                 }

I fixed the "AnyAcc" error, and now all I see is ..

ottaky@vaio:~/acpi> ./iasl -tc dsdt.dsl

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030424 [May  7 2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b

dsdt.dsl  1902:                 Field (PIUC, DWordAcc, Lock, Preserve)
Error    1047 -                           ^ Access width is greater than 
region size

ASL Input:  dsdt.dsl - 3047 lines, 101035 bytes, 1552 keywords

The OperationRegion line reads ..

                 OperationRegion (PIUC, PCI_Config, 0x74, 0x01)

Does that provide enough info?

Thanks for helping out BTW *8-)

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: iasl

[Moore, Robert]

> dsdt.dsl  1902:                 Field (PIUC, DWordAcc, Lock, Preserve)
> Error    1047 -                           ^ Access width is greater
than
> region size
>                  OperationRegion (PIUC, PCI_Config, 0x74, 0x01)


The problem is that the region is defined as 0x01 byte, and the field
specifies a minimum access width of Dword (4 bytes).


> -----Original Message-----
> From: sjb [mailto:ottaky-XuTx12Z7TonQT0dZR+AlfA@public.gmane.org]
> Sent: Friday, May 09, 2003 10:56 AM
> To: Ducrot Bruno
> Cc: ACPI List
> Subject: Re: [ACPI] iasl
> 
> Ducrot Bruno wrote:
> 
> > It should be
> >
> > 	If(\_OSI("Windows 2001")) {
> >
> > and you may have to add:
> > extern (\_OSI)
> > (but I am not sure if it is OK with latest iasl).
> >
> > BTW, could you try 'iasl -d mydsdt' in order to disassemble your
DSDT,
> and
> > check if 'If (\_OSI ("Windows 2001"))' is correct ?
> 
> I did and it appears to produce better output than acpidump ...
> 
> It decompiled that "Windows 2001" line correctly as
> 
>                  If (\_OSI ("Windows 2001"))
>                  {
>                      Store (0x04, OSTP)
>                  }
> 
> I fixed the "AnyAcc" error, and now all I see is ..
> 
> ottaky@vaio:~/acpi> ./iasl -tc dsdt.dsl
> 
> Intel ACPI Component Architecture
> ASL Optimizing Compiler / AML Disassembler version 20030424 [May  7
2003]
> Copyright (C) 2000 - 2003 Intel Corporation
> Supports ACPI Specification Revision 2.0b
> 
> dsdt.dsl  1902:                 Field (PIUC, DWordAcc, Lock, Preserve)
> Error    1047 -                           ^ Access width is greater
than
> region size
> 
> ASL Input:  dsdt.dsl - 3047 lines, 101035 bytes, 1552 keywords
> 
> The OperationRegion line reads ..
> 
>                  OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> 
> Does that provide enough info?
> 
> Thanks for helping out BTW *8-)
> 
> sjb
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Moore, Robert wrote:

>>                 OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> 
> 
> 
> The problem is that the region is defined as 0x01 byte, and the field
> specifies a minimum access width of Dword (4 bytes).

So how would I go about fixing that? Bear in mind I have no idea how 
these things are supposed to work ;-)

Do I change the "Field" line to ByteAcc instead of DWordAcc, or the 
"OperationRegion" line somehow?

This should be the last dumb question BTW *8-)

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: iasl

[Moore, Robert]

In this case, we know that PCI_Config space is always accessed by 32-bit
reads/writes, so change the Op region definition to length 4.


> -----Original Message-----
> From: sjb [mailto:ottaky-XuTx12Z7TonQT0dZR+AlfA@public.gmane.org]
> Sent: Friday, May 09, 2003 1:51 PM
> To: Moore, Robert
> Cc: Ducrot Bruno; ACPI List
> Subject: Re: [ACPI] iasl
> 
> Moore, Robert wrote:
> 
> >>                 OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> >
> >
> >
> > The problem is that the region is defined as 0x01 byte, and the
field
> > specifies a minimum access width of Dword (4 bytes).
> 
> So how would I go about fixing that? Bear in mind I have no idea how
> these things are supposed to work ;-)
> 
> Do I change the "Field" line to ByteAcc instead of DWordAcc, or the
> "OperationRegion" line somehow?
> 
> This should be the last dumb question BTW *8-)
> 
> sjb


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Moore, Robert wrote:

> In this case, we know that PCI_Config space is always accessed by 32-bit
> reads/writes, so change the Op region definition to length 4.

OK .. so I change the 0x01 here

>>>>                OperationRegion (PIUC, PCI_Config, 0x74, 0x01)

to a 0x04 and re-compile and .. *drum roll* ..

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 380 Optimizations

Excellent!

Thanks to everybody who helped ;-)

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Fri, May 09, 2003 at 10:37:08PM +0000, sjb wrote:
> Moore, Robert wrote:
> 
> >In this case, we know that PCI_Config space is always accessed by 32-bit
> >reads/writes, so change the Op region definition to length 4.
> 
> OK .. so I change the 0x01 here
> 
> >>>>               OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> 
> to a 0x04 and re-compile and .. *drum roll* ..
> 
> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 380 Optimizations
> 
> Excellent!
> 


The _only way_ to fix *correctly* this error is to know the
definition of all Field like 

Field (PIUC, ...) 
{
...
}

But you didn't give us this info.

For example, if it is
OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
Field (REGS, DWordAcc, NoLock, Preserve)
({
	FOO, 8
})

Then a better fix is to make this:

Field (REGS, DWordAcc, NoLock, Preserve)
changed as:
Field (REGS, ByteAcc, NoLock, Preserve)

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Fri, May 09, 2003 at 01:47:39PM -0700, Moore, Robert wrote:
> 
> In this case, we know that PCI_Config space is always accessed by 32-bit
> reads/writes, so change the Op region definition to length 4.

You know nothing about that the fact that PCI_Config space have
to be accessed as 32-bit reads/write.  It may be the
Field(PIUC, DWordAcc,...) to be bogus.  A better look of this field
is needed.

Imagine it look like 
Field(PIUC, DWordAcc, ...)
{
	FOO, 16
}

then a better fix is:
OperationRegion (PIUC, PCI_Config, 0x74, 0x02)
Field(PIUC, WordAcc, ...)
{
	FOO, 16
}

Or FOO may be 8 bit long.
In that case, a possible fix is:
OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
Field(PIUC, ByteAcc, ...)
{
	FOO, 8
}


Unless sjb give us more info, we can not tell anything at this
stage.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Ducrot Bruno wrote:

> Unless sjb give us more info, we can not tell anything at this
> stage.

OK .. the dsdt is here

http://www.ottaky.com/misc/dsdt.dsl.gz

please note, this is the version I have fixed(?).

Thanks for all your help, BTW ;-)

sjb




-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Mon, May 12, 2003 at 12:24:03PM +0000, sjb wrote:
> Ducrot Bruno wrote:
> 
> >Unless sjb give us more info, we can not tell anything at this
> >stage.
> 
> OK .. the dsdt is here
> 
> http://www.ottaky.com/misc/dsdt.dsl.gz
> 

I can't believe it.. Really.

This is done like this:

                OperationRegion (PIUC, PCI_Config, 0x74, 0x04)
                Field (PIUC, DWordAcc, Lock, Preserve)
                {
                    AccessAs (ByteAcc, 0x00), 
                    PIRU,   4
                }


I assume the original one was:

                OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
                Field (PIUC, DWordAcc, Lock, Preserve)
                {
                    AccessAs (ByteAcc, 0x00), 
                    PIRU,   4
                }

Therefore, looking a little bit more, I think (not sure at 100% though)
that it is an ALi subsystem.

sjb, could you please try:

                OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
                Field (PIUC, ByteAcc, Lock, Preserve)
                {
                    PIRU,   4
                }

That make more sense for me.
It should be related to USB routing control for
this ali southbridge chipset, which
have to be accessed as byte.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Ducrot Bruno wrote:

> Therefore, looking a little bit more, I think (not sure at 100% though)
> that it is an ALi subsystem.

Yes it is .. details of the machine are at

http://www.ottaky.com/vaiou1.php

>                 OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
>                 Field (PIUC, ByteAcc, Lock, Preserve)
>                 {
>                     PIRU,   4
>                 }
> 
> That make more sense for me.
> It should be related to USB routing control for
> this ali southbridge chipset, which
> have to be accessed as byte.

I made the change and ..

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 381 Optimizations

.. it looks good.

Thanks!

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[Ducrot Bruno]

On Mon, May 12, 2003 at 02:29:58PM +0000, sjb wrote:
> Ducrot Bruno wrote:
> 
> >Therefore, looking a little bit more, I think (not sure at 100% though)
> >that it is an ALi subsystem.
> 
> Yes it is .. details of the machine are at
> 
> http://www.ottaky.com/vaiou1.php
> 
> >                OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> >                Field (PIUC, ByteAcc, Lock, Preserve)
> >                {
> >                    PIRU,   4
> >                }
> >
> >That make more sense for me.
> >It should be related to USB routing control for
> >this ali southbridge chipset, which
> >have to be accessed as byte.
> 
> I made the change and ..
> 
> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 381 Optimizations
> 
> .. it looks good.
> 

Ok.  It is a classic M1533.  Then 0x74 for this
southbridge have to be acceded as byte, not as double word (may be
different in an intel chip)


-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Ducrot Bruno wrote:

> Ok.  It is a classic M1533.  Then 0x74 for this
> southbridge have to be acceded as byte, not as double word (may be
> different in an intel chip)

I'll give it a go .. thanks.

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: iasl

[Moore, Robert]

Just as well then.  I can maintain that the AML interpreter cannot
simply "guess" at which is wrong -- the length of the operation region,
or the access width of the field definition.

Bob


> -----Original Message-----
> From: Ducrot Bruno [mailto:ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org]
> Sent: Monday, May 12, 2003 3:17 AM
> To: Moore, Robert
> Cc: sjb; Ducrot Bruno; ACPI List
> Subject: Re: [ACPI] iasl
> 
> On Fri, May 09, 2003 at 01:47:39PM -0700, Moore, Robert wrote:
> >
> > In this case, we know that PCI_Config space is always accessed by
32-bit
> > reads/writes, so change the Op region definition to length 4.
> 
> You know nothing about that the fact that PCI_Config space have
> to be accessed as 32-bit reads/write.  It may be the
> Field(PIUC, DWordAcc,...) to be bogus.  A better look of this field
> is needed.
> 
> Imagine it look like
> Field(PIUC, DWordAcc, ...)
> {
> 	FOO, 16
> }
> 
> then a better fix is:
> OperationRegion (PIUC, PCI_Config, 0x74, 0x02)
> Field(PIUC, WordAcc, ...)
> {
> 	FOO, 16
> }
> 
> Or FOO may be 8 bit long.
> In that case, a possible fix is:
> OperationRegion (PIUC, PCI_Config, 0x74, 0x01)
> Field(PIUC, ByteAcc, ...)
> {
> 	FOO, 8
> }
> 
> 
> Unless sjb give us more info, we can not tell anything at this
> stage.
> 
> --
> Ducrot Bruno
> 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: iasl

[Yu, Luming]

Could you please describe the symptom that you are trying to fix.

Thanks,
Luming
-----Original Message-----
From: sjb [mailto:ottaky-XuTx12Z7TonQT0dZR+AlfA@public.gmane.org]
Sent: 2003?5?12? 23:05
To: ACPI List
Subject: Re: [ACPI] iasl


Ducrot Bruno wrote:

> Ok.  It is a classic M1533.  Then 0x74 for this
> southbridge have to be acceded as byte, not as double word (may be
> different in an intel chip)

I'll give it a go .. thanks.

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: iasl

[sjb]

Yu, Luming wrote:

> Could you please describe the symptom that you are trying to fix.

I'm not trying to fix anything - I'm intending to upgrade the U1 in the 
near future (to SuSE 8.2) and I want to make sure I have everything I 
need to make sure the ACPI is working properly.

sjb



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com