0x001F0001 is the address of the PATA controller registers D31:F1 on the PCI_Config bus. decimal(31) = 0x001F decimal(1) = 0x0001
Thanks for the clarification. I hope you'll be able to find/insert the needed addresses to setup IDE timings. I was able to insert a quad core APIC into the BIOS, it took me 2 days trying to find the right way to do that until the OS/laptop started to boot up with my mod. Had to reduce the size of the TCPA table, so the finger print scanner is probably not functioning anymore. Waiting for my QX9300 quad core CPU to check the mod and adjust the CPU related SSDT tables. And I think I've finished inserting the other 2 cores into the DSDT.
I got a BSOD saying that my BIOS is not fully ACPI compliant. I think the problem is that the DSDT table turned out to be shorter and so the offsets of the other tables moved backwards.I don't know if that's the exact reason because I didn't have any problems after inserting a couple of strings into the DSDT table.
By the way, HPQMRM and HPQPAT are not loaded into the memory. So I think there's no need to touch them at all. We need to edit just those that are loaded into the memory. They are HPQSAT, HPQPRN, Cpu0Tst, Cpu1Tst, CpuPm. And DSDT too being the main table.
Thanks for the files. I wanted to ask about the difference between the Microsoft and Intel versions of the compiler, but have just found out the biggest difference which is the ability to load tables into the registry. I did so this time, but got the same Non-ACPI compliant BSOD. What do we do now? By the way, why did you send those SSDT tables at all if you didn't edit them? Speaking of the paddings. I've noticed HP used 00 between some tables as paddings, so 00 should be used. I told that HPQPAT and some others don't seem to get loaded into the memory, but when I zeroed it out by editing the table length and checksum in the header, the OS refused to boot and it made the laptop reboot every time. So they seem to be used somehow without being recognized by the RWE.
I wanted to ask about this piece of code. Code: Method (\_SB._INI, 0, NotSerialized) { \C009 () C01E () If(LEqual(\_SB.C009, 0x6)) { UDMA () } } In the UDMA method you are referring to C0F9. Just to make there was no typo, what is If(LEqual(\_SB.C009, 0x6)) about?
I decided to find out what the problem was and inserted just the part shown in the screenshot. I got the same BSOD. Then I replaced the whole scope with just this and the OS booted up fine: Code: Scope (_SB.C003.C0F9) { Name (D002, 0x00) } Do you have any idea of what could be the problem?
I inserted just this and got that BSOD again. I assume the registers you are trying to access through 0x001F0001 are not accessible Code: Scope (_SB.C003.C0F9) { Name (_ADR, 0x001F0001) }
You couldn't compile HPQSAT because the ASL transactor decompiled the tables with mistakes: Code: Method (_GTF, 0, NotSerialized) { Return (\_SB.C2FE) C385 0x00 } The code after the Return is incorrect not least because C385 and 0x00 cannot be used alone. C2FE is declared in this table as an integer object, but in fact it's a method from the DSDT. So the correct code should be Code: Method (_GTF, 0, NotSerialized) { Return(\_SB.C2FE(C385, 0x00)) } Then we have this piece of invalid code with the free floating C380: Code: Store (C104, 0x00) C380 C104 is a method, it's not an object. So the correct code would be: Code: Store (C104 (0x00), C380) This is another piece of wrong coding. Code: Store (C109 (0x00, 0x00, C37F, C380, Local1, Local3), \_SB.C2F7) Local2 Local3 Local1 C37D C109 is a method that in fact has 5 arguments instead of 6. And "\_SB.C2F7" is a method with 4 arguments (those are presumably sitting in the consequent lines), it's not a integer variable. Given the line that's coming before this code, The code would be: Code: Store (C109 (0x00, 0x00, C37F, C380, Local1), Local3) \_SB.C2F7 (Local2, Local3, Local1, C37D) By the way, Name (_ADR, 0x001F0001) already exists in the HPQSAT table, but you duplicated it in the DSDT. And that was probably the reason for the BSOD.
But I didn't see those mistakes in the RWE. Neither of both versions of ASL compilers are reliable. RWE is probably the best way of getting the decompiled tables
Couple things: 1. Not sure if it matters, but did you try putting the declaration of PACS to immediately after the "Name (_ADR, 0x001F0001)"? Code: Name (_ADR, 0x001F0001) OperationRegion(PACS, PCI_Config, 0x40, 0xc0) Field(PACS, DWordAcc, NoLock, Preserve) { PRIT, 16, , 16, PSIT, 4, , 28, SYNC, 4, , 12, SDT0, 2, , 2, SDT1, 2, Offset(0x14), ICR0, 4, ICR1, 4, ICR2, 4, ICR3, 4, ICR4, 4, ICR5, 4, ICR6, 4, ICR7, 4, } Name(C386, 0x01) 2. In the UDMA () function, did you move the command to set ICR4 into the comment block. Code: And(ICR4, 0xD, ICR4) 3. Just so I know what you're doing...you're overriding both the DSDT and HPQSAT tables with the Microsoft ASL compiler, right?
Brother, I'm sorry for this kind of response, I want to respond right now, but I don't have enough time today. Please have a look into my corrected tables. I've sent them over to you for your own inspection to speed things up. The HPQSAT and DSDT are in the decompiled form with all needed error-free corrections applied, so you got good source files for your further corrections. Feel free to edit them without the fear of getting a broken file after compilation. Just send me over the corrected tables in the text form and I'll compile them myself. I extended the list of the supported OS yesterday as you advised. You can see that in the DSDT table from the zip file. I also wanted to point out something about the UDMA mod. When I disable the SATA native mode (AHCI->IDE), I get the same "BIOS is not fully ACPI compliant" BSOD during starting up Windows. So we'll have to find a workaround for that too. It seems like our mod gets executed somehow, but I don't know which part does. I'll play around with calling the UDMA method a little later.
I've just checked that and found out that it was hidden in the comments. I flashed your SSDT, but nothing changed anywhere. What do you think should be done next? By the way, which Dell laptop's ACPI tables are you taking the code from?