Just confirming, this is the Apple Thunderbolt2 to ethernet adapter, correct?
The Apple Thunderbolt to Gigabit Ethernet Adapter and the Apple Thunderbolt to FireWire Adapter are Thunderbolt 1 adapters. See the attachment at
https://forums.macrumors.com/threads/testing-tb3-aic-with-mp-5-1.2143042/post-27612591 They use the DSL2210 Thunderbolt controller.
@Inqnuam @CaseySJ
Then, I have identify an EFI application named
UTDMUIApp (
Unified Target Disk Mode) used by Apple for Thunderbolt and Firewire, but I don't how I can use it. Maybe called by another application (BootPicker).
I still need to find how I can make an "on-memory" application boot link (like Boot001, Boot080,...) on NVRAM.
View attachment 522869
I have a script that can get and set the Boot#### variables. I've used it to boot the Startup Manager but haven't tried it for Target Disk Mode.
https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28956775
You can try launching it from the UEFI Shell by loading a Firmware Volume File System EFI driver and then executing the Target Disk Mode app from the UEFI Shell command line.
https://forums.macrumors.com/threads/updating-a-mac-pro-s-cpu-microcode.2114187/post-28964173
I've used the Startup Disk preferences panel to get the EFI device path of Boot Camp (BIOS mode) on my Mac Pro 2008 (select a Windows partition, close Startup Disk preferences panel, use
dumpallbootcars to get the path). It seems all Macs use the same GUID for the Boot Camp (BIOS mode) - only the EFI device path of the firmware volume differs between Macs (rEFInd has a list but I suppose it could be modified to find the firmware volume that contains the Boot Camp GUID). Macs that don't have that app need to boot Windows in UEFI mode - in that case the EFI device path would point to the Windows UEFI boot loader.
There's a Target Disk Mode button in Startup Disk preferences but I haven't tried getting the EFI device path that it uses. Maybe it doesn't use an EFI device path or it doesn't write the nvram variable until shutdown. In that case, modify Open Core's NVRAM variable write override code to copy the boot variable to another NVRAM variable. Or maybe use the DriverOrder and Driver#### boot variables to run an efi driver to intercept the variable at startup before it is overwritten (if it can load early enough, and if it is loaded at all before Target Disk Mode starts). If Driver#### loads before TargetDiskMode then it can do stuff like log all of Target Disk Modes EFI calls. Can it log to a disk that is being shared by Target Disk Mode? If not, then you can log to memory of type Runtime Services which should be accessible by macOS (memory map in ioreg?) (because Boot Services memory is unallocated at Exit Boot Services time). But that can't work if you can't get to macOS without restarting or shutting down? In that case you have to log to NVRAM but that space is limited. There's a DumpUefiCalls which I've never used or looked at before. It might do something like what I suggest. Anyway, the idea is to find any other images that are loaded by the Target Disk Mode app (find by GUID).
There exists methods for doing source level debugging in UEFI (OpenCore has a document). This is usually done by running UEFI on a VM (I've done it on a Parallels VM). I don't know if it can be used on a real system. It probably needs a UEFI gdp-remote server or something like that to exist.
