Strange interpreter behaviour

Strange interpreter behaviour

[Janosch Machowinski]

Hey,
I got an ASUS M6, which contains some strange _CST related ASL code.
In the _CST method there is a check, if \_SB.INV7 is set :
                 If (\_SB.INV7)
                 {
                     Return (NOC3)
                 }
This seems to always return true. There is also the method \_GPE:_L17 
which just inverts \_SB.INV7 and sends a signal to refetch the CST Object :
           Method (_L17, 0, NotSerialized)
         {
             If (\_SB.INV7)
             {
                 Store (0x00, \_SB.INV7)
             }
             Else
             {
                 Store (0x01, \_SB.INV7)
             }

             Notify (\_PR.CPU1, 0x81)
         }

Now I called the _L17 method manually :
echo "0:\\_GPE:_L17:\\_GPE:_L17:10001:1" > /proc/acpi/hotkey/poll_config
echo "10001:0:1:0" > /proc/acpi/hotkey/action

What I noticed is that every time I call the action, my C-State usage 
counter gets reset to zero. From that behaviour I would follow, that the 
L17 method was executed and the CST Object was refetched. So there seems 
to be an error in setting the \_SB.INV7 bit/register/whatever. (I assume 
0 is false an 1 is true in ASL if-clauses ?)
Greets
    Janosch
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Strange interpreter behaviour

[Yu, Luming]

>I got an ASUS M6, which contains some strange _CST related ASL code.
>In the _CST method there is a check, if \_SB.INV7 is set :
>                 If (\_SB.INV7)
>                 {
>                     Return (NOC3)
>                 }
>This seems to always return true. There is also the method \_GPE:_L17 
>which just inverts \_SB.INV7 and sends a signal to refetch the 
>CST Object :
>           Method (_L17, 0, NotSerialized)
>         {
>             If (\_SB.INV7)
>             {
>                 Store (0x00, \_SB.INV7)
>             }
>             Else
>             {
>                 Store (0x01, \_SB.INV7)
>             }
>
>             Notify (\_PR.CPU1, 0x81)
>         }
>
>Now I called the _L17 method manually :
>echo "0:\\_GPE:_L17:\\_GPE:_L17:10001:1" > 
>/proc/acpi/hotkey/poll_config
>echo "10001:0:1:0" > /proc/acpi/hotkey/action
>
>What I noticed is that every time I call the action, my C-State usage 
>counter gets reset to zero. From that behaviour I would 

Please show  /proc/acpi/processor/power .

>follow, that the 
>L17 method was executed and the CST Object was refetched. 
>there seems 
>to be an error in setting the \_SB.INV7 bit/register/whatever. 
>(I assume 
>0 is false an 1 is true in ASL if-clauses ?)

Don't understand what is wrong.
Please clearly point it out.

Thanks,
Luming

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Janosch Machowinski]

Yu, Luming wrote:
>>I got an ASUS M6, which contains some strange _CST related ASL code.
>>In the _CST method there is a check, if \_SB.INV7 is set :
>>                If (\_SB.INV7)
>>                {
>>                    Return (NOC3)
>>                }
>>This seems to always return true. There is also the method \_GPE:_L17 
>>which just inverts \_SB.INV7 and sends a signal to refetch the 
>>CST Object :
>>          Method (_L17, 0, NotSerialized)
>>        {
>>            If (\_SB.INV7)
>>            {
>>                Store (0x00, \_SB.INV7)
>>            }
>>            Else
>>            {
>>                Store (0x01, \_SB.INV7)
>>            }
>>
>>            Notify (\_PR.CPU1, 0x81)
>>        }
>>
>>Now I called the _L17 method manually :
>>echo "0:\\_GPE:_L17:\\_GPE:_L17:10001:1" > 
>>/proc/acpi/hotkey/poll_config
>>echo "10001:0:1:0" > /proc/acpi/hotkey/action
>>
>>What I noticed is that every time I call the action, my C-State usage 
>>counter gets reset to zero. From that behaviour I would 
> 
> 
> Please show  /proc/acpi/processor/power .
>
Before executing \_GPE:_L17 :

active state:            C2
max_cstate:              C8
bus master activity:     00000000
states:
     C1:                  type[C1] promotion[C2] demotion[--] 
latency[000] usage[00000010]
    *C2:                  type[C2] promotion[--] demotion[C1] 
latency[001] usage[00037580]

After executing
active state:            C2
max_cstate:              C8
bus master activity:     00000000
states:
     C1:                  type[C1] promotion[C2] demotion[--] 
latency[000] usage[00000010]
    *C2:                  type[C2] promotion[--] demotion[C1] 
latency[001] usage[00000430]


> 
>>follow, that the 
>>L17 method was executed and the CST Object was refetched. 
>>there seems 
>>to be an error in setting the \_SB.INV7 bit/register/whatever. 
>>(I assume 
>>0 is false an 1 is true in ASL if-clauses ?)
> 
> 
> Don't understand what is wrong.
> Please clearly point it out.

Sorry, seems I missed the main plot ;-)
In case \_SB.INV7 is 0, the _CST method returns a CST object with a C3 
and C4 State. If it is 1 I only get the "NOC3" (see above) CST object.
I can call the _L17 method as often as I want and it seems I allways get 
a clean fresh CST with only C1 and C2. That's why I assume that 
something with setting the \_SB.INV7 register is not right. I mentioned 
this a while ago in a bug : http://bugzilla.kernel.org/show_bug.cgi?id=4485
Greets
    Janosch
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Strange interpreter behaviour

[Yu, Luming]

>
>Sorry, seems I missed the main plot ;-)
>In case \_SB.INV7 is 0, the _CST method returns a CST object with a C3 
>and C4 State. If it is 1 I only get the "NOC3" (see above) CST object.
>I can call the _L17 method as often as I want and it seems I 
>allways get 
>a clean fresh CST with only C1 and C2. That's why I assume that 
>something with setting the \_SB.INV7 register is not right. I 
>mentioned 
>this a while ago in a bug : 
>http://bugzilla.kernel.org/show_bug.cgi?id=4485

Not sure, but I think you need to do further investigation.
Are you sure _CST always exits with Return (NOC3).

ACST contains C3 state?


                If (\_SB.INV7) 
                { 
                    Return (NOC3) 
                } 
 
                If (\_SB.BATO) 
                { 
                    Return (BCST) 
                } 
                Else 
                { 
                    Return (ACST) 
                } 
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Bruno Ducrot]

On Sat, Jan 07, 2006 at 06:18:22PM +0100, Janosch Machowinski wrote:
> Hey,
> I got an ASUS M6, which contains some strange _CST related ASL code.
> In the _CST method there is a check, if \_SB.INV7 is set :
>                 If (\_SB.INV7)
>                 {
>                     Return (NOC3)
>                 }
> This seems to always return true. There is also the method \_GPE:_L17 
> which just inverts \_SB.INV7 and sends a signal to refetch the CST Object :
>           Method (_L17, 0, NotSerialized)
>         {
>             If (\_SB.INV7)
>             {
>                 Store (0x00, \_SB.INV7)
>             }
>             Else
>             {
>                 Store (0x01, \_SB.INV7)
>             }
> 
>             Notify (\_PR.CPU1, 0x81)
>         }
> 
> Now I called the _L17 method manually :
> echo "0:\\_GPE:_L17:\\_GPE:_L17:10001:1" > /proc/acpi/hotkey/poll_config
> echo "10001:0:1:0" > /proc/acpi/hotkey/action
> 
> What I noticed is that every time I call the action, my C-State usage 
> counter gets reset to zero. From that behaviour I would follow, that the 
> L17 method was executed and the CST Object was refetched. So there seems 
> to be an error in setting the \_SB.INV7 bit/register/whatever. (I assume 
> 0 is false an 1 is true in ASL if-clauses ?)

Sound like \_SB.INV7 is a bit into a GPIO.
More, the associated OR is defined like that:
	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 

Note that IO2B is given here:
    OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
    Field (BIOS, ByteAcc, NoLock, Preserve)
    {
        SS1,    1,
        SS2,    1,
        SS3,    1,
        SS4,    1,
        Offset (0x01),
        IOST,   16,
        SPIO,   16,
        PMBS,   16,
        PMLN,   8,
        SMBS,   16,
        SMLN,   8,
        IO1B,   16,
        IO1L,   8,
        IO2B,   16,
        IO2L,   8,
        TOPM,   32,
        ROMS,   32,

Therefore one think to check is that IO2B is set correctly to point to
the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).

For checking if IO2B is correct:
sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump

./acpixtract FACP < acpidump.out | ./acpitbl

where acpidump.txt is the output from ./acpidump.  I assume you know
what I'm talking about reading the bugzilla report, or else do something
like that:

wget ftp://ftp.kernel.org//pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2
tar xjvfp pmtools-20050926.tar.bz2
cd pmtools
make
cd acpidump
sudo ./acpidmp > acpidmp.out

I think the value given by the 'sudo dd' above should correspond to the
GPE0_BLK: field from the ./acpitbl above.

For checking if the register where the INV7 is defined is configured as
a GPO, well I have to know the ouput from 'lspci -v -xxx -s"the southbridge"'

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Janosch Machowinski]

Yu, Luming wrote:
>>Sorry, seems I missed the main plot ;-)
>>In case \_SB.INV7 is 0, the _CST method returns a CST object with a C3 
>>and C4 State. If it is 1 I only get the "NOC3" (see above) CST object.
>>I can call the _L17 method as often as I want and it seems I 
>>allways get 
>>a clean fresh CST with only C1 and C2. That's why I assume that 
>>something with setting the \_SB.INV7 register is not right. I 
>>mentioned 
>>this a while ago in a bug : 
>>http://bugzilla.kernel.org/show_bug.cgi?id=4485
> 
> 
> Not sure, but I think you need to do further investigation.
> Are you sure _CST always exits with Return (NOC3).
> 
> ACST contains C3 state?
> 
Yep, ACST and BCST definitely contain one or more C3 states :
                 Name (ACST, Package (0x03)
                 {
                     0x02,
                     Package (0x04)
                     {
                         ResourceTemplate ()
                         {
                             Register (SystemIO, 0x08, 0x00, 
0x00000000000005FF)
                         },

                         0x02,
                         0x01,
                         0x03E8
                     },

                     Package (0x04)
                     {
                         ResourceTemplate ()
                         {
                             Register (SystemIO, 0x08, 0x00, 
0x0000000000000415)
                         },

                         0x03,
                         0x01,
                         0x01F4
                     }
                 })


                  Name (BCST, Package (0x04)
                 {
                     0x03,
                     Package (0x04)
                     {
                         ResourceTemplate ()
                         {
                             Register (SystemIO, 0x08, 0x00, 
0x00000000000005FF)
                         },

                         0x02,
                         0x01,
                         0x03E8
                     },

                     Package (0x04)
                     {
                         ResourceTemplate ()
                         {
                             Register (SystemIO, 0x08, 0x00, 
0x0000000000000415)
                         },

                         0x03,
                         0x01,
                         0x01F4
                     },

                     Package (0x04)
                     {
                         ResourceTemplate ()
                         {
                             Register (SystemIO, 0x08, 0x00, 
0x0000000000000416)
                         },

                         0x04,
                         0x02,
                         0xFA
                     }
                 })

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Janosch Machowinski]

> Sound like \_SB.INV7 is a bit into a GPIO.
> More, the associated OR is defined like that:
> 	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 
> 
> Note that IO2B is given here:
>     OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
>     Field (BIOS, ByteAcc, NoLock, Preserve)
>     {
>         SS1,    1,
>         SS2,    1,
>         SS3,    1,
>         SS4,    1,
>         Offset (0x01),
>         IOST,   16,
>         SPIO,   16,
>         PMBS,   16,
>         PMLN,   8,
>         SMBS,   16,
>         SMLN,   8,
>         IO1B,   16,
>         IO1L,   8,
>         IO2B,   16,
>         IO2L,   8,
>         TOPM,   32,
>         ROMS,   32,
> 
> Therefore one think to check is that IO2B is set correctly to point to
> the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).
> 
> For checking if IO2B is correct:
> sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump
> 
Here it get's strange :
scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
dd: reading `/dev/mem': Bad address
0+0 records in
0+0 records out


> ./acpixtract FACP < acpidump.out | ./acpitbl
> 
> where acpidump.txt is the output from ./acpidump.  I assume you know
> what I'm talking about reading the bugzilla report, or else do something
> like that:
> 
> wget ftp://ftp.kernel.org//pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2
> tar xjvfp pmtools-20050926.tar.bz2
> cd pmtools
> make
> cd acpidump
> sudo ./acpidmp > acpidmp.out
> 
> I think the value given by the 'sudo dd' above should correspond to the
> GPE0_BLK: field from the ./acpitbl above.
> 
> For checking if the register where the INV7 is defined is configured as
> a GPO, well I have to know the ouput from 'lspci -v -xxx -s"the southbridge"'
> 
Uhm as far as I know "the southbridge" is is the Intel 82801. There are 
more than one 82801 devices, so I just post all except the USB devices, 
sorry for that :

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) 
(prog-if 00 [Normal decode])
         Flags: bus master, fast devsel, latency 0
         Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
         I/O behind bridge: 00001000-00001fff
         Memory behind bridge: ff900000-ff9fffff
         Prefetchable memory behind bridge: dea00000-deafffff
00: 86 80 48 24 07 01 80 80 83 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 40 10 10 80 02
20: 90 ff 90 ff a0 de a0 de 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00
40: 02 28 20 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 10 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 01 00 02 00 00 00 c0 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 2c 48

00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface 
Bridge (rev 03)
         Flags: bus master, medium devsel, latency 0
00: 86 80 cc 24 0f 01 80 02 03 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 01 05 00 00 10 00 00 00
60: 0b 04 0a 05 90 00 00 00 80 80 80 0a 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 28 03 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 80 02 02 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 02 28 00 00 02 cf 00 00 04 00 00 00 00 00 00 00
e0: 12 00 00 c0 00 00 06 34 33 22 11 00 00 00 67 45
f0: 00 00 01 00 00 00 00 00 60 0f 03 00 00 00 80 02

00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE 
Controller (rev 03) (prog-if 8a [Master SecP PriP])
         Subsystem: ASUSTeK Computer Inc. Unknown device 1869
         Flags: bus master, medium devsel, latency 0, IRQ 10
         I/O ports at <unassigned>
         I/O ports at <unassigned>
         I/O ports at <unassigned>
         I/O ports at <unassigned>
         I/O ports at ffa0 [size=16]
         Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
00: 86 80 ca 24 07 00 80 02 03 8a 01 01 00 00 00 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
20: a1 ff 00 00 00 00 00 30 00 00 00 00 43 10 69 18
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
40: 07 e3 07 e3 00 00 00 00 05 00 01 02 00 00 00 00
50: 00 00 00 00 31 14 00 00 00 00 00 00 00 00 00 00
60: 08 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 00 00

00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
SMBus Controller (rev 03)
         Subsystem: ASUSTeK Computer Inc. Unknown device 1869
         Flags: medium devsel
         I/O ports at 0540 [size=32]
00: 86 80 c3 24 01 00 80 02 03 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 05 00 00 00 00 00 00 00 00 00 00 43 10 69 18
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
40: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 00 00



-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Bruno Ducrot]

On Mon, Jan 16, 2006 at 10:27:28PM +0100, Janosch Machowinski wrote:
> >Sound like \_SB.INV7 is a bit into a GPIO.
> >More, the associated OR is defined like that:
> >	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 
> >
> >Note that IO2B is given here:
> >    OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
> >    Field (BIOS, ByteAcc, NoLock, Preserve)
> >    {
> >        SS1,    1,
> >        SS2,    1,
> >        SS3,    1,
> >        SS4,    1,
> >        Offset (0x01),
> >        IOST,   16,
> >        SPIO,   16,
> >        PMBS,   16,
> >        PMLN,   8,
> >        SMBS,   16,
> >        SMLN,   8,
> >        IO1B,   16,
> >        IO1L,   8,
> >        IO2B,   16,
> >        IO2L,   8,
> >        TOPM,   32,
> >        ROMS,   32,
> >
> >Therefore one think to check is that IO2B is set correctly to point to
> >the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).
> >
> >For checking if IO2B is correct:
> >sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump
> >
> Here it get's strange :
> scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
> dd: reading `/dev/mem': Bad address
> 0+0 records in
> 0+0 records out

There is physical 512Mo RAM, isn't there? Or the DSDT have been
overriden?
How about a 'cat /proc/iomem'?

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Janosch Machowinski]

>>>Sound like \_SB.INV7 is a bit into a GPIO.
>>>More, the associated OR is defined like that:
>>>	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 
>>>
>>>Note that IO2B is given here:
>>>   OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
>>>   Field (BIOS, ByteAcc, NoLock, Preserve)
>>>   {
>>>       SS1,    1,
>>>       SS2,    1,
>>>       SS3,    1,
>>>       SS4,    1,
>>>       Offset (0x01),
>>>       IOST,   16,
>>>       SPIO,   16,
>>>       PMBS,   16,
>>>       PMLN,   8,
>>>       SMBS,   16,
>>>       SMLN,   8,
>>>       IO1B,   16,
>>>       IO1L,   8,
>>>       IO2B,   16,
>>>       IO2L,   8,
>>>       TOPM,   32,
>>>       ROMS,   32,
>>>
>>>Therefore one think to check is that IO2B is set correctly to point to
>>>the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).
>>>
>>>For checking if IO2B is correct:
>>>sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump
>>>
>>
>>Here it get's strange :
>>scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
>>dd: reading `/dev/mem': Bad address
>>0+0 records in
>>0+0 records out
> 
> 
> There is physical 512Mo RAM, isn't there? Or the DSDT have been
> overriden?
> How about a 'cat /proc/iomem'?
> 
Jup, here is 512 MB of RAM, the DSDT hasen't been overidden.


scotch@scotchmobil ~ $ cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000f0000-000fffff : System ROM
00100000-1ff3ffff : System RAM
   00100000-004853d6 : Kernel code
   004853d7-00583193 : Kernel data
1ff40000-1ff4ffff : ACPI Tables
1ff50000-1fffffff : ACPI Non-volatile Storage
30000000-300003ff : 0000:00:1f.1
32000000-33ffffff : PCI CardBus #03
34000000-35ffffff : PCI CardBus #03
36000000-37ffffff : PCI CardBus #07
38000000-39ffffff : PCI CardBus #07
ce900000-de9fffff : PCI Bus #01
   d0000000-d7ffffff : 0000:01:00.0
     d0000000-d7ffffff : radeon
dea00000-deafffff : PCI Bus #02
e0000000-efffffff : 0000:00:00.0
ff800000-ff8fffff : PCI Bus #01
   ff8c0000-ff8dffff : 0000:01:00.0
   ff8f0000-ff8fffff : 0000:01:00.0
     ff8f0000-ff8fffff : radeon
ff900000-ff9fffff : PCI Bus #02
   ff900000-ff900fff : 0000:02:01.0
     ff900000-ff900fff : yenta_socket
   ff901000-ff901fff : 0000:02:01.1
     ff901000-ff901fff : yenta_socket
   ff9ee000-ff9eefff : 0000:02:02.0
   ff9ef800-ff9effff : 0000:02:01.2
     ff9ef800-ff9effff : ohci1394
   ff9f0000-ff9fffff : 0000:02:00.0
     ff9f0000-ff9fffff : tg3
ffaff400-ffaff4ff : 0000:00:1f.5
   ffaff400-ffaff4ff : Intel 82801DB-ICH4
ffaff800-ffaff9ff : 0000:00:1f.5
   ffaff800-ffaff9ff : Intel 82801DB-ICH4
ffaffc00-ffafffff : 0000:00:1d.7
   ffaffc00-ffafffff : ehci_hcd
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Bruno Ducrot]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

On Tue, Jan 17, 2006 at 01:41:39PM +0100, Janosch Machowinski wrote:
> >>>Sound like \_SB.INV7 is a bit into a GPIO.
> >>>More, the associated OR is defined like that:
> >>>	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 
> >>>
> >>>Note that IO2B is given here:
> >>>  OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
> >>>  Field (BIOS, ByteAcc, NoLock, Preserve)
> >>>  {
> >>>      SS1,    1,
> >>>      SS2,    1,
> >>>      SS3,    1,
> >>>      SS4,    1,
> >>>      Offset (0x01),
> >>>      IOST,   16,
> >>>      SPIO,   16,
> >>>      PMBS,   16,
> >>>      PMLN,   8,
> >>>      SMBS,   16,
> >>>      SMLN,   8,
> >>>      IO1B,   16,
> >>>      IO1L,   8,
> >>>      IO2B,   16,
> >>>      IO2L,   8,
> >>>      TOPM,   32,
> >>>      ROMS,   32,
> >>>
> >>>Therefore one think to check is that IO2B is set correctly to point to
> >>>the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).
> >>>
> >>>For checking if IO2B is correct:
> >>>sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump
> >>>
> >>
> >>Here it get's strange :
> >>scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
> >>dd: reading `/dev/mem': Bad address
> >>0+0 records in
> >>0+0 records out
> >
> >
> >There is physical 512Mo RAM, isn't there? Or the DSDT have been
> >overriden?
> >How about a 'cat /proc/iomem'?
> >
> Jup, here is 512 MB of RAM, the DSDT hasen't been overidden.
> 
> 
> scotch@scotchmobil ~ $ cat /proc/iomem
> 00000000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000cffff : Video ROM
> 000f0000-000fffff : System ROM
> 00100000-1ff3ffff : System RAM
>   00100000-004853d6 : Kernel code
>   004853d7-00583193 : Kernel data
> 1ff40000-1ff4ffff : ACPI Tables
> 1ff50000-1fffffff : ACPI Non-volatile Storage
> 30000000-300003ff : 0000:00:1f.1
> 32000000-33ffffff : PCI CardBus #03
> 34000000-35ffffff : PCI CardBus #03
> 36000000-37ffffff : PCI CardBus #07
> 38000000-39ffffff : PCI CardBus #07
> ce900000-de9fffff : PCI Bus #01
>   d0000000-d7ffffff : 0000:01:00.0
>     d0000000-d7ffffff : radeon
> dea00000-deafffff : PCI Bus #02
> e0000000-efffffff : 0000:00:00.0
> ff800000-ff8fffff : PCI Bus #01
>   ff8c0000-ff8dffff : 0000:01:00.0
>   ff8f0000-ff8fffff : 0000:01:00.0
>     ff8f0000-ff8fffff : radeon
> ff900000-ff9fffff : PCI Bus #02
>   ff900000-ff900fff : 0000:02:01.0
>     ff900000-ff900fff : yenta_socket
>   ff901000-ff901fff : 0000:02:01.1
>     ff901000-ff901fff : yenta_socket
>   ff9ee000-ff9eefff : 0000:02:02.0
>   ff9ef800-ff9effff : 0000:02:01.2
>     ff9ef800-ff9effff : ohci1394
>   ff9f0000-ff9fffff : 0000:02:00.0
>     ff9f0000-ff9fffff : tg3
> ffaff400-ffaff4ff : 0000:00:1f.5
>   ffaff400-ffaff4ff : Intel 82801DB-ICH4
> ffaff800-ffaff9ff : 0000:00:1f.5
>   ffaff800-ffaff9ff : Intel 82801DB-ICH4
> ffaffc00-ffafffff : 0000:00:1d.7
>   ffaffc00-ffafffff : ehci_hcd

Ok.  Well maybe that little tool attached could give us the
information.

-- 
Bruno Ducrot

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

[-- Attachment #2: check_io2b.c --]
[-- Type: text/x-csrc, Size: 903 bytes --]

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/stat.h>


int main(void)
{
	int fd;
	off_t c;
	unsigned char t[2];

	fd = open("/dev/mem", O_RDONLY);
	if (fd < 0) {
		perror("open /dev/mem");
		exit(1);
	}

	/*
	 * SS1,    1,	<- 0
	 * SS2,    1,
	 * SS3,    1,
	 * SS4,    1,
	 * Offset (0x01),
	 * IOST,   16,	<-   1, 2
	 * SPIO,   16,	<-   3, 4
	 * PMBS,   16,	<-   5, 6
	 * PMLN,   8,	<-   7
	 * SMBS,   16,	<-   8, 9
	 * SMLN,   8,	<-   A
	 * IO1B,   16,	<-   B, C
	 * IO1L,   8,	<-   D
	 * IO2B,   16,	<-   E, F
	 * IO2L,   8,
	 * TOPM,   32,
	 * ROMS,   32,
	 */

	c = lseek(fd, 0x1FF50064 + 0xE, SEEK_SET);
	if (c != 0x1FF50064 + 0xE) {
		perror("lseek");
		exit(1);
	}

	if (read(fd, t, 2) != 2) {
		perror("read");
		close(fd);
		exit(1);
	}
	close(fd);

	printf("0x%x\n", ((t[0] & 0xff) << 8) | (t[1] & 0xff));

	return 0;
}

Re: Strange interpreter behaviour

[Janosch Machowinski]

> On Tue, Jan 17, 2006 at 01:41:39PM +0100, Janosch Machowinski wrote:
> 
>>>>>Sound like \_SB.INV7 is a bit into a GPIO.
>>>>>More, the associated OR is defined like that:
>>>>>	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 
>>>>>
>>>>>Note that IO2B is given here:
>>>>> OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
>>>>> Field (BIOS, ByteAcc, NoLock, Preserve)
>>>>> {
>>>>>     SS1,    1,
>>>>>     SS2,    1,
>>>>>     SS3,    1,
>>>>>     SS4,    1,
>>>>>     Offset (0x01),
>>>>>     IOST,   16,
>>>>>     SPIO,   16,
>>>>>     PMBS,   16,
>>>>>     PMLN,   8,
>>>>>     SMBS,   16,
>>>>>     SMLN,   8,
>>>>>     IO1B,   16,
>>>>>     IO1L,   8,
>>>>>     IO2B,   16,
>>>>>     IO2L,   8,
>>>>>     TOPM,   32,
>>>>>     ROMS,   32,
>>>>>
>>>>>Therefore one think to check is that IO2B is set correctly to point to
>>>>>the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).
>>>>>
>>>>>For checking if IO2B is correct:
>>>>>sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump
>>>>>
>>>>
>>>>Here it get's strange :
>>>>scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
>>>>dd: reading `/dev/mem': Bad address
>>>>0+0 records in
>>>>0+0 records out
>>>
>>>
>>>There is physical 512Mo RAM, isn't there? Or the DSDT have been
>>>overriden?
>>>How about a 'cat /proc/iomem'?
>>>
>>
>>Jup, here is 512 MB of RAM, the DSDT hasen't been overidden.
>>
>>
>>scotch@scotchmobil ~ $ cat /proc/iomem
>>00000000-0009fbff : System RAM
>>0009fc00-0009ffff : reserved
>>000a0000-000bffff : Video RAM area
>>000c0000-000cffff : Video ROM
>>000f0000-000fffff : System ROM
>>00100000-1ff3ffff : System RAM
>>  00100000-004853d6 : Kernel code
>>  004853d7-00583193 : Kernel data
>>1ff40000-1ff4ffff : ACPI Tables
>>1ff50000-1fffffff : ACPI Non-volatile Storage
>>30000000-300003ff : 0000:00:1f.1
>>32000000-33ffffff : PCI CardBus #03
>>34000000-35ffffff : PCI CardBus #03
>>36000000-37ffffff : PCI CardBus #07
>>38000000-39ffffff : PCI CardBus #07
>>ce900000-de9fffff : PCI Bus #01
>>  d0000000-d7ffffff : 0000:01:00.0
>>    d0000000-d7ffffff : radeon
>>dea00000-deafffff : PCI Bus #02
>>e0000000-efffffff : 0000:00:00.0
>>ff800000-ff8fffff : PCI Bus #01
>>  ff8c0000-ff8dffff : 0000:01:00.0
>>  ff8f0000-ff8fffff : 0000:01:00.0
>>    ff8f0000-ff8fffff : radeon
>>ff900000-ff9fffff : PCI Bus #02
>>  ff900000-ff900fff : 0000:02:01.0
>>    ff900000-ff900fff : yenta_socket
>>  ff901000-ff901fff : 0000:02:01.1
>>    ff901000-ff901fff : yenta_socket
>>  ff9ee000-ff9eefff : 0000:02:02.0
>>  ff9ef800-ff9effff : 0000:02:01.2
>>    ff9ef800-ff9effff : ohci1394
>>  ff9f0000-ff9fffff : 0000:02:00.0
>>    ff9f0000-ff9fffff : tg3
>>ffaff400-ffaff4ff : 0000:00:1f.5
>>  ffaff400-ffaff4ff : Intel 82801DB-ICH4
>>ffaff800-ffaff9ff : 0000:00:1f.5
>>  ffaff800-ffaff9ff : Intel 82801DB-ICH4
>>ffaffc00-ffafffff : 0000:00:1d.7
>>  ffaffc00-ffafffff : ehci_hcd
> 
> 
> Ok.  Well maybe that little tool attached could give us the
> information.
> 
Nope, scotchmobil pmtools # ./a.out
read: Bad address

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Strange interpreter behaviour

[Bruno Ducrot]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Tue, Jan 17, 2006 at 03:28:44PM +0100, Janosch Machowinski wrote:
> >
> >Ok.  Well maybe that little tool attached could give us the
> >information.
> >
> Nope, scotchmobil pmtools # ./a.out
> read: Bad address

Sometimes I'm stupid.  Try this version instead.


-- 
Bruno Ducrot

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

[-- Attachment #2: check_io2b.c --]
[-- Type: text/x-csrc, Size: 895 bytes --]

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>


int main(void)
{
	int fd;
	off_t c;
	unsigned char *p;

	fd = open("/dev/mem", O_RDONLY);
	if (fd < 0) {
		perror("open /dev/mem");
		exit(1);
	}

	/*
	 * SS1,    1,	<- 0
	 * SS2,    1,
	 * SS3,    1,
	 * SS4,    1,
	 * Offset (0x01),
	 * IOST,   16,	<-   1, 2
	 * SPIO,   16,	<-   3, 4
	 * PMBS,   16,	<-   5, 6
	 * PMLN,   8,	<-   7
	 * SMBS,   16,	<-   8, 9
	 * SMLN,   8,	<-   A
	 * IO1B,   16,	<-   B, C
	 * IO1L,   8,	<-   D
	 * IO2B,   16,	<-   E, F
	 * IO2L,   8,
	 * TOPM,   32,
	 * ROMS,   32,
	 */

	p = mmap(NULL, 1024, PROT_READ, MAP_SHARED, fd, 0x1FF50000);
	if (p == MAP_FAILED) {
		perror("mmap");
		exit(1);
	}
	close(fd);
	printf("0x%x\n", ((p[0x64 + 0xf] & 0xff) << 8) | (p[0x64 + 0xe] & 0xff));
	munmap(p, 1024);

	return 0;
}

Re: Strange interpreter behaviour

[Janosch Machowinski]

> Sometimes I'm stupid.  Try this version instead.
> 
Okay, this worked,
the outprut from your little programm was 0x500,
but it should be
GPE0_BLK:         0x00000428
GPE1_BLK:         0x00000000

So is this an error in ACPI-CA or in my DSDT ?

Re: Strange interpreter behaviour

[Bruno Ducrot]

[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]

On Fri, Jan 20, 2006 at 04:27:50PM +0100, Janosch Machowinski wrote:
> >Sometimes I'm stupid.  Try this version instead.
> >
> Okay, this worked,
> the outprut from your little programm was 0x500,
> but it should be
> GPE0_BLK:         0x00000428
> GPE1_BLK:         0x00000000
> 
> So is this an error in ACPI-CA or in my DSDT ?
> 

>From the ich4-m specification (see
ftp://download.intel.com/design/mobile/datashts/25233701.pdf
)
and the lspci -xxx I've requested, we can look that, for the isa
bridge, we can see that 0x500 is the base address for the GPIO
configuration registers.

The lspci show us:
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge (rev 03)
Flags: bus master, medium devsel, latency 0
00: 86 80 cc 24 0f 01 80 02 03 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 01 05 00 00 10 00 00 00
60: 0b 04 0a 05 90 00 00 00 80 80 80 0a 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 28 03 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 80 02 02 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 02 28 00 00 02 cf 00 00 04 00 00 00 00 00 00 00
e0: 12 00 00 c0 00 00 06 34 33 22 11 00 00 00 67 45
f0: 00 00 01 00 00 00 00 00 60 0f 03 00 00 00 80 02


The GPIO base address is at 0x58-0x5b (see page 305).

>From page 396 (9.10 General Purpose I/O Registers) we'll
learn that the ACPI node INV7 correspond to the
8th bit of the 'GPIO signal invert (GPI_INV)' register.

Therefore actually INV7 control somehow we'll treat
what happens under the GPE0_BLK, but do not modify it.
(I must confess I don't see why the ODM designed
that stuff like this).

At the description of this register, and for bit 8, we'll
see that setting this bit will have no effect if the
corresponding GPIO is set as an output.  We'll therefore
shall check if that is the problem.

Could you please (again, sorry!) run the next tool attached?
This would help to progress a little bit further.

NB: please compile it with -O flags at least:

gcc -O -W -Wall scan_gpio_ctl.c -o scan_gpio_ctl
sudo ./scan_gpio

-- 
Bruno Ducrot

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

[-- Attachment #2: scan_gpio_ctl.c --]
[-- Type: text/x-csrc, Size: 495 bytes --]

#include <stdio.h>
#include <stdlib.h>

#include <sys/io.h>

#define GPIO_BASE	0x0500

int main(void)
{
	int i;
	int gpio_base = GPIO_BASE;

	if (iopl(3)) {
		perror("iopl");
		exit(1);
	}

	printf("     00 01 02 03 04 05 06 07   08 09 0a 0b 0c 0d 0e 0f");
	for (i = 0; i < 64; ++i) {
		switch (i % 16) {
		case 0:
			printf("\n%.4x ", gpio_base + i);
			break;
		case 8:
			printf("  ");
			break;
		default:
			break;
		}
		printf("%.2x ", inb(gpio_base + i));
	}
	printf("\n");

	return 0;
}

Re: Strange interpreter behaviour

[Janosch Machowinski]

> On Fri, Jan 20, 2006 at 04:27:50PM +0100, Janosch Machowinski wrote:
> 
>>>Sometimes I'm stupid.  Try this version instead.
>>>
>>
>>Okay, this worked,
>>the outprut from your little programm was 0x500,
>>but it should be
>>GPE0_BLK:         0x00000428
>>GPE1_BLK:         0x00000000
>>
>>So is this an error in ACPI-CA or in my DSDT ?
>>
> 
> 
>>From the ich4-m specification (see
> ftp://download.intel.com/design/mobile/datashts/25233701.pdf
> )
> and the lspci -xxx I've requested, we can look that, for the isa
> bridge, we can see that 0x500 is the base address for the GPIO
> configuration registers.
> 
> The lspci show us:
> 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
> Bridge (rev 03)
> Flags: bus master, medium devsel, latency 0
> 00: 86 80 cc 24 0f 01 80 02 03 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 40: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 01 05 00 00 10 00 00 00
> 60: 0b 04 0a 05 90 00 00 00 80 80 80 0a 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 28 03 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 80 02 02 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 02 28 00 00 02 cf 00 00 04 00 00 00 00 00 00 00
> e0: 12 00 00 c0 00 00 06 34 33 22 11 00 00 00 67 45
> f0: 00 00 01 00 00 00 00 00 60 0f 03 00 00 00 80 02
> 
> 
> The GPIO base address is at 0x58-0x5b (see page 305).
> 
>>From page 396 (9.10 General Purpose I/O Registers) we'll
> learn that the ACPI node INV7 correspond to the
> 8th bit of the 'GPIO signal invert (GPI_INV)' register.
> 
> Therefore actually INV7 control somehow we'll treat
> what happens under the GPE0_BLK, but do not modify it.
> (I must confess I don't see why the ODM designed
> that stuff like this).
> 
> At the description of this register, and for bit 8, we'll
> see that setting this bit will have no effect if the
> corresponding GPIO is set as an output.  We'll therefore
> shall check if that is the problem.
> 
> Could you please (again, sorry!) 
Don't be sorry to debug my notebook ;-)
run the next tool attached?
> This would help to progress a little bit further.
> 

scotchmobil pmtools # ./scan_gpio_ctl
      00 01 02 03 04 05 06 07   08 09 0a 0b 0c 0d 0e 0f
0500 bf 39 00 1a ff ff 00 00   00 00 00 00 00 00 01 08
0510 00 00 00 00 00 00 00 00   00 00 00 02 00 00 00 00
0520 00 00 00 00 00 00 00 00   00 00 00 00 88 39 00 00
0530 ff 0f 00 00 06 04 00 00   8f 04 00 00 00 00 00 00