Contribute
Register

IHC7 DSDT AHCI Patch

Status
Not open for further replies.
RehabMan said:
No idea without seeing the code and logs.
Click to expand...
The DSDT.dsl I'm working with is attached.

With ADDM (old ACHI) at 0x40, the output in console is:
Code: 
6/5/15 1:43:04 PM    kernel    ACPIDebug: Version 0.1.2 starting
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "VEID is", 0x8086, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "DEID is", 0x27c5, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCIC is", 0x7, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCIS is", 0x2b0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "RVIR is", 0x2, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PGIR is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCCR is", 0x6, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "BCCR is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PMLT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSVI is", 0x1028, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSDI is", 0x2f4, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCMD is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCNL is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCMD is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCNL is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "LBAR is", 0x1811, }
[B]6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ABAR is", 0x0, }[/B]
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ADDM is", 0x40, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCAS is", 0x1011, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SAIR is", 0x4a000180, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SIRI is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SIRD is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCR0 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCR1 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PRIT is", 0xa307, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SECT is", 0x8000, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PSIT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSIT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SYNC is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT0 is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT1 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT2 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT3 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR0 is", 0x3, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR1 is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR2 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR3 is", 0x3, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR4 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR5 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "MAPV is", 0x0, }

A description of each field is commented in the DSDT

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...
Click to expand...
I'll give it a try.
 

Attachments

  • DSDT.dsl.zip
    19.8 KB · Views: 137
shinzon said:
The DSDT.dsl I'm working with is attached.

With ADDM (old ACHI) at 0x40, the output in console is:
Code: 
6/5/15 1:43:04 PM    kernel    ACPIDebug: Version 0.1.2 starting
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "VEID is", 0x8086, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "DEID is", 0x27c5, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCIC is", 0x7, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCIS is", 0x2b0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "RVIR is", 0x2, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PGIR is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCCR is", 0x6, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "BCCR is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PMLT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSVI is", 0x1028, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSDI is", 0x2f4, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCMD is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCNL is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCMD is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCNL is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "LBAR is", 0x1811, }
[B]6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ABAR is", 0x0, }[/B]
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ADDM is", 0x40, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PCAS is", 0x1011, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SAIR is", 0x4a000180, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SIRI is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SIRD is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCR0 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SCR1 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PRIT is", 0xa307, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SECT is", 0x8000, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "PSIT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SSIT is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SYNC is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT0 is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT1 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT2 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "SDT3 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR0 is", 0x3, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR1 is", 0x1, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR2 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR3 is", 0x3, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR4 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "ICR5 is", 0x0, }
6/5/15 1:43:04 PM    kernel    ACPIDebug: { "MAPV is", 0x0, }

A description of each field is commented in the DSDT


I'll give it a try.
Click to expand...

You might want to dump all the values before you start changing things...

Also, only call PINI from one place (best at SATA._INI), not PCI0._INI.
 
More for posterity than anything, but with the SATA region fully scoped with ACPIDebug, here's what I've found so far:

  • 0x40 is the only combination for the SATA mode select field (offset 90h) that will bring up the AHCI controller; I tried them all. Further, the machine never boots in IDE Primary combined mode. In that case, and given ICH8 uses 0x40 for 90h too, one can be assured that 0x40 is setting non-combined mode (the only mode where AHCI works), and enabling the AHCI controller.
  • With 90h set to 0x40, Three things change: the first is the SubClass Code Register field, and second is the DeviceID field, both of which change to indicate the AHCI controller is active per the documentation.
  • The third thing to change is the Programing Interface Register to 0x1. Per the specs, this means that the Controller is in AHCI 1.0 mode.
 
It appears I missed something basic in my testing. While I attempted to use FakePCIID, I never bothered with AHCIPortInjector. With AHCIPortInjector.kext installed, the AHCI driver loads, but it doesn't read my drive, nor does it appear to be attached to the SATA device in IOREG.

Booting from USB:
Code: 
kextstat |grep -y ahci
   57    1 0x3612e000 0x6000     0x5000     com.apple.iokit.IOAHCIFamily (2.0.6) <5 4 3 1>
   58    0 0x3614d000 0x14000    0x13000    com.apple.driver.AppleAHCIPort (2.1.7) <57 14 5 4 3 1>

Code: 
00:1f.2 SATA controller [0106]: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller [8086:27c5] (rev 02) (prog-if 01 [AHCI 1.0])
    Subsystem: Dell Unknown device [1028:02f4]
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19
    I/O ports at 1808
    I/O ports at 18a8
    I/O ports at 18a0
    I/O ports at 18ac
    I/O ports at 1810
    Memory at fed1a000 (32-bit, non-prefetchable)
    Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
    Capabilities: [70] Power Management version 2

I still don't understand why I need to inject my own device-id to get the kext to load... but hey, I wont look a gift horse in the mouth.

So the question now becomes, why, with AHCIPort loaded, wont it detect my drive?

Edit: could it be an IRQ conflict? IRQ19 is currently shared with SMBus and UHCI.

edit 2: to answer a question I had earlier in the thread, lspci can dump the config space

Code: 
$ lspci -xxx
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00: 86 80 c5 27 07 00 b0 02 02 01 06 01 00 00 00 00
10: 09 18 00 00 19 18 00 00 11 18 00 00 1d 18 00 00
20: a1 18 00 00 00 a0 d1 fe 00 00 00 00 28 10 f4 02
30: 00 00 00 00 80 00 00 00 00 00 00 00 13 02 00 00
40: 07 a3 00 80 00 00 00 00 01 00 01 00 00 00 00 00
50: 00 00 00 00 13 30 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 01 a8 02 40 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 70 00 00 00 00 e0 fe 94 40 00 00 00 00 00 00
90: 40 00 11 10 80 01 00 0a 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 12 00 10 00 48 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

The first thing I noticed is that ABAR, offset 24h-27h is not 0x0. That means it IS the driver's responsibility to populate it.

From a MacbookPro2,1
Code: 
00: 86 80 c5 27 07 00 b0 02 02 01 06 01 00 00 00 00
10: c9 20 00 00 ed 20 00 00 c1 20 00 00 e9 20 00 00
20: a1 20 00 00 00 50 44 50 00 00 00 00 86 80 70 72
30: 00 00 00 00 80 00 00 00 00 00 00 00 13 02 00 00
40: 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 01 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 70 00 00 00 00 e0 fe 92 40 00 00 00 00 00 00
90: 40 00 44 10 80 01 80 5b 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00
 
The 'lspci -xxx' is a neat trick to dump PCI config space via Linux on a Mac...

Nice..
 
hi, there. i got samsung np-q35 with ich7m and no ahci option to enable it in bios. i tried so many fixes, patches, etc, but no success.
i tried to modify DSDT like you do, but with no result.
my last attempt was - pciutils builded for dos, few batch files, that you told in post before, and then grub4dos chainloading windows 7. all i can said that it's just another deadend. the only thing i've noticed - is when chainloading after setpci mods system not completely stuck. i left my notebook with blinkin cursor and take a walk to buy some beer. and when i came back - whooa! the system continues loading, but very very slowly. approximately 1 hour needed for grub to scan devices and fallback. and if before setpci mods my hdd is seen by grub, dos, etc, after setpci and grub - no drives at all.
and almost after every change made by setpci an error "controller seen twice. firmware bug" appears.
i'm almost totally new in DSDT editing, but maybe i can be useful for this research.

and on my hp4530s in ahci mode "setpci -s 0:1f.2 90.b=40" puts controller in IDE mode. start thinkin that 40 is not AHCI mode, maybe it's combined?
 
shinzon said:
Do you think the reason ABAR is set in Windows is because the device driver is actually supposed to set this memory range? The Windows driver might set for both LegIDE and AHCI even if it doesn't support it, whereas the Apple driver doesn't load so it doesn't have a chance to set ABAR.
Click to expand...

NonAhciCapable2.png

this mine from PciScope. As you no ABAR. And by the way in my bios i found oprom with ssdt contains description of SATA ports. And some portion of init code, i guess...
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top