IHC7 DSDT AHCI Patch

[RehabMan]

Okay, I tried

OperationRegion (GICR, SystemMemory, Subtract(3, And(ABAX,Not(0x3FF))), 4) // GICR is offset ABR+04h-07h; length 32
                Field (GICR, ByteAcc, NoLock, Preserve)
                {
                    
                    GIC0,   32, // Returns entire field
                }

which returned 0xff53f0 (I assume I have to pad the beginning with two zeros to make it a 32bit number, 0x00ff53f0), but when translated to binary has ones in bits reserved zero. I also tried:

OperationRegion (GICR, PCI_config, Subtract(3, And(ABAX,Not(0x3FF))), 4) // GICR is offset ABR+04h-07h; length 32
                Field (GICR, ByteAcc, NoLock, Preserve)
                {
                    
                    GIC0,   32, // Returns entire field
                }

which returns 0xB0000727, which is a 32 bit number, but when translated to binary, again has 1s in bits that should be reserved 0. Am I doing something wrong?

I don't get what you mean by masking off the other bits (the Not(0x3FF) operation). Could you go into more depth on why this is needed?

You should verify the accuracy of the documentation (and the interpretation of it) in RW-Everything in Windows...

If you read the docs on the base address, the lower 10 bits are not part of the address, but are other things. Hence the And(ABAX,Not(0x3FF)).

 

[shinzon]

Okay, here's what I got after another day of playing with it. I went through and set the necessary bits for SATA in AHCI mode in every register except those that require an abar+x-x offset.

Nothing I've done so far (including setting a bit that was supposed to enable AHCI memory space) has changed the value of ABAR to anything other than 0x0.

Looking at this part of the datasheet:

It says "The ABAR register must be set to a value of 0001_0000h or greater."

What does the dash in the middle of the hex number mean? Does that mean, in binary, that it should be set from:

0000 0000 0000 0000 0000 0000 0000 0000

to

0001 0000 0000 0000 0000 0000 0000 0000

I also made an AppleAHCIPort FakePCIID injector. With no method _DSM, FakePCIID will use my injector as a personalitypublisher, and will match 0x27c58086 and attach to SATA@1f,2, but it will not load AppleAHCIPort.kext. There is nothing related to FakePCIID or AppleAHCIPort in console. Given that it's attaching to the AHCI device-id, that would suggest that AppleAHCIPort.kext should be able to as well.

I also tried with a method _DSM that injects the AHCI device-id in combination with FakePCIID. That didn't' work either.

You should verify the accuracy of the documentation (and the interpretation of it) in RW-Everything in Windows...

That's my next step. Thanks for the tip on RW-Everything.

If you read the docs on the base address, the lower 10 bits are not part of the address, but are other things. Hence the And(ABAX,Not(0x3FF)).

Yup, I didn't understand how bit masking worked. I read up on it and now I understand what you're doing there. With ABAR at 0x0 I don't think it's giving my the correct memory slice. All of the bits that are reserved 0 are 1 with this, so it can't be right. I'll verify in Windows

 

[shinzon]

What do I keep posting that is setting off the post filter? It keeps eating my posts.

 

[RehabMan]

Okay, here's what I got after another day of playing with it. I went through and set the necessary bits for SATA in AHCI mode in every register except those that require an abar+x-x offset.

Nothing I've done so far (including setting a bit that was supposed to enable AHCI memory space) has changed the value of ABAR to anything other than 0x0.

Looking at this part of the datasheet:

It says "The ABAR register must be set to a value of 0001_0000h or greater."

What does the dash in the middle of the hex number mean? Does that mean, in binary, that it should be set from:

0000 0000 0000 0000 0000 0000 0000 0000

to

0001 0000 0000 0000 0000 0000 0000 0000

Not sure as I don't see any documentation you've posted for an "ABAR" register...

I also made an AppleAHCIPort FakePCIID injector. With no method _DSM, FakePCIID will use my injector as a personalitypublisher, and will match 0x27c58086 and attach to SATA@1f,2, but it will not load AppleAHCIPort.kext. There is nothing related to FakePCIID or AppleAHCIPort in console. Given that it's attaching to the AHCI device-id, that would suggest that AppleAHCIPort.kext should be able to as well.

Assuming a matching IOKItPersonality in AppleAHCIPort.kext, it will load, but may fail :robe or ::start if it finds something it doesn't like.

Thanks for the tip on RW-Everything.
...
I'll verify in Windows

Good idea...

 

[shinzon]

Not sure as I don't see any documentation you've posted for an "ABAR" register...

That is the documentation for ABAR. The title is just on the previous page:

It bears mentioning that ABAR is not R/0; so at least I know I have that much right.

Good idea...

How would I go about changing to the AHCI controller in Windows? I don't think it's possible to use Clover to inject a patched DSDT. I see I can change the bit directly with R/W everything, but wouldn't that cause a bluescreen since Windows wasn't installed to expect an AHCI drive (same as enabling AHCI in the bios when Windows wasn't installed in AHCI mode)?

Also, I played around with RW-Tools on my D630 that is currently booting in AHCI mode. It's an ICH8 chipset, but a quick look at the datasheet revealed the AHCI documentation was generally the same. Offset 90h, for example, is the same 40h as I'm setting it on my ICH7. This machine has ABAR set to something other than 0x0, so it would appear this is one of the steps necessary (either setting it manually, or figuring out what combination of bits causes it to be set) to get this controller working on my Snow Leopard laptop.

 

[RehabMan]

That is the documentation for ABAR. The title is just on the previous page:

It bears mentioning that ABAR is not R/0; so at least I know I have that much right.

I doubt you could change the base address as set in PCI_Config. Hence why they mark as RO.

If you find it to be zero, perhaps this is a function of BIOS. Allocating memory for it in the memory map, and setting it...

How would I go about changing to the AHCI controller in Windows? I don't think it's possible to use Clover to inject a patched DSDT.

I've never had good results with that (injecting patched DSDT).

I see I can change the bit directly with R/W everything, but wouldn't that cause a bluescreen since Windows wasn't installed to expect an AHCI drive (same as enabling AHCI in the bios when Windows wasn't installed in AHCI mode)?

Yes, that won't work. But you should use RW-Everything to verify your understanding of the spec.

Also, I played around with RW-Tools on my D630 that is currently booting in AHCI mode. It's an ICH8 chipset, but a quick look at the datasheet revealed the AHCI documentation was generally the same. Offset 90h, for example, is the same 40h as I'm setting it on my ICH7. This machine has ABAR set to something other than 0x0, so it would appear this is one of the steps necessary (either setting it manually, or figuring out what combination of bits causes it to be set) to get this controller working on my Snow Leopard laptop.

What is ABAR in RW-Everything?

 

[shinzon]

I doubt you could change the base address as set in PCI_Config. Hence why they mark as RO.

If you find it to be zero, perhaps this is a function of BIOS. Allocating memory for it in the memory map, and setting it...

I've read reading about SATA bus enumeration, and it's generally the responsibility of the BIOS to allocate the necessary memory. I'll continue researching it.

Yes, that won't work. But you should use RW-Everything to verify your understanding of the spec.



What is ABAR in RW-Everything?

The ABAR value on the ICH7 machine is 0x00FCBFFE (in windows)
On the ICH8 machine it is 0x00B8DFF6

 

[RehabMan]

I've read reading about SATA bus enumeration, and it's generally the responsibility of the BIOS to allocate the necessary memory. I'll continue researching it.




The ABAR value on the ICH7 machine is 0x00FCBFFE (in windows)
On the ICH8 machine it is 0x00B8DFF6

So, it is:
- not zero
- already allocated by BIOS

 

[shinzon]

So, it is:
- not zero
- already allocated by BIOS

I don't understand why PCIDebug is returning 0x0 then.

Do you know of any similar programs like RW Everything that run on a Mac that would allow me to dump the SATA memory range? I have access to a real macbookpro2,2 with an ICH7-M chipset and the same AHCI device-ID. I'd love to see what it has set to enable AHCI.

Digging deeper into the documentation, I also found this:


Though I guess it doesn't really apply unless the PATA controller is interfering in some way.

 

[RehabMan]

I don't understand why PCIDebug is returning 0x0 then.

No idea without seeing the code and logs.

Do you know of any similar programs like RW Everything that run on a Mac that would allow me to dump the SATA memory range? I have access to a real macbookpro2,2 with an ICH7-M chipset and the same AHCI device-ID. I'd love to see what it has set to enable AHCI.

You can use ACPIDebug.kext on a real Mac. I have used Clover to boot my Apple MacBookAir6,2 in order to provide patched DSDT, with the purpose of using ACPIDebug...