Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About joevt

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender
  1. ThunderBolt Drivers

    I found some relevant code in PlatformInit of the BIOS. There's a function that reads the Setup NVRAM variable to a local stack variable and extracts some of the Thunderbolt settings. Since it's a local variable, the offsets in the assembly are stack relative, not SYSTEM_CONFIGURATION struct relative so you can't search for settings offsets that way which means you have to look at every function manually to see if they use the settings that you're interested in. I suppose it's possible to create a script to find functions that read the Setup NVRAM variable, finds the stack address used for the destination, then scans the entire function for specific offsets that we want. That is nearly impossible because the stack pointer can change often inside a function (arguments that are pushed on the stack for a function call might not be immediately popped). I used Hopper to disassemble the files created by UEFIExtract. Hopper doesn't support TE image files so I wrote a script to convert those to PE (included below). Hopper can keep track of stack pointer changes, so it knows for each instruction what a stack relative address is pointing to. The nearly impossible script is more possible with the disassembly from Hopper. Image PlatformInit is part of stage pei of UEFI. They use a struct EFI_PEI_SERVICES to call useful functions. A pointer to this is stored in field Ps of struct PEI_CORE_INSTANCE. Function SetPeiServicesTablePointer is used to store a pointer to field Ps of struct PEI_CORE_INSTANCE to the 4 bytes immediately preceding the Interrupt Descriptor Table. The sidt instruction is used to get the address of the IDT and the lidt instruction is used to set it. This is all setup by source file PeiMain.c of PeiCore. PlatformInit has many functions that use GetPeiServicesTablePointer to get a pointer to the pointer to EFI_PEI_SERVICES. These are from source file PeiServicesLib.c I think some of it might be setting up some PCD stuff (EDKII Platform Configuration Database Entries) using settings from NVRAM. That might be interesting. Some of the UEFI code affects the ACPI code (for example, when Thunderbolt is enabled, XTBT is renamed _E23 where the Edge-Triggered GPE number (23) is calculated by the code based on one of the settings). I don't see an easy way to import types into Hopper (entering 3000 settings fields in a struct by hand will take forever and have errors that are not easily fixable with the current UI). I've included the scripts I used for searching (produces easier to use results (hierarchical with full path) than UefiTool.app). #========================================================================================= # Extract some downloaded bios files cd ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7 ~/Downloads/UEFIstuff/UEFITool-master/build-uefiextract-Desktop_Qt_5_10_1_clang_64bit-Debug/UEFIExtract ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7/Z170XG7.22j #========================================================================================= # Get a list of type and subtype combinations cd ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7/Z170XG7.22j.dump find . -name info.txt -exec printf "sed -nE '1,2 p' '%s' | tr '\\\\n' ' ' ; echo\n" {} \; | sh | sort -u #========================================================================================= # Find body.bin files containing the Setup var name and guid cd ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7/Z170XG7.22j.dump search() { grep -q "$1" /tmp/efihex.txt } IFS=$'\n' guid='EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9' guidhex=$(echo -n "${guid:6:2} ${guid:4:2} ${guid:2:2} ${guid:0:2} ${guid:11:2} ${guid:9:2} ${guid:16:2} ${guid:14:2} ${guid:19:2} ${guid:21:2} ${guid:24:2} ${guid:26:2} ${guid:28:2} ${guid:30:2} ${guid:32:2} ${guid:34:2}" | tr '[:upper:]' '[:lower:]') ## 43 d6 87 ec a4 eb b5 4b a1 e5 3f 3e 36 b2 0d a9 setuphex=$(printf "Setup\000" | iconv -f UTF-8 -t UTF-16LE | xxd -ps -c1 | tr '\n' ' ') # 53 00 65 00 74 00 75 00 70 00 00 00 pat1='^Type: File .*' pat2='^Type: Section .*' for theinfo in $(find . -name info.txt); do thetype=$(sed -nE '1,2 p' $theinfo | tr '\n' ' ') if [[ $thetype =~ $pat1 || $thetype =~ $pat2 ]]; then thebody=${theinfo/info.txt/body.bin} if [ -f $thebody ]; then xxd -ps -c1 $thebody | tr '\n' ' ' > /tmp/efihex.txt if search "$guidhex"; then if search "$setuphex"; then echo $thetype $theinfo #echo "# found" fi fi fi fi done #========================================================================================= # Find body.bin files containing the Setup var name and guid and XTBT text (used in ACPI) cd ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7/Z170XG7.22j.dump search() { grep -q "$1" /tmp/efihex.txt } IFS=$'\n' guid='EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9' guidhex=$(echo -n "${guid:6:2} ${guid:4:2} ${guid:2:2} ${guid:0:2} ${guid:11:2} ${guid:9:2} ${guid:16:2} ${guid:14:2} ${guid:19:2} ${guid:21:2} ${guid:24:2} ${guid:26:2} ${guid:28:2} ${guid:30:2} ${guid:32:2} ${guid:34:2}" | tr '[:upper:]' '[:lower:]') ## 43 d6 87 ec a4 eb b5 4b a1 e5 3f 3e 36 b2 0d a9 XTBThex=$(printf "TBT" | xxd -ps -c1 | tr '\n' ' ') # 53 00 65 00 74 00 75 00 70 00 00 00 #thunderboltSupportHex="53 04" #0x453 #thunderboltPcieSupportHex="5a 04" #0x45A #thunderboltUsbSupportHex="5c 04" #0x45C pat1='^Type: File .*' pat2='^Type: Section .*' for theinfo in $(find . -name info.txt); do thetype=$(sed -nE '1,2 p' $theinfo | tr '\n' ' ') if [[ $thetype =~ $pat1 || $thetype =~ $pat2 ]]; then thebody=${theinfo/info.txt/body.bin} if [ -f $thebody ]; then xxd -ps -c1 $thebody | tr '\n' ' ' > /tmp/efihex.txt if search "$guidhex"; then if search "$setuphex"; then if search "$XTBThex"; then echo $thetype $theinfo #echo "# found" fi fi fi fi fi done #========================================================================================= # Convert all TE image files to PE so they can be disassembled by Hopper cd ~/Downloads/UEFIstuff/UEFIbios/GA-Z170X-Gaming_7/Z170XG7.22j.dump ConvertTEtoPE() { theTEFile="$1" thePEFile=${theTEFile/.bin/.pe} teHeader=$(dd if="${theTEFile}" bs=40 count=1 2> /dev/null | xxd -ps -c40) TEsignature=${teHeader:0:4} # VZ TEmachine=${teHeader:4:4} TEnumberOfSections=${teHeader:8:2} TEsubsystem=${teHeader:10:2} # 11 = EFI driver with boot services. TEstrippedSize=$((0x${teHeader:14:2}${teHeader:12:2})) TEaddressOfEntryPoint=${teHeader:16:8} # pointer to the entry point function, relative to the image base address TEbaseOfCode=${teHeader:24:8} TEimageBase=${teHeader:32:16} TEreloc=${teHeader:48:16} TEdebug=${teHeader:64:16} if [[ $TEsignature == 565a ]]; then TEsections="$(dd if="${theTEFile}" bs=40 skip=1 count=0x$TEnumberOfSections 2> /dev/null | xxd -ps -c40)" PEsizeOfCode=0 PEsizeOfInitializedData=0 IFS=$'\n' for theSection in $TEsections; do if [[ $theSection =~ ^(2e7465787400.{68})$ ]]; then PEsizeOfCode=$(($PEsizeOfCode + 0x${theSection:38:2}${theSection:36:2}${theSection:34:2}${theSection:32:2})) else PEsizeOfInitializedData=$(($PEsizeOfInitializedData + 0x${theSection:38:2}${theSection:36:2}${theSection:34:2}${theSection:32:2})) fi done PEsizes=00000000000000000000000000000000 if [[ $TEmachine == 4c01 ]]; then PEoptionalHeaderSize=e0 PEmagic=0b01 PEimageBase=00000000${TEimageBase:0:8} elif [[ $TEmachine == 6486 ]]; then PEoptionalHeaderSize=f0 PEmagic=0b02 PEimageBase=$TEimageBase PEsizes=$PEsizes$PEsizes else echo "# bad TE machine: $TEmachine" return 1 fi PEdosStub=4d5a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 PEheader=50450000${TEmachine}${TEnumberOfSections}00000000000000000000000000${PEoptionalHeaderSize}002220 sizeOfTEFile=$(wc -c < $theTEFile) peSizeOfImage=$(($sizeOfTEFile - 40 + $TEstrippedSize)) peSizeOfHeaders=$(($TEstrippedSize + 40 * 0x$TEnumberOfSections)) peHeaderOffset=$(($TEstrippedSize - 0x$PEoptionalHeaderSize - ${#PEheader}/2)) peSizeOfImageHex=$( printf "%08x" $peSizeOfImage | sed -E "s/(..)(..)(..)(..)/\4\3\2\1/g") peSizeOfHeadersHex=$( printf "%08x" $peSizeOfHeaders | sed -E "s/(..)(..)(..)(..)/\4\3\2\1/g") peHeaderOffsetHex=$( printf "%08x" $peHeaderOffset | sed -E "s/(..)(..)(..)(..)/\4\3\2\1/g") PEsizeOfCodeHex=$( printf "%08x" $PEsizeOfCode | sed -E "s/(..)(..)(..)(..)/\4\3\2\1/g") PEsizeOfInitializedDataHex=$(printf "%08x" $PEsizeOfInitializedData | sed -E "s/(..)(..)(..)(..)/\4\3\2\1/g") PEoptionalHeader=${PEmagic}0900${PEsizeOfCodeHex}${PEsizeOfInitializedDataHex}00000000${TEaddressOfEntryPoint}${TEbaseOfCode}${PEimageBase}200000002000000000000000000000000000000000000000${peSizeOfImageHex}${peSizeOfHeadersHex}00000000${TEsubsystem}000000${PEsizes}000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000${TEreloc}${TEdebug}000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ( echo -n ${PEdosStub}${peHeaderOffsetHex}$(seq -f '00' -s '' $(($peHeaderOffset - ${#PEdosStub}/2 - 4 )))${PEheader}${PEoptionalHeader} | xxd -ps -r dd if="${theTEFile}" bs=1 skip=40 2> /dev/null ) > "$thePEFile" else echo "# bad TE signature: $TEsignature" return 1 fi } IFS=$'\n' pat1='^Type: Section Subtype: TE image ' for theinfo in $(find . -name info.txt); do thetype=$(sed -nE '1,2 p' $theinfo | tr '\n' ' ') if [[ $thetype =~ $pat1 ]]; then thebody=${theinfo/info.txt/body.bin} if [ -f $thebody ]; then echo "#" $thebody ConvertTEtoPE $thebody fi fi done open -a /Applications/Hopper\ Disassembler\ v4.app ."/3 BIOS region/4 8C8CE578-8A3D-4F1C-9935-896185C32DD3/0 PeiBoardConfigInit/1 TE image section/body.pe" open -a /Applications/Hopper\ Disassembler\ v4.app ."/3 BIOS region/5 8C8CE578-8A3D-4F1C-9935-896185C32DD3/1 RomLayoutPei/1 TE image section/body.pe" open -a /Applications/Hopper\ Disassembler\ v4.app ."/3 BIOS region/5 8C8CE578-8A3D-4F1C-9935-896185C32DD3/2 PeiCore/0 TE image section/body.pe" #========================================================================================= # Utility function to convert a physical address to a PCIe bus device function register PCIFunctionFromAddress() { # baseAddress and baseBus come from ACPI data table having signature MCFG adr=$1 baseAddress=0xF0000000 baseBus=0 pciAdr=$((adr - baseAddress)) printf "# %08X = %02X:%02X.%X -> %X\n" $adr $(((pciAdr >> 20 & 0xFF) + baseBus)) $((pciAdr >> 15 &0x1F)) $((pciAdr >> 12 & 7)) $((pciAdr & 0xFFF)) } PCIFunctionFromAddress 0xF7FFFFFF # F7FFFFFF = 7F:1F.7 -> FFF #=========================================================================================
  2. ThunderBolt Drivers

    I took a couple hours to look at using UEFITool (Mac or Windows) and Universal-IFR-Extractor (Windows). It's quite simple to get the IFR information from a bios file. I've tried Asus Z370, X299, and Gigabyte Z170 BIOS files. They all contain firmwares from AMI and therefore have many of the same Thunderbolt related variables stored in the Setup NVRAM variable at various offsets. Many of the variables are not presented to the user in BIOS. Here's the list from ASUS Z370 (more info such as defaults and options are in the IFR): 0448 One Of: Thunderbolt(TM) Support 0449 Checkbox: Wake From Thunderbolt(TM) Devices 044F One Of: Thunderbolt(TM) PCIe Support 0451 One Of: Thunderbolt Usb Support 0452 One Of: Thunderbolt Boot Support 0455 One Of: Thunderbolt(TM) PCIe Cache-line Size 0456 Checkbox: GPIO3 Force Pwr 0457 Numeric: Wait time in ms after applying Force Pwr 0459 One Of: Security Level 045A One Of: Call pre boot Smi handler 0468 Numeric: Reserve mem per phy slot 046A Numeric: Reserve P mem per phy slot 046C Numeric: Reserve IO per phy slot 0470 Checkbox: Native OS Hot Plug 0471 One Of: SW SMI on TBT hot-plug 0472 One Of: GPIO filter 0473 One Of: ACPI Notify on TBT Hot-plug 0474 One Of: MSI enabled in FADT 0475 Numeric: AIC Location 0476 One Of: Enable CLK REQ 0477 One Of: Enable ASPM 0478 One Of: Enable LTR 0479 One Of: TBT Host Router 047A One Of: AIC Location Group 047B One Of: AIC Location 047C One Of: AIC Location 047D Numeric: Extra Bus Reserved 047E Numeric: Reseved Memory 0480 Numeric: Reserved I/O 0481 Numeric: Memory Alignment 0482 Numeric: Reserved PMemory 0484 Numeric: PMemory Alignment 0485 One Of: Skip PCI enumeration 0486 One Of: Skip PCI OptionRom 0487 One Of: Skip PCI Interrupt Assignment 0488 One Of: ACPI Removal Object Suppport 0489 One Of: Alpine Ridge Workaround Select 048A One Of: AR XHCI Host Pre-wake 048B Numeric: AR XHCI Host Active LTR 048F Numeric: AR XHCI Host High LTR 0493 Numeric: AR XHCI Host Medium LTR 0497 Numeric: AR XHCI Host Low LTR There are almost 3000 other variables in the setup configuration. The next step is to find the code that uses those variables, but I'm not sure how that gets accessed. There are occurrences of "Setup" and "EC87D643-EBA4-4bb5-A1E5-3F3E36B20DA9" (SYSTEM_CONFIGURATION_GUID) in edk2 which may give a clue.
  3. mac-pixel-clock-patch-V2 has a new patch for 10.13.3. Can we get a new CoreDisplayFixup? I'm missing 4K 60 Hz from my Nvidia's HDMI 2.0 port.
  4. Not an error message. https://www.tonymacx86.com/threads/guide-10-11-usb-changes-and-solutions.173616/page-255#post-1578710 If you're having a problem, then it's something else.
  5. ThunderBolt Drivers

    Do we need hot plug? Can we manually tell macOS to rescan the PCI bus? First, setup some boot arguments. sudo boot-args="debug=0x144 pci=0x45" "debug=0x144" is required by pciutils (lspci, setpci). I use the version at https://github.com/gittup/pciutils(just use "sudo make install"). There is a version of lspci that uses it's own kernel extension instead of Apple's AppleACPIPlatformExpert so that it doesn't require sudo or the debug flags, but that version is out of date (doesn't show PCI Express 3.0 information). I don't know exactly which flags pciutils requires because AppleACPIPlatformExpert is not open source, but 0x144 is the sugestion given in the error message if you don't have the flags. The debug= flags are listed at https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/kern/debug.h.auto.html and described at https://developer.apple.com/library/content/documentation/Darwin/Conceptual/KernelProgramming/build/build.html 0x144 is DB_LOG_PI_SCRN + DB_ARP + DB_NMI The pci= flags are listed at https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-320.1.1/IOKit/pci/IOPCIConfigurator.h.auto.html Use pci= to set flags and npci= to clear flags. I think we only care about kIOPCIConfiguratorIOLog. KPrintf is for serial port or firewire kprintf, but you can set some of the "debug=" flags to make IOLog also go to kprintf (I think one or both of DB_PRT and DB_KPRT). The io= flags are listed at https://opensource.apple.com/source/xnu/xnu-4570.1.46/iokit/IOKit/IOKitDebug.h.auto.html You can find more flags by googling PE_parse_boot_argn site:opensource.apple.comYou can find usage of flags be googling "PE_parse_boot_argn pci" site:opensource.apple.comMaybe IOThunderboltFamily.kext has it's own flags? You would have to disassemble it and look for calls to PE_parse_boot_argn. Once you enable the kIOPCIConfiguratorIOLog flag, restart the computer. Open Terminal.app, and start streaming the log using a command like this: log stream --style syslog --predicate 'not senderImagePath ENDSWITH "/IOUSBHostFamily" and processImagePath ENDSWITH "/kernel"' Execute that command. press Command-K to clear the Terminal window before you do something that you want to log. Unplug a Thunderbolt device. Copy the contents of the terminal window to a text file. Connect a Thunderbolt device. Copy the contents of the terminal window to another text file. The results using a Mac with Thunderbolt should give a clue how a workaround for hot plug may be created. The IOPCIFamily is open source. Hopefully we don't need to go into the IOThunderboltFamily which is not open source. I've attached results from a Thunderbolt 2 MacBook Pro which has a Thunderbolt 1 FireWire adapter and a Thunderbolt 1 Ethernet adapter. So I think you could make a kext with a user client that can be called from a user space command line app to force a PCI rescan. I suppose you could use the setpci command to see if there is actually anything to scan (vendor id and device id should not be FFFF for new devices). First you must set the primary bus, secondary bus, and subordinate bus. This won't work if Thunderbolt requires some other setup before new devices are presented on the bus. setpci only works for pci configuration space (4096 bytes of registers). I think a kext with a user client that can read and write to different base registers of a pci device may be helpful. With such a kext, I would make a script to read / set the registers described by the Linux drivers (firmware versions, security level, etc.) to better understand its workings. I've attached a script that uses setpci to dump the pci device tree. It's similar to the "lspci -t -vnn" command except it shows information about the upstream and downstream switches and the max and current link speed, link width (g1 = gen 1, etc.). The included example output shows a OWC Thunderbolt 2 Dock connected to a OWC Thunderbolt 3 Dock. Sometimes, if they don't appear in macOS (the NHI may not appear either), I boot into Windows, unplug the cable, reconnect it, make sure they appear in Windows Device Manager or the Intel Thunderbolt sofware list of devices, and restart into MacOS. Another thing that needs investigation, besides ACPI is UEFI. Use UEFITool to get UEFI from a firmware update. Use Universal-IFR-Extractor to get the list of Thunderbolt variables in the forms packages. Then search the UEFI for code that uses those variables. This probably involves searching UEFI for the GUIDs of the involved protocols. It might be interesting to add Internal Form Represention (IFR) code to Clover to dump such information (like F4 does for DSDT and SSDT). I don't know enough about the Human Interface Infrastructure Specification (HII) to know if that's possible. MacBook Pro (Retina, 15-inch, Mid 2015).zip pcitree.zip
  6. Clover General discussion

    You can add more PCI configuration logging by adding pci=1 to boot arguments in Clover config.plist. Maybe it will show what device is causing the problem? The pci= flags are listed at https://opensource.apple.com/source/IOPCIFamily/IOPCIFamily-320.1.1/IOKit/pci/IOPCIConfigurator.h.auto.htmlPCI logging might be useful to get Thunderbolt probe (for hot plug) in the future.
  7. Clover General discussion

    Mount point names are not the same as volume names. A mount point can be named anything (doesn't need to match the file system volume name) and be anywhere (doesn't need to be in the /Volumes folder). Look at the mount command, and the various file system specific versions like mount_msdos. "diskutil info /dev/disk1s2" will tell you the volume name, mount point name, and device name for partition 2 of disk 1.
  8. VoodooHDA 2.9.0

    You double click the prefpane and the OS will move it to the correct location for you.
  9. Clover General discussion

    Since Clover is responsible for loading the driver, is it possible for it to redirect console output to a null device during that time? Maybe a buffer that could be added to the debug log?
  10. Clover General discussion

    I tested SavageAUS's build 4194 and compared my debug log before and after. The output for ScanSPD is unchanged for me because my ram is DDR4 with vendor "G Skill Intl" which is from bank 4 in memvendors.h, which has odd parity bit set to 0, so it doesn't have the problem that vendors from bank 0, 3, 5, 6, and 9 have. truesoldier should see an improvement in ScanSPD output because he has "Geil" ram (bank 3) which has the odd parity bit set.
  11. I started working on this but I haven't had time to finish it. Additional features: - Match on any property using regular expressions (slot, name, path, class, id, bus, device, function, etc...). Maybe start with a simple string search first, then add regular expression method later. - Match on any handle with a device path protocol - not just PCI devices. For example, ACPI devices such as UART. - Allow more compact property specification <key>thekey</key><data>thedata</data> instead of silly <key>key</key><string>thekey</string><key>data</key><data>thedata</data> - Allow all methods of setting properties to work with each other: Inject, AddProperties, NoDefaultProperties, Arbitrary, Properties. - Reuse code for each method. Combine similar code into a single function. Create a device loop function that can be given different call-back functions. - Code changes should not require changes to config.plist, unless config.plist expects silly side effects like where one method doesn't do anything when another method is specified. Because why would you enter info that you don't expect to be acted upon? - Allow specify device path for devices that may not actually exist. - Parse binary properties (<key>Properties</key>) if any other method of defining properties is used, so that conflicts can be reported. It shouldn't be necessary to parse binary properties otherwise but it may be useful for debugging. - When adding a property, include a "Source" field which indicates what part of Clover is adding the property. - Report an error if an attempt to add the same property to a device occurs, so user can know when Inject conflicts with AddProperties for example (using the Source field to report the origin of the original setting). - The code will build a database of device path, property name/data information. The database is compiled into binary properties before booting into macOS. - Before booting macOS, dump the list of device paths, properties and their Source to the log.
  12. Clover General discussion

    Looks fine except for the bank number for the vendor. The bank number is 0x83 but the code expects 3 because it does not take into account that the most significant bit is an odd parity bit. The code in file spd.c for DDR3 masks off the parity bit. Maybe the DDR4 code should do the same. Maybe both the DDR3 and DDR4 code should check the parity first and at least give an error message if it's wrong, then mask off the parity bit: UINT8 parity = bank; UINT8 testbit = bank; for (i=6; i >= 0; i--) { parity ^= (testbit <<= 1); } if ( (parity & 0x80) == 0 ) { DBG("Bad parity bank=0x%2X code=0x%2X\n", bank, code); } bank &= 0x7f; Bank 3, code 0x13 is manufacturer "Geil". Is that correct for your ram? How does this SPD data compare to the "Get Smbios" part of the log? Is there a valid manufacturer name there?
  13. Nvidia audio is probably off topic here but it is an HDA device, so it relates to AppleHDA, VoodooHDA, AppleALC. There are some interesting things to note: 1) Nvidia graphics card (Maxwell or Pascal) may have 5 ports, but only 4 can be connected to a display. The 5th display must be disabled. Windows can detect all 5 and you choose which display to disable. 2) Nvidia graphics cards can output audio to any of the 5 ports, up to 4. Windows Nvidia driver let's you select which outputs to activate. It can get confused when you plug in 4 or 5 displays though. Ubuntu seems to handle Nvidia audio ok, but some of that is not open source. There might be some info in the alsa driver code anyway. The problem is, there's no documentation describing how to connect one of the 4 audio outputs to one of the 5 ports. The information from the HDA gives no hint how that is done. I don't think the Mac drivers handle this, so some ports might not show an audio device in that case.
  14. It seems to work well. I'm using layout 4 which has Digital Out, Front, C/Sub, Rear, and Internal Mic. The Mic is switched to Front or Rear, C/Sub is disabled or enabled. Front Mic seems to enable Front HP and Front Mic, disable C/Sub and Rear Mic. Actually, it seems front Mic is also getting audio from one of the Outputs if I have the output selected (I think it's the C/Sub one). If I select a different output, then all the input comes from the microphone. That could be a feature, if you want to record an output. Front HP seems to enable Front HP and Rear Mic, disable C/Sub and Front Mic. C/Sub seems to enable C/Sub and Rear Mic, disable Rear HP, Front HP, Front Mic. The app quits after 10 seconds or when you click a button. It should probably not quit. A feature I would like to see in AppleALC is to be able to rename the inputs and outputs. This might require more patches to AppleHDA. Then you're app can also rename the inputs or outputs depending on the button pressed. I can create aggregate devices with custom names, but the Sound preferences panel will only show 9 devices and I can't hide the real devices. Maybe we need an app to show the layout like the Microsoft "High Definition Audio (HD Audio) tool" does (with better graphing), to understand the options and the results.
  15. Clover General discussion

    All the information used by Startup Disk is available to Clover, so it should be possible to add code to Clover and or it's scripts to do that if it doesn't already. .disk_label is a graphics image of the text displayed under the disk icon in the Startup Manager UI (an EFI program on Macs that is displayed when you hold the option key at startup). .disk_label_2x is the same thing for retina displays. The bless command does some of the same things as the Startup Disk preferences panel, including creating those graphics images. The bless command affects some nvram variables. It also affects some information in the HFS header of an HFS formatted disk. nvram -p echo "===============================================================================" bless --verbose --getboot echo "===============================================================================" bless --verbose --info echo "===============================================================================" ioreg -w 0 -n AppleEFINVRAM | sed -n -E "/^[ \|]+[ ]+(\".*)$/s//\1/p;" efi-boot-device is the xml representation of the boot device. efi-boot-device-data is a binary representation (using EFI device path protocol). If this is an HFS disk, then the HFS header has the id of the boot folder and the id of the efi boot file. bless --verbose will tell you which EFI boot variable that uses the efi-boot-device. GUID 8BE4DF61-93CA-11D2-AA0D-00E098032B8C is for the efi owned set of nvram variables, and Boot0080 is the name of the nvram variable in that set containing the EFI device path of the boot device. Apple owned nvram variables will use a different guid. If you select a Windows disk in Startup Disk preferences panel, and it is legacy (BIOS) instead of EFI, then the efi-boot-device-data will be the path of an EFI program used for booting BootCamp (an image file in EFI). The BootCampHD nvram variable will then be the device path of the disk that should have it's MBR boot code executed by Apple's BIOS boot loader. efi-boot-device-data can also be a path to an efi program like Clover.