Up until OS X 10.10 (Yosemite) the ACPI table data could be extracted from the ioreg, but that doesn’t work anymore. This sucks if you need to debug say stuff for power management, and that is why I like to propose a possible fix for it. One that hopefully will be implemented in all boot loaders, otherwise it won’t help us much. And here is what I did for RevoBoot:
I changed function addConfigurationTable() in fake_efi.h a little:
+#if (MAKE_TARGET_OS == YOSEMITE)
+if (strcmp(tableAlias, "ACPI_20") == 0)
+{
+ Node *acpiTablesNode = DT__AddChild(tableNode, "ACPI Tables");
+
+ gPlatform.EFI.Nodes.ACPI_Tables = acpiTablesNode;
+}
+#endif
This adds a new child note called “ACPI Tables” to:
IODeviceTree:/efi/configuration-table/8868E871-E4F1-11D3-BC22-0080C73C8881
To me that was the most logical place to add it. Here’s how it looks:
And at the bottom of efi.c I added some lines to add the actual data. That’s all. The next thing that I plan on doing is to check a boot argument, perhaps debug, so that the data will only be there when you need it.
What do you think?
Pike, what is the benefit of getting them via ioreg as opposed to iasl?
iasl can’t – as far as I know – extract tables in OS X (Yosemite) or did I miss some update?
I see. I had no idea because I hadn’t tried it. Do you think this is Apple’s way of preventing us from getting acpi tables from a real Mac? This could be really problematic when some new models come out that only run Yosemite.
There is no need for Apple to leave them in, and thus they removed the ACPI tables from the ioreg dump. And yeah the usual dumps will no longer be sufficient. Darwin dumper and the like will still work, but you can’t go to an Apple store and fire it up. At least not the stores I visit.
Thought you might find this interesting…
Although the tables don’t seem to be visible from IORegistryExplorer in Yosemite, they are still accessible. I noticed that MaciASL could still extract the tables and I had looked at this code before and knew it was getting it essentially from AppleACPIPlatformExpert via CF calls, similar to how you might expect IORegistryExplorer to access them.
Since MaciASL could access it, I decided to add a little feature to patchmatic, which is based on MaciASL. If you use ‘patchmatic -extract’ it will extract all ACPI objects normally seen in IORegistryExplorer under AppleACPIPlatformExpert->ACPI Tables.
You can download it to try it here (and examine the source): https://github.com/RehabMan/OS-X-MaciASL-patchmatic
This is the related code from patchmatic:
void ExtractTables()
{
io_service_t expert;
if ((expert = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching(“AppleACPIPlatformExpert”)))) {
NSDictionary* tableset = (__bridge NSDictionary *)IORegistryEntryCreateCFProperty(expert, CFSTR(“ACPI Tables”), kCFAllocatorDefault, 0);
for (NSString* table in tableset.allKeys) {
////NSPrintF(@”%@\n”, table);
NSData* aml = [tableset objectForKey:table];
if (aml) {
NSMutableString* name = [NSMutableString stringWithString:table];
[name appendString:@”.aml”];
[aml writeToFile:name atomically:false];
}
}
IOObjectRelease(expert);
}
}
Yeah I know. This is currently the best workaround, but I don’t like it. I rather see IASL getting OS X compatible.
By the way. This is my helper program that I use for ssdtPRGen.sh Available from my Github repository today, but people have been testing it for a while now (zipped data incorporated into ssdtPRGen.sh) so I guess that it is time for a public released.
iASL is open source.
That is why we are looking into it 😉
I don’t really think it is worth it, but you could port the code you have in your “helper program” you mention above into iasl.
Oh… I should have made my point clear. No need to modify the bootloader to implement ACPI table extraction in an OS X version of iasl. It can be done already without the bootloader’s help.
The boot loader route was one that restored the missing property/data, without the need of (other) third party (commandline) tools, to get the same ioreg output.
The table extraction is a feature of iasl, but it is currently broken/unsupported in OS X, and that should be fixed.
I am aware of that. I just don’t think it is necessary, given that there are other tools that already accomplish the same task.
The other tools are only there because this feature isn’t working in IASL, otherwise there was no need for the other tools.
The data in ioreg is only useful for diagnosis and automated tool use. For such purposes, there are other solutions. Using a fair bit of wired kernel memory for data which is static and not needed to run the OS is not really appropriate, and probably the reason Apple removed it. Not to mention that injecting it from the bootloader will actually create duplicates of such data, given that we know the data is internal to AppleACPIPlatform.kext (where it is actually needed).
First of all. The ACPI table data is Of course required to run any operating system, and injecting addresses in a boot loader doesn’t duplicate anything but the address itself. That is. When done right. Secondly. It wasn’t Apple who removed it, but Intel. Apple just updated their source code with a more recent version of the upstream source code. And lastly. AppleACPIPlatform.kext is the interpreter. The real “users” are other kexts.
Is it just injecting addresses, or is a copy being made at some point?
You have access to the source for AppleACPIPlatform.kext?
No. No source code, but the AppleACPIPlatform.kext is basically a souped up version of ACPICA.