Damnation

Other than not needing to apply your hack to acpi.sys every time we build it I'm not sure, I don't recall ever making use of the GPIO.

@Mov AX, 0xDEAD @daniel_k Could we use code from reactos for unsupported opcodes?

@Dietmar I downloaded the BIOS for the ASRock B550 Steel Legend (board I chose for a build, still waiting for it on backorder) checked it's DSDT, it also has Device (GPIO) { Name (_HID, "AMDI0030") // _HID: Hardware ID Name (_CID, "AMDI0030") // _CID: Compatible ID Name (_UID, Zero) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, } Memory32Fixed (ReadWrite, 0xFED81500, // Address Base 0x00000400, // Address Length ) }) Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */ } I think perhaps all AMD Ryzen boards use this DSDT code.

@Dietmar maybe try this? if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { // // It's a PCI PDO, which means a root PCI bus, // which means that we should just handle this // as an ISA device. // return STATUS_NOT_FOUND; } elseif (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_ISA) { // return STATUS_NOT_FOUND; }

@Mov AX, 0xDEAD For the unknown error in _AMLILoadDDB could we feasibly use the version from windows 8.1? . psuedocode of AMLILoadDDB 8.1 generated by relyze int __fastcall _AMLILoadDDB( int p1, int p2 ) { unsigned short local_0x2C; // [esp-44] unsigned short local_0x2A; // [esp-42] unsigned short local_0x26; // [esp-38] unsigned int local_0x24; // [esp-36] int v1; // [esp-30] int v2; // [esp-26] int v3; // [esp-22] void * local_0xC; // [esp-12] unsigned int local_0x8; // [esp-8] int v4; // eax local_0x2C = 0; local_0xC = 0; local_0x2A = 0; local_0x8 = 0; local_0x26 = 0; local_0x24 = 0; v1 = 0; v2 = 0; v3 = 0; if( _ghQueryDLMSupportHandler != 0 ) { _ghQueryDLMSupportHandler( &local_0x8 ); } else { local_0x8 = 0; } _gDeviceLockMutexSupported = local_0x8; v4 = _NewContext( &local_0xC ); if( v4 == 0 ) { *((unsigned char *)local_0xC + 176) = _gpheapGlobal; v4 = LoadDDB( _gpnsNameSpaceRoot, &local_0x2C ); if( v4 == 0 ) { v4 = SyncLoadDDB( local_0xC ); } } if( p2 != 0 ) { *p2 = local_0x24; } return v4; }

@Dietmar Just an idea - for ACPIArbCrackPRT can you try this out? // if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { if (!((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { // // It's a PCI PDO, which means a root PCI bus, // which means that we should just handle this // as an ISA device. // return STATUS_NOT_FOUND; } } ASSERT(PciInterfacesInstantiated); still 7E BSOD? or something else?

@Dietmar do you mean having ULONG64 for CreateQWordField instead of ULONG? after this is changed A5 0x02 is gone?

@Mov AX, 0xDEAD Maybe try comparing nonworking ACPIArbCrackPRT to working LinkNodeCrackPrt to try and find what LinkNodeCrackPrt does differently to avoid the BSOD?

@Mov AX, 0xDEAD So is acpi.sys expecting DEV_CAP_PCI to be a PDO but it is something else?

@WinWord2000 I'm taking a break from working on it for now.

@Dietmar Looking at the logs there, I'm a bit more confident that if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) is the cause I think try commenting it out, compile and test.

@Dietmar In source code we just comment out entire function and return all OK?

@Andalu I have this same problem on my AMD Threadripper System, I even get this A5 0x11 0x08 BSOD on Windows 8.0 as of right now the best we can do for this case is to tell acpi.sys to ignore failed DDB Load.

@Dietmar I recall the problem was somewhere near PciInterfacesInstantiated I think the problem in ACPIArbCrackPRT might be this if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { // // It's a PCI PDO, which means a root PCI bus, // which means that we should just handle this // as an ISA device. // return STATUS_NOT_FOUND; } try commenting this out and see if that works?

@Mov AX, 0xDEAD I would like to try and see if I can implement 64bit integer support. what functions should I be focusing on to properly implement this? which acpi.sys version has a proper 64bit integer support?

I bought my first AMD Ryzen 5000 series desktop system today (previous desktop was older 2000 series with 300 chipset) I'll compile and test this when the system is ready. I went with an ASRock motherboard, for whatever reason they use an iASL compiler from 2012 for their AMD boards and they seem to be the only vendor doing this. I wonder if this might be more ACPI friendly for XP because of it?

@Dietmar But isn't that hack just skipping over the error rather than actually resolving the issue?

@Dietmar there is an ACPIDebugResourceRequirementsList function, maybe that can help?

@Dietmar you may as well try my earlier suggestion -

@TrevMUN That would be @Dietmar he's on this forum actually, he can help you get NVMe working on XP if you're still interested.

@George King As far as I know there isn't an easy way to convert assembly back into C code, at best you can get some psuedo code with a dissassembler. Everything would be so much easier if there was a reliable way to convert to C code.

We'll have to convert those functions implemented with _asm into C code if we ever want to produce an x64 version of this.

@Mov AX, 0xDEAD Concerning the CreateQwordfield implementation, would doing something like this work better? pbf->FieldDesc.dwNumBits = 8*sizeof(ULONGLONG); pbf->FieldDesc.dwFieldFlags = ACCTYPE_QWORD;

@Mov AX, 0xDEAD Nice Work! much appreciated! thanks!

@Mov AX, 0xDEAD If not 2000 then ME? I think Windows 2000 and Windows ME are on par to each other in terms of WDM driver model support. As in Windows ME's NTKERN.VXD has the same functionality implemented as 2000, unless I'm mistaken. I think it'd be cool to have storport/ahci/nvme and usb3 support in ME. But then I doubt you're that interested in supporting any of Windows 9x/ME