Impossible to be anything else than binary. The field is only two bits in size. Probably they just forgot to add the 'b'.
It is possible, but your proposed code is wrong (Offset specifies a byte-offset).
Correct:
Code:
OperationRegion (SAHC, PCI_Config, 0x90, One) // AHCI
Field (SAHC, ByteAcc, NoLock, Preserve)
{
VMAP,2,
,4,
AHCI,2
}
I don't see where the ACPI spec actually states the bit order, so I'm not sure if it is 7...0 or 0..7.
You'll have to experiment to find out.
If it is 7..0, the order would need to change:
Code:
OperationRegion (SAHC, PCI_Config, 0x90, One) // AHCI
Field (SAHC, ByteAcc, NoLock, Preserve)
{
AHCI,2
,4,
VMAP,2,
}
Thank you for that. I'm finding it much easier to wrap my head around this at the binary level.
Okay, so my options for either field are now either 0x0, 0x1, 0x2, or 0x3.
Using ACPIDebug, I've returned the default values for these fields: they are both 0x0
VMAP 0x0 = Non-Combined
AHCI 0x0 = IDE
Per the specs, to enable the AHCI controller, I want a value of binary 01 (0x1) for AHCI, and I want binary 00 (0x0) for VMAP.
Accounting for the uncertainty on if the bits are ordered 0-7 or 7-0, I have two options to try.
0-7:
Code:
AHCI = 0x1; VMAP = 0x0
OperationRegion (SAHC, PCI_Config, 0x90, One) // AHCI
Field (SAHC, ByteAcc, NoLock, Preserve)
{
VMAP, 2, // 0-7 order
, 4,
AHCI, 2
}
Result: Boot halts at waiting for root device.
PCIDebug returns:
ACPIDebug: { "PINI_AHCI", 0x1, }
ACPIDebug: { "PINI_VMAP", 0x0, }
ACPIDebug: { "PINI_MAPV", 0x0, } Original "MAPV" field
ACPIDebug: { "DSM_AHCI", 0x1, } _DSM attached to SATA
ACPIDebug: { "DSM_VMAP", 0x0, }
ACPIDebug: { "DSM_MAPV", 0x0, }
(the order these are returned seems to suggest that PINI is being called before the _DSM at the end of SATA, as it should be).
7-0: [this would match the order the data was given in the datasheet, but who knows if that means anything]
Code:
AHCI = 0x1; VMAP = 0x0
OperationRegion (SAHC, PCI_Config, 0x90, One) // AHCI
Field (SAHC, ByteAcc, NoLock, Preserve)
{
AHCI, 2, // 7-0 order
, 4,
VMAP, 2
}
Result: Boot halts at waiting for root device.
PCIDebug returns:
ACPIDebug: { "PINI_AHCI", 0x1, }
ACPIDebug: { "PINI_VMAP", 0x0, }
ACPIDebug: { "PINI_MAPV", 0x1, } Original "MAPV" field
ACPIDebug: { "DSM_AHCI", 0x1, } _DSM attached to SATA
ACPIDebug: { "DSM_VMAP", 0x0, }
ACPIDebug: { "DSM_MAPV", 0x1, }
My current method PINI:
Code:
Method (PINI, 0, NotSerialized) // For PCI0/Wake INI
{
Store (0x2, \_SB.PCI0.SATA.VMAP)
Store (0x1, \_SB.PCI0.SATA.AHCI)
\RMDT.P2 ("PINI_AHCI", \_SB.PCI0.SATA.AHCI)
\RMDT.P2 ("PINI_VMAP", \_SB.PCI0.SATA.VMAP)
\RMDT.P2 ("PINI_MAPV", \_SB.PCI0.SATA.MAPV)
}
Given that the Dell MAPV field and my VMAP field match in 0-7 order, that suggests 0-7 is the correct order of the bits.
This seems pretty basic on a binary level, so unless I made an error, to me this suggests that the DSDT code has been fine all along, and OSX is not loading AppleAHCIPort.kext for whatever reason.
Thoughts?
My DSDT set up for 7-0 is attached.