Jump to content

Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)

Mov AX, 0xDEAD

By Mov AX, 0xDEAD
in Windows XP

 Share

Recommended Posts

Mov AX, 0xDEAD

Mov AX, 0xDEAD

Posted
  • Author
Posted (edited)

@daniel_k

9 hours ago, daniel_k said:

@Mov AX, 0xDEAD

Thanks, managed to build it and this time it worked.

Is the log size limited? Did 2 times and the old entries are lost, log is 1.58MB.

Any c0140001 errors in ParseIntObj/ParseString result in AMLILoadDDB failed 0xc0140001?

first error:

Quote

AMLI:| | | | | | ParseArg=c0140001
AMLI:| | | | | ParseTerm=c0140001

prev parsed thing:

Quote

ParseObjName=0 (Name=_ADR)

of object:

Quote

 GetObjectPath=\_SB.PCI0.HDAS.SNDW

DSDT:

Quote

    Scope (_SB.PCI0.HDAS.SNDW)
    {
        Device (SWD0)
        {
            Name (_ADR, 0x000010025D070100)  // _ADR: Address

                   08 5F 41 44 52 0E 00 01 07 5D 02 10 00 00        // ._ADR....]....

            Name (_DSD, Package (0x04)  // _DSD: Device-Specific Data

i think problem is _ADR 64-bit integer, acpi failed to parse it

0x0E is new acpi 2.0 opcode AML_QWORD_OP, my patch already support this opcode, but ParseIntOb() cannot parse it sucesfully:

Quote

ParseIntObj=c0140001

I will test this new way of name definition on VBox to check what is wrong with ParseIntOb()
 

Edited by Mov AX, 0xDEAD
Link to comment
Share on other sites

Mov AX, 0xDEAD

Mov AX, 0xDEAD

Posted
  • Author
Posted

@daniel_k

I fear problem may be in different dsdt place, before checking in VM i ask you to do one more modification

 

Errors:

Quote

AMLI:| | | | | | | ParseIntObj(pbOp=f6d2cac5,pdataResult=84edd97c,fErrOK=1)
AMLI:| | | | | | | ParseIntObj=c0140001 (pbOp=f6d2cac5,Value=0)
AMLI:| | | | | | | ParseString(pbOp=f6d2cac5,pdataResult=84edd97c,fErrOK=1)
AMLI:| | | | | | | ParseString=c0140001 (Value=<null>)
AMLI:| | | | | | ParseArg=c0140001


ParseArg(PCTXT pctxt, char chArgType, POBJDATA pdataArg):

Quote

        case ARGTYPE_DATAOBJ:
            if (((rc = ParseIntObj(&pctxt->pbOp, pdataArg, TRUE)) ==
                 AMLIERR_INVALID_OPCODE) &&
                ((rc = ParseString(&pctxt->pbOp, pdataArg, TRUE)) ==
                 AMLIERR_INVALID_OPCODE) &&
                ((*pctxt->pbOp == OP_BUFFER) || (*pctxt->pbOp == OP_PACKAGE)))
            {
                rc = PushTerm(pctxt, pctxt->pbOp, NULL,
                              OpcodeTable[*pctxt->pbOp], pdataArg);
                pctxt->pbOp++;
            }
            break;


aml bytecode:

Quote

        Device (SWD0)
        {
 3BAB7: 5B 82 81 12 01 53 57 44 30                       // [....SWD0

            Name (_ADR, 0x000010025D070100)  // _ADR: Address
 3BAC0: 08 5F 41 44 52 0E 00 01 07 5D 02 10 00 00        // ._ADR....]....

            Name (_DSD,
 3BACE: 08 5F 44 53 44                                   // ._DSD

Package (0x04)  // _DSD: Device-Specific Data
            {
 3BAD3: 12 44 4E 04     

So:
1) ParseIntObj return AMLIERR_INVALID_OPCODE
2) ParseString return AMLIERR_INVALID_OPCODE
3) *pctxt->pbOp is not OP_BUFFER () or OP_PACKAGE() because no call to PushTerm()
4) _DSD definition has OP_PACKAGE (0x12) , i dont see problem with it

Couse we dont know exact dsdt place i recommend to edit ParseArg() to write unknow opcode with nearest bytes to log:

Quote

            {
                rc = PushTerm(pctxt, pctxt->pbOp, NULL,
                              OpcodeTable[*pctxt->pbOp], pdataArg);
                pctxt->pbOp++;
            } else {
            PRINTF("Unknow ParseArg opcode %x %x %x %x %x %x %x %x \n", pctxt->pbOp[0], pctxt->pbOp[1], pctxt->pbOp[2], pctxt->pbOp[3], pctxt->pbOp[4], pctxt->pbOp[5],pctxt->pbOp[6],pctxt->pbOp[7]);
            }


 

Link to comment
Share on other sites
Dave-H

Dave-H

Posted
Posted

@Dietmar

You still haven't said whether you got anywhere with debugging the restart problem on your Flex 10.
As it seems I can't debug my machine, I'd be interested to know if you did get anywhere with finding the cause of why it will shut down but not restart.
Cheers, Dave.
:dubbio:
 

Link to comment
Share on other sites
MilkChan

MilkChan

Posted
Posted (edited)

I really appreciate this project. that made me use the old window again But I'll wait for it to be perfect. And I miss my first computer, Windows XP.

and this community MSFN
(I'm interested in XP Update Hacks using POSReady 2009 updates until 2019)
Because I don't like coverage in my country that much.
make most people look like puppets

 

POSReady 2009 differs only 5%, just add-ons

spacer.png

Edited by tpao12
Link to comment
Share on other sites
Dave-H

Dave-H

Posted
Posted

@Dietmar

You still haven't said whether you got anywhere with debugging the restart problem on the Flex 10 (I've asked three times!)
Did anyone else make any progress with that?
It's the one remaining annoyance as far as I'm concerned, and I can't debug it myself it appears as I can't connect the machine.
Cheers, Dave.
:)

Link to comment
Share on other sites
  • 3 weeks later...
daniel_k

daniel_k

Posted
Posted (edited)

@Mov AX, 0xDEAD

Sorry for the delay, I was really busy.

The board was defective and I was doing a mess with the acpi.sys versions. :crazy:
Fortunately, Amazon gives a whole month to return the board, so got a working replacement.

Specs:

  • i7-11700K
  • 16 GB
  • Gigabyte Z490 AORUS PRO AX

You latest acpi.sys works perfectly,
Surprisingly, even standby works on this board!

Sadly, don't know if because of SLI/Crossfire or Thunderbolt support, reserved memory eats almost all of my RAM, only 916 MB available. :(

For x64, there is a strange behavior, text mode setup hangs unless it is in UniProcessor mode (disable HT and only one core enabled in BIOS).
After install, XP x64 also hangs when loading (logo) if I reenable HT and all cores.

My processor has 8 cores/16 threads, so I did a test and "removed" support for additional cores (11900K has 10 cores/20 threads) from all ACPI tables.

DSDT:
 

Quote

From 20 "cores/threads"
  

        Processor (PR00, 0x01, 0x00001810, 0x06) {}
        Processor (PR01, 0x02, 0x00001810, 0x06) {}
        Processor (PR02, 0x03, 0x00001810, 0x06) {}
        Processor (PR03, 0x04, 0x00001810, 0x06) {}
        Processor (PR04, 0x05, 0x00001810, 0x06) {}
        Processor (PR05, 0x06, 0x00001810, 0x06) {}
        Processor (PR06, 0x07, 0x00001810, 0x06) {}
        Processor (PR07, 0x08, 0x00001810, 0x06) {}
        Processor (PR08, 0x09, 0x00001810, 0x06) {}
        Processor (PR09, 0x0A, 0x00001810, 0x06) {}
        Processor (PR10, 0x0B, 0x00001810, 0x06) {}
        Processor (PR11, 0x0C, 0x00001810, 0x06) {}
        Processor (PR12, 0x0D, 0x00001810, 0x06) {}
        Processor (PR13, 0x0E, 0x00001810, 0x06) {}
        Processor (PR14, 0x0F, 0x00001810, 0x06) {}
        Processor (PR15, 0x10, 0x00001810, 0x06) {}
        Processor (PR16, 0x11, 0x00001810, 0x06) {}
        Processor (PR17, 0x12, 0x00001810, 0x06) {}
        Processor (PR18, 0x13, 0x00001810, 0x06) {}
        Processor (PR19, 0x14, 0x00001810, 0x06) {}

To 16 "cores/threads"
  

        Processor (PR00, 0x01, 0x00001810, 0x06) {}
        Processor (PR01, 0x02, 0x00001810, 0x06) {}
        Processor (PR02, 0x03, 0x00001810, 0x06) {}
        Processor (PR03, 0x04, 0x00001810, 0x06) {}
        Processor (PR04, 0x05, 0x00001810, 0x06) {}
        Processor (PR05, 0x06, 0x00001810, 0x06) {}
        Processor (PR06, 0x07, 0x00001810, 0x06) {}
        Processor (PR07, 0x08, 0x00001810, 0x06) {}
        Processor (PR08, 0x09, 0x00001810, 0x06) {}
        Processor (PR09, 0x0A, 0x00001810, 0x06) {}
        Processor (PR10, 0x0B, 0x00001810, 0x06) {}
        Processor (PR11, 0x0C, 0x00001810, 0x06) {}
        Processor (PR12, 0x0D, 0x00001810, 0x06) {}
        Processor (PR13, 0x0E, 0x00001810, 0x06) {}
        Processor (PR14, 0x0F, 0x00001810, 0x06) {}
        Processor (PR15, 0x10, 0x00001810, 0x06) {}

 

Also removed references to PR16~PR19 from other SSDT tables.
With these changes, sometimes it restarts but eventually XP x64 loads properly with all cores / HT enabled.

 

Edited by daniel_k
Link to comment
Share on other sites
daniel_k

daniel_k

Posted
Posted (edited)

@Mov AX, 0xDEAD

I have two questions for you.

For x86, unfortunately, Gigabyte removed the TOLUD (Top of Low Usable DRAM) setting, there is nothing hidden that I can change regarding reserved memory.
Any ideas of how to find the module responsible for this?

For x64, we don't have a ported Win8 LAN debug. Can you please try to add these 20 processors to your VM testing and see if XP x64 (setup) fails to boot?
Or please explain what software (hypervisor) you use and how to mod the ACPI tables?

Edited by daniel_k
Link to comment
Share on other sites
daniel_k

daniel_k

Posted
Posted

@Damnation

I'm using a stock ISO with just intel ahci driver and acpi.sys replaced as USB 2.0 support is provided by a PCIe card with MCS9990 chipset.

Still didn't have time to make an updated ISO with the XHCI driver integrated.

Link to comment
Share on other sites
Mov AX, 0xDEAD

Mov AX, 0xDEAD

Posted
  • Author
Posted

@daniel_k

20 minutes ago, daniel_k said:

For x86, unfortunately, Gigabyte removed the TOLUD (Top of Low Usable DRAM) setting, there is nothing hidden that I can change regarding reserved memory.
Any ideas of how to find the module responsible for this?

no IFR setting -> to hard to 1) find exact uefi module 2) find inject place inside module

in old leaked AMI UEFI sources, tolud used in NBPEI.c/NBPEIBoard.c, i dont know name of final module

20 minutes ago, daniel_k said:

For x64, we don't have a ported Win8 LAN debug. Can you please try to add these 20 processors to your VM testing and see if XP x64 (setup) fails to boot?
Or please explain what software (hypervisor) you use and how to mod the ACPI tables?

VirtualBox:

1) limited cpu support, max 8 cpu on real 4-core cpu

2) ssdt table very simple, no packages/power control and other stuff from real boards:

DefinitionBlock ("", "SSDT", 1, "VBOX  ", "VBOXCPUT", 0x00000002)
{
    Scope (\_PR)
    {
        Processor (CPU0, 0x00, 0x00000000, 0x00) {}
        Processor (CPU1, 0x01, 0x00000000, 0x00) {}
        Processor (CPU2, 0x02, 0x00000000, 0x00) {}
        Processor (CPU3, 0x03, 0x00000000, 0x00) {}
        Processor (CPU4, 0x04, 0x00000000, 0x00) {}
        Processor (CPU5, 0x04, 0x00000000, 0x00) {}
        Processor (CPU6, 0x04, 0x00000000, 0x00) {}
        Processor (CPU7, 0x04, 0x00000000, 0x00) {}
}

QEMU:

1) doesn't have SSDT(i use patched 2.11), only DSDT exist

2) DSDT dont have CPU related definitions

 

So it is useless to test cpu related DSDT/SSDT tables on VM because it is amost virtual or stubs

1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...