Yosemite and the missing ACPI Tables property

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 (strcmp(tableAlias, "ACPI_20") == 0)
+	Node *acpiTablesNode = DT__AddChild(tableNode, "ACPI Tables");
+	gPlatform.EFI.Nodes.ACPI_Tables = acpiTablesNode;

This adds a new child note called “ACPI Tables” to:


To me that was the most logical place to add it. Here’s how it looks:
New EFI ACPI Table node

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?

18 thoughts on “Yosemite and the missing ACPI Tables property

      • 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.

  1. 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];

  2. 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.

      • 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.

  3. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s