#10970 NORM Not Tri: Unknown ACPI opcode error with updated XO-1.5 OS/firmware

[Zarro Boogs per Child]

#10970: Unknown ACPI opcode error with updated  XO-1.5 OS/firmware
-------------------------------------------+--------------------------------
           Reporter:  greenfeld            |       Owner:  Quozl                            
               Type:  defect               |      Status:  new                              
           Priority:  normal               |   Milestone:  Not Triaged                      
          Component:  ofw - open firmware  |     Version:  Development build as of this date
         Resolution:                       |    Keywords:                                   
        Next_action:  test in build        |    Verified:  0                                
Deployment_affected:                       |   Blockedby:                                   
           Blocking:                       |  
-------------------------------------------+--------------------------------
Changes (by wmb at firmworks.com):

  * owner:  wmb at firmworks.com => Quozl
  * next_action:  diagnose => test in build


Comment:

 0xff5b is indeed invalid as an ACPI opcode.  That sequence does not appear
 in the ACPI DSDT binary that OFW exports to the OS (verified with a hex
 editor).  Therefore, my best guess is that the memory containing the DSDT
 is getting corrupted.  Following that train of thought...

 The AML address is b00fc63f.  OFW puts the DSDT into low memory starting
 at 000fc000, so it's a fair guess that Linux maps low memory at virtual
 b0000000.  So if we look at offset 63f in the DSDT binary (dsdt-
 c2only.aml), what do we see?  Aha, the byte there is 0x5b - but the next
 byte is 0x68, not 0xff.  So what could cause the data to go bad?

 If we use the strings in the binary to figure out where we are in the
 source code, we see that the affected byte is 19 bytes after the following
 code in the _PTS (prepare to sleep) routine:

     IF (LEqual(Arg0, 0x03)) {       // S3
         Store(0x0,\_SB.PCI0.MEMC.FSEG)     // Disable F Segment Read/Write
     }

 But the DSDT is in the F segment (0xf0000 - 0xfffff)!  So disabling read
 on that segment would prevent the processor from seeing it.

 But why does it wait until 19 or so bytes later before dying?  Well, the
 0x5b at the end of the same cache line as the disable code, so the disable
 would not be noticed until the memory controller tried to fetch a new
 cache line.  The first byte in the new line is the byte following the
 0x5b, so it would read back as 0xff instead of the expected 0x22.

 So why is the code disabling that segment?  I have no idea; a lot of that
 DSDT code was copied from Via's example, much of which doesn't exactly
 apply to our system.  My best guess is that the disable-segment-F code
 could and should be removed.  On legacy PCs, segment F was the boot ROM.
 Enabling segment F causes the ROM to be shadowed with RAM.  I suspect that
 Via needed to make the ROM accessible when going into S3, possibly because
 they were going to do some system management mode work on S3 entry.  We
 don't need that.

 Quozl, could you try removing lines 334 and 376 of dsdt-c2only.dsl to see
 if it fixes the problem?  If it works, the corresponding change should be
 made in dsdt.dsl .

 Note that this problem will only show up in exactly this way on systems
 that use the c2only DSDT.  The regular DSDT has different cache line
 alignment.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10970#comment:2>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system