Some of you may want to have this kind of data, so here it is:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)</key> <dict> <key>TBTDPLowToHigh</key> <data> AQAAAA== </data> <key>TBTFlags</key> <data> AQAAAA== </data> <key>ThunderboltConfig</key> <data> AAL//wQABAIBABAABAICAAUABAIBABIABAICAAIAAQA= </data> <key>ThunderboltDROM</key> <data> IwAMkZU2SQEACptg+gFeAAEADAABAAiBgAKAAAAACIKQAYAAAAAIg4AEgAEA AAiEkAOAAQAACIUAAAAAAAADhiADh4ACyAWJUAAABYpQAAACyw0BQXBwbGUg SW5jLgAMAk1hY2ludG9zaAA= </data> <key>ThunderboltUUID</key> <data> mMXy78Caelu3mBXl2TmnxA== </data> <key>linkDetails</key> <data> CAAAAAMAAAA= </data> <key>pathcr</key> <data> BAAAAAAAAAAAAAcAEAAQAAUAAAAAAAAAAAAHABAAEAABAAAABQAOAA4AAAAA AAAAAgAAAAAAAAAAAAIAAgABAAMAAAAAAAAAAAAHAAIAAQA= </data> <key>sscOffset</key> <data> AAc= </data> </dict> <key>PciRoot(0x0)/Pci(0x1f,0x3)</key> <dict> <key>MaximumBootBeepVolume</key> <data> 8Q== </data> <key>MaximumBootBeepVolumeAlt</key> <data> 8Q== </data> <key>PinConfigurations</key> <data> MJCrAAABpqAQARCQEQEQkCBAKwA= </data> <key>layout-id</key> <data> MwAAAA== </data> <key>multiEQDevicePresence</key> <data> DAABAA== </data> </dict> <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>AAPL,Gfx324</key> <data> AQAAAA== </data> <key>AAPL,GfxYTile</key> <data> AQAAAA== </data> <key>AAPL,ig-platform-id</key> <data> AgAmGQ== </data> <key>AAPL00,PanelCycleDelay</key> <data> +gAAAA== </data> <key>AAPL00,PanelPowerDown</key> <data> PAAAAA== </data> <key>AAPL00,PanelPowerOff</key> <data> EQAAAA== </data> <key>AAPL00,PanelPowerOn</key> <data> GQEAAA== </data> <key>AAPL00,PanelPowerUp</key> <data> MAAAAA== </data> <key>graphic-options</key> <data> DAAAAA== </data> <key>saved-config</key> <data> RwAAAAAAAAAAAAAAAAAAAAAAAwACACYZAGwFaQUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQEBAAYQNKACA0AAAAAAAAAA AAKQbIoPAApABlAAAAAuAAAACAAgACAACABACwgHWgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA </data> </dict> </dict> </plist>
Pike's Universum 
Keep on digging up the Gold ! Just awesome..
Took delivery of 13,2 MBP today (for a client). Putting it through its paces.
Fully maxed out 16/1tb, 3.3 i7 etc.
If you need IOreg etc (frequency vector extrusion?) let me know… And how to it 😉
Great. Please run DarwinDumper on it.
I’m slowly learning, using a Gigabyte X99 with 6950x with the Alpine thunderbolt card. I’m attempting to figure out how to apply the properties via DSM to get OS X to recognize the card. I’m not asking for the answer, but could you do a write up on how to apply these findings, with the thunderbolt keys, from these string formats to the hex addresses in a DSDT? I’m familiar with simple data being added but haven’t had much luck trying to apply these (or any from other systems). I’m also not familiar with the difference of adding a data set to identify a device, versus when it reports “number” and “boolean”. I’ve got a few years of reading, re-reading, and testing, so no rush, I see you’re often quite busy.
Thanks for your forum and contributions, I learn more from your forum than any other because of the way you contribute to people learning and seeking the next answer vs plug and play solutions. It’s helped me.
AFAIK Thunderbolt requires more than just device properties. Some XPS users on InsanelyMac (goodwin_c in particular) are trying to get Thunderbolt 3 hotplugging working on the XPS 9550/9560, with some success. The main issue is communicating with the Internal Connection Manager (firmware [ACPI/SMM] for managing Thunderbolt hotplugging); real Macs do not use the ICM in macOS (but they enable it in Windows) and let the drivers handle everything.
I’m honestly digging into stuff I’m still at the beginning of understanding. Thank you for your IASL work, I’ve learned a lot.
I’ve tested with some patches and tree structures that are out there, including the patches from that thread, though I didn’t know the repositories originated there. We’re looking at similar options. I’ve been able to falsely get items to report over the thunderbolt bus, but no drivers loading. Given the properties that the driver calls for, is it possible to fake these via _DSM to get the driver to latch? Juggling between the PCIe structure of MacBook Air 6,2, MBP 14,3, Al3xtjames’s patch and driver, and that 9550 method. A part I am having a hard time grasping, since I’m learning the coding as I go, is easily being able to identify what specifically is needed as the property to take the characteristics from the drivers and firmware and translate those to what I would need to characterize in ASL.
I’m a noob,so please correct me if my language or understanding is incorrect. I do have a pretty smooth DSDT that I’ve compiled thanks to this site and your posts, and it’s the first time I’ve done that, so I’m slowly understanding it. Thank you.
(Pike, if I am not supposed to link to other sites, please let me know. I’m new to trying to adhere to customary digital courtesies. I also hope this is not considered derailing the topic, I just wanted to begin to answer my own questions for anyone else that might find themselves here due to what I asked. Thank you.)
https://reverse.put.as/2016/06/25/apple-efi-firmware-passwords-and-the-scbo-myth/
This appears to be a good write up that I’ll be digesting the next few days. This is the type of linear conversion of data that I am attempting to understand better.
The end state I’m hoping to figure out is how to use information that they have gleaned in implementing linux hot swap with the alpine ridge card using the similar property pulls like the ones mentioned in this thread
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1458252.html
They are pulling the same (apparently to me) information we would pull in to a _DSM to assign characteristics to the card for the OS to bind to. Can this (or some of this) occur at the DSDT level to trick the drivers?
Your first link doesn’t work here. What is it about?
The snippet that I see, by following the second link, shows me that they are reading properties that the Apple driver injected. That is not the same as injecting them from a _DSM method. The driver need to do this.
Apologies, it takes minute to even load here. The title of the article is “Apple EFI firmware passwords and the SCBO myth”. It is about reverse engineering the SCBO file. I’m still reading it, but it deals with disassembling the EFI files, reading the binaries, and tracing the code. You’ve done a lot of write ups on similar topics, it’s just a process that I’m having to read more on to get it to “stick” with me.
Thank you for the clarification on when/where they are reading them from. Specific to the properties listed above in your post. These are loaded at boot? Can these types of properties be incorporated into a _DSM method to grant characteristics?
(Thank you, and please feel free to modify my posts as needed to keep it coherent)