Updating a Mac (Pro)s CPU Microcode

L4va · Aug 24, 2020

Any update on this? I was also wondering if anyone was able to at least mod the BIOS emulation part of the firmware to keep AHCI enabled, rather than switching the SATA ports to IDE mode?

Also, these are my own thoughts but I personally think that this old machine would be better off with something like coreboot, rather than using Apples trash bodge of a firmware (32bit EFI on a 64bit machine, SATA being IDE when legacy booting, needing an Apple flashed GPU for boot screens, not being able to boot from a USB drive under legacy mode... must I continue?).

joevt · Aug 24, 2020

L4va said:
Any update on this? I was also wondering if anyone was able to at least mod the BIOS emulation part of the firmware to keep AHCI enabled, rather than switching the SATA ports to IDE mode?

Also, these are my own thoughts but I personally think that this old machine would be better off with something like coreboot, rather than using Apples trash bodge of a firmware (32bit EFI on a 64bit machine, SATA being IDE when legacy booting, needing an Apple flashed GPU for boot screens, not being able to boot from a USB drive under legacy mode... must I continue?).

I remember years ago using the MBR modification to enable AHCI for Boot Camp. I don't remember having problems with that. I haven't tried it recently.

I found this thread and wanted to see if I could find the same IFR stuff in my MacPro3,1 ROM:

Code:

#=========================================================================================
# Extract EFI stuff from the MacPro3,1 rom (as returned by DarwinDumper's flashrom)


[[ -d $UEFIstuff/UEFIbios/MacPro3,1 ]] || mkdir $UEFIstuff/UEFIbios/MacPro3,1
cd $UEFIstuff/UEFIbios/MacPro3,1

cp /Volumes/Updates/Misc_Software/rEFIt/DarwinDumper_v2.7.0/DarwinDumperReports/002_2013-04-24_23-16-37_MacPro3,1/DarwinDumper_2.7.0_Apple_X64_ML_joevt/BiosROMDump/biosbackup.rom .
UEFIExtract ./biosbackup.rom
parseVolumeHeader: unknown file system 00000000-0000-0000-0000-000000000000
parsePadFileBody: non-UEFI data found in pad-file

#===================================================================
# Run ifrextract on all PE32 images to see if they contain IFR


filenum=0
IFS=$'\n'
for thefile in $(find . -iname body.bin -ipath '* PE32 image section/*'); do
    ifrextract "$thefile" /tmp/ifr.txt > /tmp/ifrresult.txt
    grep -q "error: Unknown protocol" /tmp/ifrresult.txt && continue
    
    (( filenum++ ))

    echo "================================================================================"
    echo $thefile
    echo setup_ifr_$filenum.txt
    
    cp /tmp/ifr.txt setup_ifr_$filenum.txt
    cp /tmp/ifrresult.txt setup_ifr_$filenum_result.txt
    
    perl -e '
        sub onevar {
            my $setting = $_[0];
            my $var = $_[1];
            print ( "0x" . ( ("00000000" . $var) =~ s|^0*([0-9A-F]{8})|$1|r ) . " " . $thepath . "\\" . $setting )
        }

        $thepath="";
        while (<>) {
               if ( /0x[0-9A-F]+\s+Form Set: (.*) {[0-9A-F ]+}/ ) { $thepath = $thepath . "\\" . $1 }
            elsif ( /0x[0-9A-F]+\s+Form: (.*), Form ID: 0x([0-9A-F]+) {[0-9A-F ]+}/ ) { $thepath = $thepath . "\\" . $1 }
            elsif ( /0x[0-9A-F]+\s+End Form {[0-9A-F ]+}/ ) { $thepath =~ s|^(.*)\\[^\\]*$|$1| }
            elsif ( /0x[0-9A-F]+\s+End Form Set {[0-9A-F ]+}/ ) { $thepath =~ s|^(.*)\\[^\\]*$|$1| }
            elsif ( /0x[0-9A-F]+\s+Setting: (.*), Variable: 0x([0-9A-F]+\[[^]]+\]) {[0-9A-F ]+}/ ) {
                onevar($1, $2);
                $options = "";
            }
            elsif ( /0x[0-9A-F]+\s+(\w+): (.*), Variable: 0x([0-9A-F]+\[[^]]+\]) {[0-9A-F ]+}/ ) {
                onevar($2, $3);
                print " ($1)\n"; # Checkbox, Numeric, Password
            }
            elsif ( /0x[0-9A-F]+\s+(?:Date|Time): (.*), (.*), (.*), Variables: 0x([0-9A-F]+\[[^]]+\]), 0x([0-9A-F]+\[[^]]+\]), 0x([0-9A-F]+\[[^]]+\]) {[0-9A-F ]+}/ ) {
                onevar($1, $4);
                print "\n";
                onevar($2, $5);
                print "\n";
                onevar($3, $6);
                print "\n";
            }
            elsif ( /0x[0-9A-F]+\s+Option: (.*), Value: (0x[0-9A-F]+) {[0-9A-F ]+}/ ) { 
                $option = $1;
                $val = $2 =~ s|0x([0-9])$|$1|r;
                if ($options eq "") { $options = "(" } else { $options .= "; " }
                $options .= ($val . ":\"" . $option . "\"")
            }
            elsif ( /0x[0-9A-F]+\s+End of Options {[0-9A-F ]+}/ ) { print " " . $options . ")\n" }
        }
    ' < "setup_ifr_$filenum.txt" | sort
done
#===================================================================

================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/100 EF0C99B6-B1D3-4025-9405-BF6A560FE0E0/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_1.txt
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/105 4AA33F45-9000-4E6D-9A26-CBEA50D26B1B/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_2.txt
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/12 A6F691AC-31C8-4444-854C-E2C1A6950F92/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_3.txt
0x00000000[150] \File Explorer\Modify Boot Option Description\Input the description (String)
0x00000000[150] \File Explorer\Modify Driver Option Description\Input the description (String)
0x00000096[254] \File Explorer\Modify Boot Option Description\Input Optional Data (String)
0x00000096[254] \File Explorer\Modify Driver Option Description\Input Optional Data (String)
0x00000195[1] \File Explorer\Modify Driver Option Description\Load Option Force Reconnect (Checkbox)
0x00000209[1] \Boot Maintenance Manager\Change Boot Order\Change Boot Order (Checkbox)
0x00000209[1] \Boot Maintenance Manager\Change Driver Order\Change Driver Order (Checkbox)
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/17 62D171CB-78CD-4480-8678-C6A2A797A8DE/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_4.txt
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/53 EF17CEE7-267D-4BFD-A257-4A6AB3EE8591/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_5.txt
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/88 EBF342FE-B1D3-4EF8-957C-8048606FF670/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/0 PE32 image section/body.bin
setup_ifr_6.txt
================================================================================
./biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/99 056E7324-A718-465B-9A84-228F06642B4F/0 Compressed section/0 FC1BCDB0-7D31-49AA-936A-A4600D9DD083/1 PE32 image section/body.bin
setup_ifr_7.txt
0x00000000[1] \Advanced\Floppy Configuration\Diskette Controller (0:"Disable"; 1:"Enable")
0x00000001[1] \Advanced\Floppy Configuration\Diskette Write Protect (0:"Disable"; 1:"Enable")
0x00000004[1] \Advanced\Peripheral Configuration\Azalia/AC97 Selection (0:"Auto"; 1:"Azalia"; 2:"AC97 Audio and Modem"; 3:"AC97 Audio Only"; 4:"AC97 Modem Only"; 5:"All Disabled")
0x00000005[1] \Advanced\Peripheral Configuration\On-board LAN (0:"Disable"; 1:"Enable")
0x00000006[1] \Advanced\Boot Configuration\Numlock (0:"Off"; 1:"On")
0x00000007[40] \Security\Security\User Password (Password)
0x0000002F[40] \Security\Security\Admin Password (Password)
0x0000002F[40] \Security\Security\Unlock Setup (Password)
0x00000057[1] \Power\Power\After Power Failure (0:"Stay off"; 1:"Last state"; 2:"Power on")
0x00000058[1] \Advanced\Peripheral Configuration\PS2 Port Swap (0:"Disable"; 1:"Enable")
0x00000059[1] \Power\Power\Wake on LAN from S5 (0:"Stay off"; 1:"Power on")
0x0000005A[1] \Advanced\Video Configuration\Active Vedio (0:"Onboard Device"; 1:"PCI(X) Device"; 2:"PCIE Device")
0x0000005B[1] \Boot\Boot\Boot to Network (0:"Disable"; 1:"Enable")
0x00000061[1] \Boot\Boot\Hard Drive Detection (0:"Disable"; 1:"Enable")
0x00000062[1] \Boot\Boot\CD-ROM Drive Detection (0:"Disable"; 1:"Enable")
0x00000063[1] \Boot\Boot\HDD Self Diagnostic (0:"Disable"; 1:"Enable")
0x00000064[1] \Advanced\IDE Configuration\IDE Mode Select (0:"Compatible"; 1:"Enhanced")
0x00000065[1] \Advanced\IDE Configuration\Configure SATA as (0:"IDE"; 1:"RAID"; 2:"AHCI")
0x00000066[1] \Advanced\IDE Configuration\Stagger Spinup Support (0:"Disable"; 1:"Enable")
0x00000068[1] \Advanced\IDE Configuration\SATA Gen (0:"SATA Generation I"; 1:"SATA Generation II")
0x00000069[1] \Advanced\IDE Configuration\PATA/SATA Selection (0:"SATA Only"; 1:"PATA/SATA (PATA as Primary)"; 2:"SATA/PATA (SATA as Primary)"; 3:"PATA Only")
0x0000006A[1] \Processor\Processor\Max CPUID Value Limit (0:"Disable"; 1:"Enable")
0x00000075[1] \Processor\Processor\HyperThreading (0:"Disable"; 1:"Enable")
0x00000076[1] \Blackford Configuration\CPU / FSB Configuration\FSB Bus Parking (0:"Disable"; 1:"Enable")
0x00000077[1] \Blackford Configuration\CPU / FSB Configuration\FSB Enable (1:"FSB-0 Enable, FSB-1 Disabled"; 2:"FSB-0 Disabled, FSB-1 Enable"; 3:"Both FSB-0 and FSB-1 Enabled")
0x00000078[1] \Processor\Processor\Set Processor Ratio (20-1) (Numeric)
0x00000079[1] \Processor\Processor\C1E Enable (0:"Disable"; 1:"Enable")
0x0000007A[1] \Processor\Processor\VT Enable (0:"Disable"; 1:"Enable")
0x0000007B[1] \Processor\Processor\Excution Disable Bit (0:"Disable"; 1:"Enable")
0x0000007C[1] \Processor\Processor\Hardware Prefetcher (0:"Disable"; 1:"Enable")
0x0000007D[1] \Processor\Processor\Adjacent Cache Line Prefetch (0:"Disable"; 1:"Enable")
0x0000007E[1] \Processor\Processor\Clock Spread Spectrum (0:"Disable"; 1:"Enable")
0x0000007F[1] \Blackford Configuration\Memory Interface Configuration\Patrol Scrub (0:"Disable"; 4:"Enable")
0x00000080[1] \Blackford Configuration\Memory Interface Configuration\Demand Scrub (0:"Disable"; 2:"Enable")
0x00000081[1] \Blackford Configuration\Memory Interface Configuration\Snoop Filter Bypass (0:"Enable"; 1:"Disable")
0x00000082[1] \Blackford Configuration\Crystal Beach / DMA Configuration\Crystal Beach / DMA (1:"Enable"; 0:"Disable")
0x00000082[1] \Blackford Configuration\Port 0 Configuration\L1 Entry Hange Protection (1:"Enable"; 0:"Disable")
0x00000084[1] \Blackford Configuration\Port 2 & 3 Configuration\L1 Entry Hange Protection (1:"Enable"; 0:"Disable")
0x00000086[1] \Blackford Configuration\Port 4 & 5 Configuration\L1 Entry Hange Protection (1:"Enable"; 0:"Disable")
0x00000088[1] \Blackford Configuration\Port 6 & 7 Configuration\L1 Entry Hange Protection (1:"Enable"; 0:"Disable")
0x0000008A[1] \Blackford Configuration\Port 0 Configuration\Coalesce Mode and MPS (0:"Coalesce Mode disabled with MPS of 128B"; 1:"Coalesce Mode disabled with MPS of 256B"; 2:"Coalesce Mode enabled with MPS of 128B")
0x0000008C[1] \Blackford Configuration\Port 2 & 3 Configuration\Coalesce Mode and MPS (0:"Coalesce Mode disabled with MPS of 128B"; 1:"Coalesce Mode disabled with MPS of 256B"; 2:"Coalesce Mode enabled with MPS of 128B")
0x0000008E[1] \Blackford Configuration\Port 4 & 5 Configuration\Coalesce Mode and MPS (0:"Coalesce Mode disabled with MPS of 128B"; 1:"Coalesce Mode disabled with MPS of 256B"; 2:"Coalesce Mode enabled with MPS of 128B")
0x00000090[1] \Blackford Configuration\Port 6 & 7 Configuration\Coalesce Mode and MPS (0:"Coalesce Mode disabled with MPS of 128B"; 1:"Coalesce Mode disabled with MPS of 256B"; 2:"Coalesce Mode enabled with MPS of 128B")
0x00000093[1] \Chassis Intrusion\Chassis Intrusion\Chassis Intrusion (Checkbox)
0x000000A7[1] \ESB2 Setup Options\ESB2 Setup Options\PEXH Bus Freq. (0:"Auto"; 1:"33 MHz"; 2:"66 MHz"; 3:"100 MHz"; 4:"133 MHz"; 5:"266 MHz")
0x000000B3[1] \ESB2 Setup Options\ESB2 Setup Options\Port 80h Cycles (0:"LPC"; 1:"PCI")
0x0000024C[1] \Blackford Configuration\ITK Hooks\ITK test branch 0/1 (0:"Branch 0"; 1:"Branch 1")
0x0000024D[1] \Blackford Configuration\ITK Hooks\ITK test config (0:"Disabled"; 1:"Enabled")
0x0000024F[1] \Blackford Configuration\Memory Interface Configuration\Memory Branch Mode (0:"Sequential"; 1:"Interleave"; 2:"Mirror"; 3:"Single Channel 0")
0x00000268[1] \Blackford Configuration\Memory Interface Configuration\Branch 0 Rank Interleave (1:"1:1"; 2:"2:1"; 4:"4:1")
0x00000269[1] \Blackford Configuration\Memory Interface Configuration\Branch 0 Rank Sparing (0:"Disable"; 1:"Enable")
0x0000026A[1] \Blackford Configuration\Memory Interface Configuration\Branch 0 Spare Error Threshold Value (15-1) (Numeric)
0x0000026B[1] \Blackford Configuration\Memory Interface Configuration\Branch 0 Spare Rank Number (8:"Auto"; 0:"Rank 0"; 1:"Rank 1"; 2:"Rank 2"; 3:"Rank 3"; 4:"Rank 4"; 5:"Rank 5"; 6:"Rank 6"; 7:"Rank 7")
0x00000274[1] \Blackford Configuration\Memory Interface Configuration\Branch 1 Rank Interleave (1:"1:1"; 2:"2:1"; 4:"4:1")
0x00000275[1] \Blackford Configuration\Memory Interface Configuration\Branch 1 Rank Sparing (0:"Disable"; 1:"Enable")
0x00000276[1] \Blackford Configuration\Memory Interface Configuration\Branch 1 Spare Error Threshold Value (15-1) (Numeric)
0x00000277[1] \Blackford Configuration\Memory Interface Configuration\Branch 1 Spare Rank Number (8:"Auto"; 0:"Rank 0"; 1:"Rank 1"; 2:"Rank 2"; 3:"Rank 3"; 4:"Rank 4"; 5:"Rank 5"; 6:"Rank 6"; 7:"Rank 7")
0x00000278[1] \Blackford Configuration\Memory Interface Configuration\Enhanced x8 Detection Threshold (0:"Disable"; 1:"Enable")
0x0000027A[1] \Blackford Configuration\Memory Interface Configuration\Enhanced x8 Detection Threshold Value (15-1) (Numeric)
0x0000027C[0] \Main\Main\Year (2004-2100)
0x0000027E[0] \Main\Main\Month (1-12)
0x00000280[0] \Main\Main\Day (1-31)
0x00000282[0] \Main\Main\Hour (0-23)
0x00000284[0] \Main\Main\Minute (0-59)
0x00000286[0] \Main\Main\Second (0-59)


#=========================================================================================
# Show the non-zero settings of the MacPro3,1
# These appear to match setup_ifr_7.txt above

source "/Volumes/Work/Programming/ThunderboltProjects/Other/OSXOLVED/gfxutil.sh"

nvramp ec87d643-eba4-4bb5-a1e5-3f3e36b20da9:Setup | xxd -c 1 | sed -E '/: 00 /d; /^(.*)  ./s//0x\1/'
0x00000004: 01
0x00000005: 01
0x00000006: 01
0x00000059: 01
0x0000005a: 02
0x00000061: 01
0x00000062: 01
0x00000063: 01
0x00000064: 01
0x00000065: 02
0x00000069: 01
0x00000075: 01
0x00000076: 01
0x00000077: 03
0x00000078: 08
0x00000079: 01
0x0000007b: 01
0x0000007c: 01
0x0000007e: 01
0x0000007f: 04
0x00000080: 02
0x00000082: 01
0x00000084: 01
0x00000086: 01
0x00000088: 01
0x0000024c: 01
0x0000024f: 01
0x00000268: 04
0x0000026a: 01
0x0000026b: 08
0x00000274: 04
0x00000276: 01
0x00000277: 08
0x0000027a: 01

Larsvonhier · Aug 24, 2020

L4va said:
Any update on this? I was also wondering if anyone was able to at least mod the BIOS emulation part of the firmware to keep AHCI enabled, rather than switching the SATA ports to IDE mode?

Also, these are my own thoughts but I personally think that this old machine would be better off with something like coreboot, rather than using Apples trash bodge of a firmware (32bit EFI on a 64bit machine, SATA being IDE when legacy booting, needing an Apple flashed GPU for boot screens, not being able to boot from a USB drive under legacy mode... must I continue?).

Some of the limitations listed are irrelevant once you got a stable system (like El Cap) running on i. e. a MP2,1.
And OpenCore won‘t help us getting newer macOS booting thereon...

There is some slow progress that Alexej, Petri and myself are working on - no solution yet, and no guarantee there will be one (soon).

Petri Krohn · Aug 25, 2020

I have sent @Larsvonhier the latest version of my modified firmware. I won't be posting it online before I am sure it is safe to flash on a Mac Pro. If you want to risk bricking your Mac, here are the instructions for recreating the file.

Three modules of the Mac Pro 2,1 firmware have been modified. I have included all three images as attachments.

In Pre-EFI initialization:

SEC core
PEI module with GUID: 72A8EAE8-0F11-4FBB-A38F-6B8144D44A9A

In EFI:

PE32 image inside compressed module with GUID: 056E7324-A718-465B-9A84-228F06642B4F

All the modifications change a check for CPUID == 0x6F to a check for Family ID == 0x6.

First replace SEC core and PEI module 72A8EAE8-0F11-4FBB-A38F-6B8144D44A9A with UEFITool by selecting "Replace body..." from the menu. The Pre-EFI section is uncompressed, so you could also do the changes directly to the EFI image using a hex editor, but in that case the checksums would not be modified and would need to be manually corrected. Store the results as a temporary file. (I called mine "MP21_007F_06B Petri CPUID fix - PEI only.rom")

If you compare the resulting temporary file with the original image using the cmp -l command, you get the following output. (cmp can only display the changed bytes in octal, not in hex.)

Code:

Petris-iMac:~ petri$ cmp -l /Users/petri/Documents/Apple/Firmware/Mac\ Pro\ 2\,1/LOCKED_MP21_007F_06B.fd /Users/petri/Documents/Apple/Firmware/Mac\ Pro\ 2\,1/MP21_007F_06B\ Petri\ CPUID\ fix\ -\ PEI\ only.rom
1889602 151  51
1896492 360   0
1896497 360   0
1925556 360   0
1925561 360   0
2093057 352 377
2093058 320 377
2093060   0 377
2093061 360 377
2094980  77  17
2094981 377   0
2094982  17   0
2095176 360   0
2095181 360   0
2095212 360   0
2095217 360   0
2095368 360   0
2095370 360   0
2095969 360   0
2095971 360   0
2096387 360   0
2096388  77  17
2096389 377   0
2096390  17   0
2096392 360   0
2096458 360   0
2096459  77  17
2096460 377   0
2096461  17   0
2096463 360   0

The first change on line 1889602 from 151 (0x69) to 51 (0x29) is a change in the checksum. For some reason UEFITool never recalculates the checksum for the SEC core module.

The changes between lines 2093057 and 2093061 to 377 (0xFF) in the middle of a pad file are a feature of UEFITool: "parseFile: non-empty pad-file contents will be destroyed after volume modifications".

The deleted hex pattern "EAD0FF00F0" is a far jump command to absolute address 0xF000FFD0.

Code:

jmp 0xF000FFD0

This hex pattern appears in two places in the MP21 image.

At address 0x1C0000, right at the start of the header of the PEI segment.
At address 0x1FF000, in the middle of the padding preceding the SEC core section.

I do not think the second one is necessary, and Larsvonhier's tests seem to confirm it. If it is, it can be restored by a manual copy-paste.

In the second step, replace the PE32 image inside the compressed module with GUID: 056E7324-A718-465B-9A84-228F06642B4F using UEFITool. The binary module is 54112 bytes long. The compressed image is 15382 bytes in the original MP2,1 image but shrinks to 15381 bytes after the change.

There is no point running cmp -l again, as compression changes most bytes of the compressed module. To check that you have recreated the correct EFI image file, calculate the MD5 hash. My image file is named "MP21_007F_06B Petri CPUID fix - v04.rom" and it has a MD5 hash of 47e87376474527a2169968ed295d33a.

Code:

Petris-iMac:~ petri$ md5 /Users/petri/Documents/Apple/Firmware/Mac\ Pro\ 2\,1/MP21_007F_06B\ Petri\ CPUID\ fix\ -\ v04.rom

MD5 (/Users/petri/Documents/Apple/Firmware/Mac Pro 2,1/MP21_007F_06B Petri CPUID fix - v04.rom) = 47e87376474527a2169968ed295d33a7

Changes to GUID: 056E7324-A718-465B-9A84-228F06642B4F - I have explained changes to the two other modules in previous posts. This compressed EFI module provided bit more of a challenge. Looking for offending code in the EFI image is difficult as all the compressed EFI modules would first have to be uncompressed and disassembled. UEFITool however lets you search the whole image for suspect hex patterns. I searched for the pattern "3D F0 06 00 00" which is a 32-bit comparison to 0x6F0 and found the EFI module.

Before the comparison the code masks the last 8 bits of the CPUID with a value in the the 8-bit AL register. I changed the mask from 0xF0 to 0x00 to mask out the Model ID. Harpertowns however have a CPUID of 0x10670, so the first two bytes also need to be masked out. It is not possible to add additional lines or bytes to the code, as the whole module would have to be reassembled. The solution was to replace the 32-bit comparison with a 16-bit comparison, freeing up one byte for a no-op.

I replaced

Code:

3D F0 06 00 00          cmp    eax, 0x6F0

...with

Code:

90                nop
66                (16-bit prefix)
3D 00 06          cmp    ax, 0x600

The 66h prefix changes the 32-bit mode to 16-bits for the particular command. Here is the resulting code as seen on Hopper. The function sub_10002655 that is called on line 1000154e is a cpuid() function included in the same module.

Petri Krohn · Aug 27, 2020

UNBRICKING A MAC PRO 1,1 - part 2
(For part 1, see this post.)

Macs have a Device Firmware Upgrade mode (DFU mode) that allows the firmware to be restored after a failed firmware update. On the iMac Pro this happens by connecting a Thunderbolt port to another Mac running Apple Configurator 2.6. Other modern Macs will automatically detect a corrupted firmware and restore the firmware from a firmware image on the recovery partition. On older Intels Macs firmware upgrade mode is entered by pressing the power button for several seconds until the sleep led starts to blink rapidly or you hear a long tone. You then insert a "Firmware Restoration CD" into the DVD drive.

The structure of the Restoration CD seems simple. In the root directory are EFI image files for all the Mac models the particular CD supports. The files that interest us are MP11_005C_04B.fd and MP21_007F_02B.fd. Evidently the process only checks for the matching model name, or if the current firmware is uncorrupted, that the version number is greater than the current version. This mechanism can be useful for our task in several ways.

Boot milestone: We have not been able to make a Mac Pro display POST codes during the boot process. @Larsvonhier has mainly been looking at the error and status LEDs at the end of a failed boot. There are a few other things to test for to see how far the boot progresses with 5400-series Xeons. The first test is to see if the system tries to configure RAM. Running the Mac without RAM should result in a single tone repeated every 5 seconds. If 5400s cannot get this far, they have failed early in Pre-EFI Initialization phase of the boot process. On the other had, if the system cannot boot, but is able to start the firmware recover, then the boot process must have successfully finished the PEI phase and has entered the EFI phase.

Safe EFI edits: It would be of great benefit to us if we knew what parts of the firmware are need for the firmware restoration to work. Evidently the whole Pre-EFI Initialization is needed and at least some parts of EFI. During firmware update the Mac shows the Apple logo and a progress bar. Some EFI graphics drivers are needed. But how can a corrupted firmware repair itself if it is corrupted? The firmware upgrade flashes the whole firmware image, including the PEI section. What happens if the power goes off when the PEI section is updated?

I was wondering if the firmware upgrade was actually handled by the System Management Controller and did a simple test. I removed the RAM and tried to see if the firmware upgrade would start. It did not. Evidently DFU mode needs the CPU and RAM.

If firmware restoration works, we can safely make changes to the EFI part of the firmware without having a dual BIOS system. We should specify the NO GO! parts of the firmware and allow hackers to play around with the rest of the firmware as they please. The test, to be done in a dual BIOS system, would be to remove as many of the EFI modules as possible and confirm that the system can still do a firmware restoration.

Fast test cycle: It might be possible to flash test images from a "Restoration CD". Just burn the EFI image to a rewritable CD and let DFU mode flash it. Test if the system boots, if not, burn another image. For this to work we would have to figure out how the naming and the numbering of the restoration images is done. The download page for the Firmware Restoration CDs says "Note: This CD cannot be used to return an Intel-based Macintosh computer's firmware to a previous version if a successful update has already been performed."

Finding Firmware Restoration CD 1.4

Apple has released nine different Firmware Restoration CD images in .dmg format. The different CDs and the different Mac models supported by each are discussed in this article. Only Macs that have received a firmware upgrade are included in the CDs. The CD contains the original, older firmware image while this download page contains the newer image. These Macs thus have two different firmware images in the wild, while some Macs, like the iMac 8,1 have no publicly available firmware image.

Recently Apple has removed some of the images from their download pages. Firmware Restoration CD 1.3 no longer seems to exist on the Internet. Searching for it in the Apple download repository produces six newer images. Of these only four contain a working download page. The download page for Firmware Restoration CD 1.4 that contains the Mac Pro 1,1 and Mac Pro 2,1 firmware images only contains a broken link.

The file to look for is named FirmwareRestorationCD1.4.dmg. A Google search for the name produces this archive. Evidently it is still available on an Apple server, but I cannot reconstruct the full URL.

DmitryD · Aug 27, 2020

1.4

FirmwareRestorationCD1.4.dmg

Nextcloud - a safe home for all your data

cloud.ufoserver.org

http://download.info.apple.com/Mac_OS_X/061-3791.20070911.mVot5/FirmwareRestorationCD1.4.dmg

1.3

FirmwareRestorationCD1.3.dmg

Nextcloud - a safe home for all your data

cloud.ufoserver.org

Larsvonhier · Aug 28, 2020

Also on Macintosh Archive, here´s the file.

Larsvonhier · Aug 28, 2020

Also most helpful would be to have the schematic diagrams / circuit diagrams of the Mac Pro (1,1 to 3,1).
Most other Apple schematics can be found on various sites, but the Mac Pro seem to be the exception here. I´ve digged for years now and only got to places mentioning the right Apple part numbers without content or marked as "unavailable".
Any hints here, friends?

L4va · Aug 29, 2020

Larsvonhier said:
Some of the limitations listed are irrelevant once you got a stable system (like El Cap) running on i. e. a MP2,1.
And OpenCore won‘t help us getting newer macOS booting thereon...

Personally I'm not interested in running macOS, let alone the latest versions. I just use Linux and Windows on my machine, as they were the only options I had in terms of being able to run a modern OS with security patches. So for me, Apples bodge firmware serves as a hassle for me.

I used to install Manjaro Linux with EFI on this machine so I didn't need to mess with custom grub entries to enable AHCI and neither did I need to go through the PAINFUL process of making modified installer discs that enable AHCI during setup (if i didn't do this, the initramfs wouldn't have been built to load the SATA controller drivers when I reboot the system with AHCI enabled) and then adding grub configs.

It soon became apparent that installing any 64bit Linux distro with an EFI loader (which also needs to be 32bit) wasn't gonna be the solution. Later kernels required I add the kernel parameter "noefi" to boot, some GPU won't be initialized by their drivers if they haven't already been init during bootup (meaning that I MUST use an Apple flashed GPU), and neither can I manage EFI variables such as which bootloader to use when booted into Manjaro because I needed to pass noefi (which disables EFIFS), so I am required to install grub with the bootloader name "boot" to force the mac to default to it.

A massive pain in the back side for anyone who wants to use a non-apple flashed GPU, who wants to run a modern OS whilst having full SATA performance.

So something like coreboot makes sense for people who use an OS that isn't macOS.

Larsvonhier · Aug 31, 2020

Some interesting stuff on a ftp server regarding S5000 chipset server EFI updates... (credits to Alexej Rempel for finding this).
Seems unrelated to the intel leaks, but exactly about "our" northbridge chipset.
The .exe file can be uncompressed and has some intel PDFs and other goodies in there.
I tried to flash the R0098.cap to the 2,1 but the rom tool does not recognize the file (same as with @Petri Krohn ´s R0095). I edited the file to have similar header beginnings as the original file, it can be flashed then but does not start any Xeon then).

Petri Krohn · Sep 15, 2020

I have not commented here for a few weeks, but I have actually been busy working on Mac Pro 1,1 upgrades. First of all, I finally got my Mac Pro 1,1 back from my cousin. I had borrowed it to her while I worked upgrading her 2007 iMac from 20 inch with El Capitan to 24 inch with Catalina. I also picked up another Mac Pro 1,1 for 60 euros.

I started by flashing video cards for boot screen. I figured out how to Atiflash on a Mac Pro without Windows or boot screen. I then created a bootable USB drive with the EFI shell. I could not find a 32-bit shell that would boot on Mac Pro 1,1, but one of the 64-bit shells I tried worked on my Mac Pro 3,1. Roderick W. Smith recommends using the shell from the Clover boot loader. I used the one I found inside Dosdude1's Catalina Patcher (which may actually be the same one).

Once inside the EFI shell, I used the shell commands to extract some information into text files. These files give cleartext names to some of the EFI DXE modules that UEFITool only identifies by GUID. I understand that the GUIDs are persistent across Mac generations, even though the implementation may change. The files are included in this post.

The module I am most interested in is the one that implements the Startup Manager interface. I searched the MP21 EFI rom image for the word "Windows". It was not found, but instead I found "EFI boot" in module A6F691AC-31C8-4444-854C-E2C1A6950F92. Searching for the GUID online reveals that it implements the Boot Device Selection (BDS) phase. This EFI GUID collection says that the GUID corresponds to Bds.dxe in a phoenix UEFI. This black hat hacker from 2009 found the same GUID in an Intel server board. Most of the other results are crap. This page actually turn up as number four in the search results, thanks to @joevt's post above. The Mac BDS has an IFR description and its behavior can be changed with the Boot000x EFI variables. (I wonder if adding new Boot000x EFI variables in NVRAM would be reflected on the boot selection screen.)

Questions: Would it be possible "boot" into an EFI shell or script and then launch the Apple boot selector from the script? Or maybe load GOP drivers from the script and only then launch the boot selector?

Does the Apple BDS.DXE module have some functions or entry point that can be called? How do you call a DXE? It is possible to call a DXE that is part of the firmware? Or do we need to load our own version of the DXE? Do we need to use the "32-bit" BDS.DXE that comes with MP21 or can we use the one from Mac Pro 3,1 or even Mac Pro 7,1?

This Lenovo PC actually has an Boot000x entry for the boot selector itself. Evidently it should be possible to "boot" into the boot selector.

I said "boot" earlier, but actually running an EFI shell or rEFInd is not booting. We have not yet called ExitBootServices() so we are still in the pre-boot Drive Execution Environment.

How to replace DXE modules?

Ultimately we want to replace some or most of the modules in the MP21 image. It would be beneficial if you could test the changes without flashing them to the ROM chip. It is possible to load DXE drivers to newly allocated memory from the EFI shell. Other parts of the firmware like the boot selector may however not be aware of these new drivers. If we want to replace old drivers with new ones, we have to overwrite the global EFI_BOOT_SERVICES table. Maybe we can hook UGA drivers to call GOP drivers? The CIA was kind enough to provide example code for doing this.

It may also be possible to replace the original code in place, provided our new code fits in the same space in the flat memory. But here we come across the issue of relocations.

Microsoft Portable Executable (PE) modules as used in EFI do not need to be relocated when loaded into memory. Like Windows DLLs, they have a preferable memory address where they should be loaded. These addresses should not overlap. Only when a PE module cannot be loaded into its preferred address is relocation done.

Earlier I wondered if the flashing process does relocation of the PE object modules found in the EFI image. Evidently not. The EFI image is loaded as on block. Each PE object module in the EFI image has its Relative virtual address (RVA) set to its final position in the EFI memory space. If we copy a DXE module from one EFI image to another and place it at another offset, then relocation needs to be done. I wonder if UEFITool does relocation? I guess not. Loading a DXE from the EFI shell should do relocation.

P.S. - Here is a collection of UEFI reverse engineering tools. I will now start watching part one of this presentation from 2015 by Trammell Hudson, Reverse engineering Apple's EFI boot ROM firmware. I also need to read through this paper on Reversing Prince Harming’s kiss of death.

Ludacrisvp · Sep 15, 2020

If I recall correctly the dosdude APFS patch runs an EFI shell script to load the APFS driver during boot to allow those non APFS macs That haven’t done a bootrom mod to boot APFS. Perhaps this could do what you’re looking for?

joevt · Sep 16, 2020

Petri Krohn said:
I could not find a 32-bit shell that would boot on Mac Pro 1,1, but one of the 64-bit shells I tried worked on my Mac Pro 3,1. Roderick W. Smith recommends using the shell from the Clover boot loader. I used the one I found inside Dosdude1's Catalina Patcher (which may actually be the same one).

Use the ver command to check version. Maybe compare the help * -v > help_all_v.txt output of each to see if they have the same features.

Petri Krohn said:
Once inside the EFI shell, I used the shell commands to extract some information into text files. These files give cleartext names to some of the EFI DXE modules that UEFITool only identifies by GUID. I understand that the GUIDs are persistent across Mac generations, even though the implementation may change. The files are included in this post.

the drivers > MP31-EFI-drivers.txt from my Parllels VM (UEFI Interactive Shell v2.2) has plain text instead of GUIDs for "IMAGE NAME" column.

For dh > MP31-EFI-handles.txt, you can get more info with dh -d -v > MP31-EFI-handles.txt.

MP31-NVRAM-Setup.txt is included in MP31-NVRAM-variables.txt. Your Setup variables are the same as mine except for 0x00000078[1] \Processor\Processor\Set Processor Ratio (20-1) (Numeric)

Code:

nvramp ec87d643-eba4-4bb5-a1e5-3f3e36b20da9:Setup | xxd -c 1 | sed -E '/: 00 /d; /^(.*)  ./s//0x\1/' > setupvars.txt
iconv -f UTF-16 -t UTF-8 /Volumes/Storage/Downloads/MP31-NVRAM-Setup.txt | sed -nE '/^  [0-9A-F]+:(.*)  .*/ { s//\1/; /-/s///; p; }' | xxd -p -r | xxd -c 1 | sed -E '/: 00 /d; /^(.*)  ./s//0x\1/' > setupvars_petri_krohn.txt
diff setupvars.txt setupvars_petri_krohn.txt

Code:

15c15
< 0x00000078: 08
---
> 0x00000078: 07

which means my processor is set faster (multiplier=8 -> 3.2 GHz). I wonder if it can be overclocked (or under-clocked to be safe)?

Your output from smbiosview > MP31-smbios.txt is strange because it has Enter to continue, :q to exit, :[0-3] to change mode, /? for help after every table.

Petri Krohn said:
The module I am most interested in is the one that implements the Startup Manager interface. I searched the MP21 EFI rom image for the word "Windows". It was not found, but instead I found "EFI boot" in module A6F691AC-31C8-4444-854C-E2C1A6950F92. Searching for the GUID online reveals that it implements the Boot Device Selection (BDS) phase. This EFI GUID collection says that the GUID corresponds to Bds.dxe in a phoenix UEFI. This black hat hacker from 2009 found the same GUID in an Intel server board. Most of the other results are crap. This page actually turn up as number four in the search results, thanks to @joevt's post above. The Mac BDS has an IFR description and its behavior can be changed with the Boot000x EFI variables.

A6F691AC-31C8-4444-854C-E2C1A6950F92 appears to be the standard PC BIOS boot stuff. It's very similar (nearly identical) to what you see in the Parallels VM UEFI UI (some of the Mac Pro IFR stuff is missing from the Parallels version).

Petri Krohn said:
(I wonder if adding new Boot000x EFI variables in NVRAM would be reflected on the boot selection screen.)

I made a script to dump those variables in macOS. I don't think the Startup Manager uses the BootXXXX variables.

For the Mac Startup Manager, the new-engine branch of the UEFITool has a list of GUIDs that you may find interesting. It has the following:

Code:

A6F691AC-31C8-4444-854C-E2C1A6950F92,DuetBds
6E72A82C-14A5-4F02-A377-4A423BB1817F,WindowsNameLabel
C0512F00-0181-48C0-8B71-90504B8F991E,EfiBootNameLabel
E1628C66-2A2D-4DC5-BD41-B20F3538AAF7,BootPicker

The label files have the same format as .disk_label created by the bless --folder ... --label ... command.

Code:

source "/Volumes/Apps/File Utilities/diskutil:pdisk:fdisk:gpt/DiskUtil.sh"

find $UEFIstuff -iname '*6E72A82C-14A5-4F02-A377-4A423BB1817F'
/Volumes/Work/Programming/EFIProjects/UEFIstuff/UEFIbios/MacPro3,1/biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/146 6E72A82C-14A5-4F02-A377-4A423BB1817F

dump_label /Volumes/Work/Programming/EFIProjects/UEFIstuff/UEFIbios/MacPro3,1/biosbackup.rom.dump/0\ 7A9354D9-0468-444A-81CE-0BF617D890DF/146\ 6E72A82C-14A5-4F02-A377-4A423BB1817F/0\ Compressed\ section/0\ FC1BCDB0-7D31-49AA-936A-A4600D9DD083/0\ Raw\ section/body.bin
................................................................................................
................................................................................................
....d6......d6......d6d6........................d6..............................................
....d6......d6......d6..........................d6..............................................
......d6....d6....d6..d6....d6..d6d6........d6d6d6......d6d6....d6..........d6....d6d6..........
......d6..d6..d6..d6..d6....d6d6....d6....d6....d6....d6....d6..d6..........d6..d6....d6........
......d6..d6..d6..d6..d6....d6......d6....d6....d6....d6....d6....d6..d6..d6......d6d6..........
........d6......d6....d6....d6......d6....d6....d6....d6....d6....d6..d6..d6..........d6........
........d6......d6....d6....d6......d6....d6....d6....d6....d6......d6..d6......d6....d6........
........d6......d6....d6....d6......d6......d6d6d6......d6d6........d6..d6........d6d6..........
................................................................................................
................................................................................................

find $UEFIstuff -iname '*C0512F00-0181-48C0-8B71-90504B8F991E'
/Volumes/Work/Programming/EFIProjects/UEFIstuff/UEFIbios/MacPro3,1/biosbackup.rom.dump/0 7A9354D9-0468-444A-81CE-0BF617D890DF/121 C0512F00-0181-48C0-8B71-90504B8F991E

dump_label /Volumes/Work/Programming/EFIProjects/UEFIstuff/UEFIbios/MacPro3,1/biosbackup.rom.dump/0\ 7A9354D9-0468-444A-81CE-0BF617D890DF/121\ C0512F00-0181-48C0-8B71-90504B8F991E/0\ Compressed\ section/0\ FC1BCDB0-7D31-49AA-936A-A4600D9DD083/0\ Raw\ section/body.bin
............................................................................................
............................................................................................
......d6d6d6d6d6....d6d6d6d6..d6..............d6d6d6d6............................d6........
......d6............d6........d6..............d6......d6..........................d6........
......d6............d6........d6..............d6......d6......d6d6........d6d6....d6d6......
......d6d6d6d6d6....d6d6d6d6..d6..............d6d6d6d6......d6....d6....d6....d6..d6........
......d6............d6........d6..............d6......d6....d6....d6....d6....d6..d6........
......d6............d6........d6..............d6......d6....d6....d6....d6....d6..d6........
......d6............d6........d6..............d6......d6....d6....d6....d6....d6..d6........
......d6d6d6d6d6....d6........d6..............d6d6d6d6........d6d6........d6d6......d6......
............................................................................................
............................................................................................

UEFITool says BootPicker is an application so it should be executable directly (like the EFI Shell).

Petri Krohn said:
Questions: Would it be possible "boot" into an EFI shell or script and then launch the Apple boot selector from the script? Or maybe load GOP drivers from the script an only then launch the boot selector?

I don't think you can call the BootPicker with one of the built-in commands of the EFI Shell since it's a firmware image instead of disk file. You can look at how rEFInd starts Boot Camp using an EFI file path. If I set Startup Disk in System Preferences to a Windows partition, it sets Boot0080 to a firmware file with GUID 2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7 (called "AppleLegacyLoad" in guids.csv and is shown as an Application in UEFITool) and adds a parameter "HD" (for hard drive, as opposed to "USB" or "CD"). It also sets efi-boot-device-data (but that's just the EFI path without the "HD" parameter).

Code:

dumpallbootvars
BootOrder: Boot0080 Boot0001 
Boot0080: 1, "Mac OS X", "MemoryMapped(0xB,0xFFE00000,0xFFF7FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)", "HD"

dumpallioregefipaths
/Root//chosen/boot-file-path = \B57FB81B-F37B-4061-8FD7-C08F243FD125\System\Library\CoreServices\/boot.efi
/Root//chosen/boot-device-path = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(9,GPT,717720E1-2443-443E-B26D-D85098BC319E,0x2E34C888,0x1D0B9500)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,E9484694FD518743B58EAD0F67C43F42)
/Root//options/efi-backup-boot-device-data = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(12,GPT,01A40057-B54C-4974-AF84-A70CD2E937FF,0x6FC68A00,0x19088)
/Root//options/BootCampHD = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
/Root//options/efi-boot-device-data = MemoryMapped(0xB,0xFFE00000,0xFFF7FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)
/Root/MacPro3,1/AppleACPIPlatformExpert/AppleEFIRuntime/AppleEFINVRAM/efi-backup-boot-device-data = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0x0,0x0)/HD(12,GPT,01A40057-B54C-4974-AF84-A70CD2E937FF,0x6FC68A00,0x19088)
/Root/MacPro3,1/AppleACPIPlatformExpert/AppleEFIRuntime/AppleEFINVRAM/BootCampHD = PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
/Root/MacPro3,1/AppleACPIPlatformExpert/AppleEFIRuntime/AppleEFINVRAM/efi-boot-device-data = MemoryMapped(0xB,0xFFE00000,0xFFF7FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

nvramp efi-boot-device
<array><dict><key>MemoryType</key><integer size="64">0xb</integer><key>StartingAddress</key><integer size="64">0xffe00000</integer><key>IOEFIDevicePathType</key><string>HardwareMemoryMapped</string><key>EndingAddress</key><integer size="64">0xfff7ffff</integer></dict><dict><key>IOEFIDevicePathType</key><string>MediaFirmwareVolumeFilePath</string><key>Guid</key><string>2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7</string></dict><dict><key>IOEFIBootOption</key><string>HD</string></dict></array>

nvramp efi-boot-device-data | xxd
00000000: 0103 1800 0b00 0000 0000 e0ff 0000 0000  ................
00000010: ffff f7ff 0000 0000 0406 1400 eb85 052b  ...............+
00000020: b8d8 a949 8b8c e21b 01ae f2b7 7fff 0400  ...I............

Now, looking at the rEFInd source code, you can see that it has an exact copy of the EFI path containing the AppleLegacyLoad GUID and has code to run it. If you can't find a way to make the Shell load an EFI application from firmware using an EFI path or a handle number or whatever, then you can create an app like rEFInd to do it.

Code:

# early 2006 Core Duo / Core Solo models
gfxutil 010318000B0000000000E0FF00000000FFFFF9FF0000000004061400EB85052BB8D8A9498B8CE21B01AEF2B77FFF0400
MemoryMapped(0xB,0xFFE00000,0xFFF9FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

# mid-2006 Mac Pro (and probably other Core 2 models)
gfxutil 010318000B0000000000E0FF00000000FFFFF7FF0000000004061400EB85052BB8D8A9498B8CE21B01AEF2B77FFF0400
MemoryMapped(0xB,0xFFE00000,0xFFF7FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

# mid-2007 MBP ("Santa Rosa" based models)
gfxutil 010318000B0000000000E0FF00000000FFFFF8FF0000000004061400EB85052BB8D8A9498B8CE21B01AEF2B77FFF0400
MemoryMapped(0xB,0xFFE00000,0xFFF8FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

# early-2008 MBA
gfxutil 010318000B0000000000C0FF00000000FFFFF8FF0000000004061400EB85052BB8D8A9498B8CE21B01AEF2B77FFF0400
MemoryMapped(0xB,0xFFC00000,0xFFF8FFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

# late-2008 MB/MBP (NVidia chipset)
gfxutil 010318000B0000000040CBFF00000000FFBFFFFF0000000004061400EB85052BB8D8A9498B8CE21B01AEF2B77FFF0400
MemoryMapped(0xB,0xFFCB4000,0xFFFFBFFF)/FvFile(2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7)

All the Macs supporting legacy bios booting into Boot Camp have the same AppleLegacyLoad GUID but the FvFile is located at different addresses (depends on firmware layout/structure).

There's a bcfg command in the UEFI Shell. It can be used to add drivers (haven't tried this on a Mac - maybe it could be used to always load the apfs.efi driver so that it doesn't need to be in a startup.nsh script). It can add boot options that point to a file or a handle. Maybe you can find the BootPicker handle, in that case the Mac would always boot to the Startup Manager if you changed the default BootXXXX option?

Petri Krohn said:
Does the Apple BDS.DXE module have some functions or entry point that can be called? How do you call a DXE? It is possible to call a DXE that is part of the firmware? Or do we need to load our own version of the DXE? Do we need to used the "32-bit" BDS.DXE that comes with MP21 or can we use the one from Mac Pro 3,1 or even Mac Pro 7,1?

Drivers can be loaded from disk using the load command but I don't know about loading from a handle. As a starter, use the output from dh, find the handle, copy the EFI path, create an alias in a .nsh script, boot into EFI Shell, run the script to create the alias (use a script so you don't have to type it), then use the alias somehow.

Petri Krohn said:
This Lenovo PC actually has an Boot000x entry for the boot selector itself. Evidently it should be possible to "boot" into the boot selector.

The Parallels VM UEFI environment has this:

It shows the path for the built in EFI Shell is a firmware file (just like AppleLegacyLoad). There's a previous menu where you can edit the items and also add drivers. Actually, the Parallels VM UEFI UI has many of the Form Sets as the IFR of the Mac Pro (many of the Titles and options are the same).

Petri Krohn said:
How to replace DXE modules?

Ultimately we want to replace some or most of the modules in the MP21 image. It would be beneficial if you could test the changes without flashing them to the ROM chip. It is possible to load DXE drivers to newly allocated memory from the EFI shell? Other parts of the firmware like the boot selector may however not be aware of these new drivers. If we want to replace old drivers with new ones we have to overwrite the global EFI_BOOT_SERVICES table. Maybe we can hook UGA drivers to call GOP drivers? The CIA was kind enough to provide example code for doing this.

It may also be possible to replace the original code in place, provided our new code fits in the same space in the flat memory. But here we come across the issue of relocations.

Microsoft Portable Executable (PE) modules as used in EFI do not need to be relocated when loaded into memory. Like Windows DLLs, they have a preferable memory address where they should be loaded. These addresses should not overlap. Only when a PE module cannot be loaded into its preferred address is relocation done.

Earlier I wondered if the flashing process does relocation of the PE object modules found in the EFI image. Evidently not. The EFI image is loaded as on block. Each PE object module in the EFI image has its Relative virtual address (RVA) set to its final position in the EFI memory space. If we copy a DXE module from one EFI image to another and place it at another offset, then relocation needs to be done. I wonder if UEFITool does relocation? I guess not. Loading a DXE from the EFI shell should do relocation.

PE images must be relocatable otherwise you wouldn't be able to load more than one of them. I don't think you need to worry about that. There must be an override method somewhere. Need to read the EFI/UEFI spec.

Ludacrisvp said:
If I recall correctly the dosdude APFS patch runs an EFI shell script to load the APFS driver during boot to allow those non APFS macs That haven’t done a bootrom mod to boot APFS. Perhaps this could do what you’re looking for?

The load command that the startup.nsh script uses to load a driver only works on files afaik. #8,029 I think running an image from firmware is different. If it were a file, then you can execute it by filename like the startup.nsh script does.

joevt · Sep 16, 2020

joevt said:
Drivers can be loaded from disk using the load command but I don't know about loading from a handle. As a starter, use the output from dh, find the handle, copy the EFI path, create an alias in a .nsh script, boot into EFI Shell, run the script to create the alias (use a script so you don't have to type it), then use the alias somehow.

I found FvSimpleFileSystem which might do the trick. Build it with your favourite UEFI build environment (I have used Clover in the past). Then you can use the load and connect commands in the UEFI Shell (like the commands in the startup.nsh script used to load the apfs.efi driver and connect apfs volumes).

Petri Krohn · Sep 17, 2020

I figured out the difference between UEFITool 0.28.0 and UEFITool A57. Version A57 uses the "new engine", but it cannot reconstruct EFI images. The new engine is however better in analyzing EFI images, as it labels known modules in cleartext instead of using GUIDs. The two modules of interest are:

BootPicker: E1628C66-2A2D-4DC5-BD41-B20F3538AAF7
DuetBds: A6F691AC-31C8-4444-854C-E2C1A6950F92

This list says that BootPicker.efi is an application while Bds.efi is a driver.

joevt said:
I found FvSimpleFileSystem which might do the trick. Build it with your favourite UEFI build environment (I have used Clover in the past). Then you can use the load and connect commands in the UEFI Shell (like the commands in the startup.nsh script used to load the apfs.efi driver and connect apfs volumes).

What toolchain would we need to build the FvSimpleFileSystem for the 32-bit EFI on the Mac Pro 2,1?

P.S. - Another module to start as an application from the EFI shell would be SetupBrowserDxe with GUID EBF342FE-B1D3-4EF8-957C-8048606FF670. The unicode claims it is a "Setup Interpreter". I suspect this is the interface to the "hidden BIOS settings" defined in the IFR data.

I also noticed that there is an additional layer of multi-lingual text on top of the IFR configuration in the module PlatformDXE with GUID 056E7324-A718-465B-9A84-228F06642B4F.

P.P.S. - This is interesting! CrScreenshotDxe - A UEFI DXE driver to take screenshots from GOP-compatible graphic consoles.

To start the driver, you can either:

Integrate it into DXE volume of your UEFI firmware using UEFITool or any other suitable software (don't forget a DepEx section to prevent too early start)

Add it to an OptionROM of a PCIe device (will try it once I have a device needed)

Let BDS dispatcher load it by copying it to ESP and creating a DriverXXXX variable

Load it from UEFI Shell with load command

This blog post in Russian explains more.

joevt · Sep 18, 2020

Petri Krohn said:
I figured out the difference between UEFITool 0.28.0 and UEFITool A57. Version A57 uses the "new engine", but it cannot reconstruct EFI images. The new engine is however better in analyzing EFI images, as it labels known modules in cleartext instead of using GUIDs.

I would just use UEFIExtract, then use a script to add human readable names to the GUID file names. The script can use a database like your AppleEfiList.txt or the guids.csv file. For example, after executing the script, the BootPicker would be named something like this file-E1628C66-2A2D-4DC5-BD41-B20F3538AAF7.BootPicker.app-00.efi.

Before there was UEFIExtract, there was efidecomp and xfv.py. I had created scripts that used the results of those utilities on all the firmwares downloadable from Apple. I've attached some of the scripts. I should update them to work with UEFIExtract output instead of xfv.py output. There are some useful features in there like identifying some of the raw file types (png, icns, bmp, aml, etc.).

Along with a guid list for apps and drivers and such, you also should have a protocols list. Then the combination of guids and protocol guids can be used to clarify dependencies (apps don't have dependencies but drivers do?). For example, UEFIExtract produces this for one of the files:

/Volumes/Work/Programming/EFIProjects/UEFIstuff/UEFIbios/MacPro3,1/biosbackup.rom.dump/0\ 7A9354D9-0468-444A-81CE-0BF617D890DF/94\ 6C077FAF-8258-4C08-B86D-B8DC632632B4/0\ Compressed\ section/0\ FC1BCDB0-7D31-49AA-936A-A4600D9DD083/0\ DXE\ dependency\ section/info.txt

Code:

Type: Section
Subtype: DXE dependency
Fixed: No
Offset: 1Ch
Type: 13h
Full size: 5Eh (94)
Header size: 4h (4)
Body size: 5Ah (90)
Parsed expression:
PUSH 1390954D-DA95-4227-9328-7282C217DAA8
PUSH 3792095A-E309-4C1E-AA01-85F5655A17F1
AND
PUSH 14FC52BE-01DC-426C-91AE-A23C3E220AE8
AND
PUSH C50B323E-9075-4F2A-AC8E-D2596A1085CC
AND
PUSH E541B773-DD11-420C-B026-DF993653F8BF
AND
END

while my old scripts produces this:

/Volumes/Updates/Misc_Software/rEFIt/Mac\ EFI\ info/firmware\ downloads/MP31.006C.B05\ \(EFI\ 1.3\)/LOCKED_MP31_006C_05B.fd.contents/part01/file-6C077FAF-8258-4C08-B86D-B8DC632632B4.SmmPlatform.drv-00.dxedepex.txt

Code:

PUSH 1390954D-DA95-4227-9328-7282C217DAA8.SMMBase
PUSH 3792095A-E309-4C1E-AA01-85F5655A17F1.SMMAccess
AND
PUSH 14FC52BE-01DC-426C-91AE-A23C3E220AE8.SMMSxDispatch
AND
PUSH C50B323E-9075-4F2A-AC8E-D2596A1085CC
AND
PUSH E541B773-DD11-420C-B026-DF993653F8BF.SMMSoftwareDispatch
AND
END

Petri Krohn said:
The two modules of interest are:

BootPicker: E1628C66-2A2D-4DC5-BD41-B20F3538AAF7

DuetBds: A6F691AC-31C8-4444-854C-E2C1A6950F92

This list says that BootPicker.efi is an application while Bsd.efi is a driver.

What toolchain would we need to build the FvSimpleFileSystem for the 32-bit EFI on the Mac Pro 2,1?

rEFIt has the ability to create fat efi binaries by combining IA32 and IA64 binaries. I think fat binaries only worked on Macs?
rEFInd created separate binaries.
Clover used to create separate binaries. Maybe find an older version if the current version doesn't do IA32. Or for the current version, maybe there's a setting to allow IA32 build. An old command to build Clover with IA32 was this "./ebuild.sh -fr --ia32 -xcode5".
I think there was a legacy BIOS boot loader that loads a 64 bit EFI that you could use on MacPro2,1? Clover might have that feature.

Petri Krohn said:
P.S. - Another module to start as an application from the EFI shell would be SetupBrowserDxe with GUID EBF342FE-B1D3-4EF8-957C-8048606FF670. The unicode claims it is a "Setup Interpreter". I suspect this is the interface to the "hidden BIOS settings" defined in the IFR data.

That would definitely be a good one to test once you have the ability to run these applications.

Petri Krohn said:
I also noticed that there is an additional layer of multi-lingual text on top of the IFR configuration in the module PlatformDXE with GUID 056E7324-A718-465B-9A84-228F06642B4F.

Yes, at the top of the IFRExtract output (setup_ifr_7.txt) is a list of included languages (with their offsets in the binary). IFRExtract defaults to showing the English text for the rest of the output.

Code:

                                EFI Protocol Detected
--------------------------------------------------------------------------------


                                String Packages
--------------------------------------------------------------------------------
Offset:        Language:
--------------------------------------------------------------------------------
0x3560        eng (0x0)
0x71CA        fra (0x1)
0xB074        spa (0x2)

There's an entire spec pdf discussing IFR "Intel® Platform Innovation Framework for EFI Human Interface Infrastructure Specification".

edk2-UefiDriverWritersGuide/12_uefi_driver_configuration/123_hii_protocols at main · tianocore-docs/edk2-UefiDriverWritersGuide

EDK II Driver Writer's Guide for development of UEFI Drivers - tianocore-docs/edk2-UefiDriverWritersGuide

github.com

GitBook

edk2-docs.gitbook.io

update: I think EFIExtract does replace GUIDs with names if its guid database is in the correct location relative to the executable.

Petri Krohn · Sep 18, 2020

This is interesting! Page 161 of the book Mac OS X Internals: A Systems Approach from 2006:

4.16.4.2. The Boot Manager
The EFI firmware includes an application called the boot manager, which can load EFI bootloaders, EFI drivers, and other EFI applications. The boot manager consults global NVRAM variables to determine what to boot. It accesses bootable files from an EFI-defined file system or via an EFI-defined image-loading service.

Would it be possible to manipulate the NVRAM variables so that the "BIOS" Setup Interpreter becomes one of the boot options?

4.16.4.3. The EFI Shell
The EFI environment optionally includes an interactive shell that allows a user to perform tasks such as the following:

Launch other EFI programs

Load, test, and debug drivers manually

Load ROM images

View or manipulate memory and hardware state

Manage system variables

Manage files

Edit text

Run shell scripts

Access the network for example, via an Ethernet or a dial-up connection

Is it possible to load a 64-bit ROM image from a 32-bit shell? Can we load the Mac Pro 3,1 image from a shell on a Mac Pro 2,1?

joevt · Sep 18, 2020

Petri Krohn said:
This is interesting! Page 161 of the book Mac OS X Internals: A Systems Approach from 2006:

Would it be possible to manipulate the NVRAM variables so that the "BIOS" Setup Interpreter becomes one of the boot options?

I suggested this when I mentioned how Boot Camp is set as the boot option. I don't know if it will work but it can be set in the same way. Set the boot to Boot Camp, replace the Boot Camp GUID in Boot0080 with the Boot Manager GUID (or use gfxutil to construct the entire EFI device path and poke that into Boot0080).

Petri Krohn said:
Is it possible to load a 64-bit ROM image from a 32-bit shell? Can we load the Mac Pro 3,1 image from a shell on a Mac Pro 2,1?

No. Or it will be extremely difficult. You need to build a 64 bit EFI environment while in 32 bit EFI, then kill the 32 bit EFI environment and switch to the 64 bit environment. I think I would prefer that method over the method where you boot legacy BIOS and build an EFI in that like Clover does for old PCs that don't have EFI.

Have you seen the boot.efi hack that lets a 64 bit macOS kernel work with 32 bit EFI?

2006/2007 Mac Pro (1,1/2,1) and OS X El Capitan

The race is on. Who's the first to get OS X version 10.11 El Capitan booting perfectly on a 2006/2007 Mac Pro (1,1/2,1)? UPDATE: Only one day later, 666sheep did it first! This first post has now been updated with recent summarized information. Simply looking to download the Piker-Alpha...

forums.macrumors.com

Petri Krohn · Sep 19, 2020

What is the difference between 32-bit and 64-bit EFI?

To execute 64-bit instructions, the processor must be in the "long mode". But what is this long mode? Intel says its processors only operate in four modes, real, protected, virtual 8086, and system management mode (SMM):

Intel® Processors since the Intel386™ Processor can run one of three modes:

Real mode

Protected mode

SMM mode

You can also add a fourth mode called Virtual 8088 mode, which is considered a pseudo mode of the protected mode.

To enter 64-bit long mode the processor must disable virtual 8086 mode by setting the EFER.LME (long mode enabled) flag in Model Specific Register 0xC0000080. (I guess this is because of conflicting op codes between the modes.)

The 64-bit address space is already present in 32-bit Pentium 4 processors with Physical Address Extension (PAE). There is no requirement for 64-bit code to actually use 64-bit addresses. 32-bit code will run without changes. Many compilers default to creating 32-bits wide code.

The real difference between 32-bit and 64-bit EFI code is in the calling convention. @osxreverser explains:

For 32-bit binaries the calling convention is the standard C calling convention (arguments passed on the stack).

For 64-bit binaries Microsoft’s x64 calling convention is used (arguments passed via RCX, RDX, R8, R9, stack). The stack must be aligned in a 16-byte boundary, and a 32-byte shadow space must be reserved on the stack above the return address. This means that we will see the first stack argument starting at offset 0x20.

SEC and PEI phase binaries are 32-bit (16-bit code also found for CPU initialization) and DXE binaries are 64-bit.

To call 32-bit EFI functions from 64-bit code, one would need to write wrappers. The code would take the arguments from the 64-bit registers, truncate them to 32-bits and place them on the stack, before calling the 32-bit function. I think the wrapper could be generic, ie. able to handle any number of stack arguments, as long as all arguments are 32 bits. The problem lies in compiling such code. What compiler can handle 32-bit and 64-bit calling conventions at the same time. Maybe the wrapper needs to be spliced together in assembler.

Is a 64-bit EFI really needed?

Intel makes great fuzz of 32-bit operating systems needing a 32-bit EFI and 64-bit operating systems needing a 64-bit EFI. This is not really true, as the 32-to-64-bit boot.efi used for El Capitan demonstrates.

64-bit EFI provides runtime services for 64-bit operating systems. But what are these services? A look at the RunTime Services table reveals that they are trivial:

Code:

typedef struct  {
  EFI_TABLE_HEADER                Hdr;
  EFI_GET_TIME                    GetTime;
  EFI_SET_TIME                    SetTime;
  EFI_GET_WAKEUP_TIME             GetWakeupTime;
  EFI_SET_WAKEUP_TIME             SetWakeupTime;
  EFI_SET_VIRTUAL_ADDRESS_MAP     SetVirtualAddressMap;
  EFI_CONVERT_POINTER             ConvertPointer;
  EFI_GET_VARIABLE                GetVariable;
  EFI_GET_NEXT_VARIABLE_NAME      GetNextVariableName;
  EFI_SET_VARIABLE                SetVariable;
  EFI_GET_NEXT_HIGH_MONO_COUNT    GetNextHighMonotonicCount;
  EFI_RESET_SYSTEM                ResetSystem;
} EFI_RUNTIME_SERVICES;

How much code does one need to write to create wrappers for all eleven functions?

Linux developer Matthew Garrett wrote a rant against 32-bit EFI: Don't ship 32-bit UEFI firmware on x86. I tend to disagree. Maybe all EFI should be 32-bit, with an option to boot both 32 and 64-bit operating systems. UEFI would make a great 64-bit DOS, if anyone used it for program development. But does anyone actually need a 64-bit DOS?

joevt said:
Have you seen the boot.efi hack that lets a 64 bit macOS kernel work with 32 bit EFI?

Yes, I use it on my Mac Pro 1,1 to run El Capitan. I have never actually looked inside the code. I guess it simply contains a copy of EFI_RUNTIME_SERVICES table populated with wrapper functions to the 32-bit EFI functions. And naturally a copy of the 64-bit bootX64.efi boot file.

Update September 20, 2020: GNU-EFI has a generic function wrapper to bridge the different calling conventions. You just need to specify the number of arguments passed. Roderick W. Smith explains:

But wait—what's this uefi_call_wrapper() function? It's a workaround for the problem noted on the "Hello, World" page: EFI uses the Microsoft ABI, whereas GNU-EFI uses the SysV ABI. Because so many EFI features are accessed through pointers to functions, it's necessary to call them in such a way that the ABI difference is handled properly. The uefi_call_wrapper() function does just that. It takes a variable number of arguments. The first is the pointer to the function that must be wrapped, the second is the number of arguments that the called function takes, and the remaining arguments are passed to the function unchanged.

Update November 1, 2020: I have been reading on 32-bit and 64-bit processor modes. Good general sources are the Wikipedia article on x86-64 and this History of Modern 64-bit Computing from 2007. I was wrong about the operating modes. Wikipedia finds a total of six modes in addition to the SMM mode: real mode, unreal mode, virtual 8086 mode, protected mode and long mode with 64-bit mode and 32-bit compatibility mode submodes.

32-bit code may not work when run in 64-bit mode. Some op-codes, like PUSH and POP have different semantics in 64-bit mode and the two 32-bit modes. It is not just a question of the same mnemonic having different translations in the two modes, but of the same hex opcode having different effects in the different modes.

The operating mode is defined by four flag bits in four different registers. This article describes how the flags must be set. See X86 encoding and the photo below.

A search of the web reveals that 32-bit code and 64-bit code are not supposed to intermix. 64-bit Windows applications cannot call 32-bit DLLs. Some people have however tried and succeeded.

Here is an old discussion on switching modes. Can you enter x64 32-bit “long compatibility sub-mode” outside of kernel mode?
Luboš Doležel was working on improving Darling, a translation layer that lets you run macOS software on Linux. He has a post on Running 32-bit code in 64-bit Linux processes.

Update January 2, 2021: Linux can cross-boot in EFI mode from 32/64-bit EFI to a 32/64-bit kernel. From the Ubuntu documentation pages:

OS kernel architecture (32 or 64-bit) must be the same as the EFI architecture (unless "eficross" is used, which is available from kernel 3.4)

UEFIBooting - Community Help Wiki

I looked into "eficross". It existed for a short time in 2012, but was merged into the Linux kernel in 2013. The source code with the diffs is interesting reading. The solution is to simply not provide EFI runtime services if the modes mismatch. (I guess there are other ways of reading the system clock.)

joevt · Sep 27, 2020

I made some scripts to set boot variables in macOS
I can load drivers (such as apfs.efi) without using an EFI boot loader (no EFI Shell, rEFInd, Clover, or OpenCore required).
See: #86

I can set the Startup Manager as the boot app (similar to how macOS sets Boot Camp as the boot app):

Code:

setbootvar Boot0080 1 "BootPicker" "MemoryMapped(0xB,0xFFE00000,0xFFF7FFFF)/FvFile(E1628C66-2A2D-4DC5-BD41-B20F3538AAF7)"
setbootorder Boot0080

If the apfs.efi driver is loaded (Driver#### was setup), then the Startup Manager will list apfs volumes.

I'm not sure how to get the setup IFR stuff to load though since they are drivers and not apps. Maybe the required app is removed from Mac firmware?

There is a EfiUtil app (DEA6-4081-BFBF-3B720EB1386D) which appears to be for flashing firmware? I have not tried it. It takes parameters so I guess it should be executed from the EFI Shell or maybe the parameters can be passed using the optional data part of the bootvar (encoded as UTF-16LE).

gabe12345 · Sep 28, 2020

Wait so how is progress going? Has anybody gotten the 5400 cpus to boot? Are you close? Will newer versions of Mac OS even work with just the 5400 cpu?

joevt · Sep 29, 2020

joevt said:
Clover used to create separate binaries. Maybe find an older version if the current version doesn't do IA32. Or for the current version, maybe there's a setting to allow IA32 build. An old command to build Clover with IA32 was this "./ebuild.sh -fr --ia32 -xcode5".

I used the Clover build environment to build FvSimpleFileSystemDxe.
FvSimpleFileSystemDxe requires EfiFirmwareVolume2ProtocolGuid but my MacPro3,1 uses EfiFirmwareVolumeProtocolGuid so I also added Fv2OnFvThunk (from UDK2018) to Clover. I only needed to modify the Clover.dsc file to include each .inf file.

I installed the two files in the rEFInd drivers folder (they can also be loaded manually in the EFI Shell or by using the Driver#### variables). From rEFInd, the EFI Shell has the following FramerworkEfiFirmwareVolumeBlockProtocolGuid/EfiFirmwareVolumeProtocolGuid handles with the new protocols added (964E5B22-6459-11D2-8E39-00A0C969723B:EfiSimpleFileSystemProtocolGuid (Fs) from FvSimpleFileSystemDxe and 220E73B6-6BDB-4413-8405-B974B108619A:EfiFirmwareVolume2ProtocolGuid from Fv2OnFvThunk):

Code:

Handle 05 (7F468718)
   Dpath (7F467D28)
      Hardware Device Path for Memory Mapped
       Memory Type (11: FFFC0000-FFFFFFFF)
      AsStr: 'MemMap(11:FFFC0000-FFFFFFFF)'
   Fs (7D632AD0)

     Controller Name    : <UNKNOWN>

     Device Path        : MemMap(11:FFFC0000-FFFFFFFF)
     Controller Type    : ROOT
     Configuration      : NO
     Diagnostics        : NO
     Managed by :
       Drv[172] : Fv Simple File System Driver
     Parent Controllers : <NONE>
     Child Controllers  : <NONE>
   220E73B6-6BDB-4413-8405-B974B108619A (7B0CCF20)
   F496922D-172F-4BBC-A1EB-0EEB949C3486 (00000000)
   53A4C71B-B581-4170-91B3-8DB87A4B5C46 (7F844788)
   389F751F-1838-4388-8390-CD8154BD27F8 (7F467030)
   7AA35A69-506C-444F-A7AF-694BF56F71C8 (00000000)
   DE28BC59-6228-41BD-BDF6-A3B9ADB58DA1 (7F844748)

Handle 06 (7F468598)
   Dpath (7F467928)
      Hardware Device Path for Memory Mapped
       Memory Type (11: FFE00000-FFF7FFFF)
      AsStr: 'MemMap(11:FFE00000-FFF7FFFF)'
   Fs (7D6327D0)

     Controller Name    : <UNKNOWN>

     Device Path        : MemMap(11:FFE00000-FFF7FFFF)
     Controller Type    : ROOT
     Configuration      : NO
     Diagnostics        : NO
     Managed by :
       Drv[172] : Fv Simple File System Driver
     Parent Controllers : <NONE>
     Child Controllers  : <NONE>
   220E73B6-6BDB-4413-8405-B974B108619A (7D638F20)
   F496922D-172F-4BBC-A1EB-0EEB949C3486 (00000000)
   53A4C71B-B581-4170-91B3-8DB87A4B5C46 (7F842F88)
   389F751F-1838-4388-8390-CD8154BD27F8 (7F465E30)
   7AA35A69-506C-444F-A7AF-694BF56F71C8 (00000000)
   DE28BC59-6228-41BD-BDF6-A3B9ADB58DA1 (7F842F48)

Handle 25 (7EF72D98)
   Dpath (7F844920)
      Hardware Device Path for Memory Mapped
       Memory Type (11: FFF80000-FFF83FFF)
      AsStr: 'MemMap(11:FFF80000-FFF83FFF)'
   Fs (7D632550)

     Controller Name    : <UNKNOWN>

     Device Path        : MemMap(11:FFF80000-FFF83FFF)
     Controller Type    : ROOT
     Configuration      : NO
     Diagnostics        : NO
     Managed by :
       Drv[172] : Fv Simple File System Driver
     Parent Controllers : <NONE>
     Child Controllers  : <NONE>
   220E73B6-6BDB-4413-8405-B974B108619A (7B0CF820)
   AC5E4829-A8FD-440B-AF33-9FFE013B12D8 (7F0BADB0)
   F496922D-172F-4BBC-A1EB-0EEB949C3486 (00000000)
   53A4C71B-B581-4170-91B3-8DB87A4B5C46 (7F844988)
   389F751F-1838-4388-8390-CD8154BD27F8 (7EF6D130)
   DE28BC59-6228-41BD-BDF6-A3B9ADB58DA1 (7F844948)

The map command shows the new file systems are mapped like this:

Code:

  fsnt0  Consistent Name f1
         Other Name   (null)
         Handle        6: Fs
         Media Type   BlockDevice
         Removable   NO
         Current Dir  \
         MemMap(11:FFE00000-FFF7FFFF)
  fsnt1  Consistent Name f2
         Other Name   (null)
         Handle       25: Fs
         Media Type   BlockDevice
         Removable   NO
         Current Dir  \
         MemMap(11:FFF80000-FFF83FFF)
  fsnt2  Consistent Name f4
         Other Name   (null)
         Handle        5: Fs
         Media Type   BlockDevice
         Removable   NO
         Current Dir  \
         MemMap(11:FFFC0000-FFFFFFFF)

Here's a directory listing for the first one:

Code:

Directory of: f1:\

  00/00/00  12:00a       r        1,792  E6E857D0-9DCD-4FB0-9BAF-54C54916179F.efi
  00/00/00  12:00a       r       10,624  BCCAD460-4F7D-4E51-8A5D-3BBA236D9EBB.efi
  00/00/00  12:00a       r       15,520  6074610C-93C6-4A50-9AAA-0927DE7C6975.efi
  00/00/00  12:00a       r       47,424  0412A7A1-C050-42C2-877A-77C379F9F5F1.efi
  00/00/00  12:00a       r        1,952  74CBEC3C-8190-42A0-9C02-D1C5ADC706D7.efi
  00/00/00  12:00a       r        3,264  9204A71D-2050-4AB7-AD42-749CF9ADB4EB.efi
  00/00/00  12:00a       r       10,624  9FBAD95A-EB48-454D-9393-DB43C511DBEB.efi
  00/00/00  12:00a       r       58,564  1F9CABF9-3F3C-4CFF-AED8-5FDF745A0DCC
  00/00/00  12:00a       r        7,040  2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7.efi
  00/00/00  12:00a       r        7,808  AD21F7A0-7F5B-47FE-8CC0-241F318CABF5.efi
  00/00/00  12:00a       r        1,856  9F2A114A-834B-4916-945C-1C09F4944819.efi
  00/00/00  12:00a       r        6,016  DF9A9591-B646-4621-AF0D-18143A73289F.efi
  00/00/00  12:00a       r       35,264  EF33C296-F64C-4146-AD04-347899702C84.efi
  00/00/00  12:00a       r       74,240  1547B4F3-3E8A-4FEF-81C8-328ED647AB1A
  00/00/00  12:00a       r        9,888  29CF55F8-B675-4F5D-8F2F-B87A3ECFD063.efi
  00/00/00  12:00a       r        2,560  5479662B-6AE4-49E8-A6BD-6DE4B625811F.efi
  00/00/00  12:00a       r       32,672  F122A15C-C10B-4D54-8F48-60F4F06DD1AD.efi
  00/00/00  12:00a       r        1,248  D3709BB4-B194-4B71-B9C0-DBD8D2DA97AD.efi
  00/00/00  12:00a       r        1,824  208117F2-25F8-479D-B726-10C10BED6DC1.efi
  00/00/00  12:00a       r       13,536  BC6D08DC-865D-4FFE-8B7A-FB5FB04F12F1.efi
  00/00/00  12:00a       r          581  6E72A82C-14A5-4F02-A377-4A423BB1817F
  00/00/00  12:00a       r        2,082  7914C493-F439-4C6C-AB23-7F72150E72D4
  00/00/00  12:00a       r          431  6B309956-6617-472B-BBC7-2A09E55E3E52
  00/00/00  12:00a       r          425  1448C340-0202-4711-9C4B-2D063AA6475B
  00/00/00  12:00a       r          225  7EF21E8C-2FC1-4BC3-A84A-73025EAAB896
  00/00/00  12:00a       r          233  EA449C41-8236-4B97-9FF9-084E4BA70020
  00/00/00  12:00a       r          422  B10ADFA1-9E43-487F-AAF3-A7A9BDEAF4AC
  00/00/00  12:00a       r          424  F5D14DB5-2F0C-4611-9DDC-7C182B173A71
  00/00/00  12:00a       r        5,680  F38C34DE-9C38-438C-9AF6-69F584F17EC0
  00/00/00  12:00a       r       10,814  C6A957E4-8303-4761-A084-92C0692D90F9
  00/00/00  12:00a       r       14,606  79C3AC4A-DEC6-48F1-AFFE-E7B95A1CCB32
  00/00/00  12:00a       r       14,675  03DBB540-E186-4615-8A7F-A427863B4E56
  00/00/00  12:00a       r       12,817  4308B1F6-60F0-49FE-9E51-3A25992515BF
  00/00/00  12:00a       r        9,383  13ECD928-87AB-4460-BBE0-B520F9EB1D32
  00/00/00  12:00a       r          576  689CDA29-29A8-42F6-93FC-46BA5F180651
  00/00/00  12:00a       r          974  BB1A3984-D171-4003-9094-46AF866B45A2
  00/00/00  12:00a       r          223  71F3B066-936A-4C84-9228-23230FD47C79
  00/00/00  12:00a       r          252  8F98528C-F736-4A84-AAA3-376A8E43BF51
  00/00/00  12:00a       r          916  6776572C-FE56-42CA-9B93-3D0960E7583A
  00/00/00  12:00a       r        1,862  A0AAFF71-35DA-41EE-863F-A24F429E59E4
  00/00/00  12:00a       r       12,921  1BFC532E-F48A-4EBE-B2FB-2B286D70A6EB
  00/00/00  12:00a       r       50,669  E6F930E0-BAE5-40E6-98C9-4CD2298278E7
  00/00/00  12:00a       r       23,098  809FBBFD-127A-4249-88BC-FD0E767F4FFD
  00/00/00  12:00a       r       20,811  21A05FD5-DB4A-4CFC-B84B-EB0DBB569934
  00/00/00  12:00a       r       13,434  410C1D0C-656F-4769-8DFB-90F9A0303E9F
  00/00/00  12:00a       r          557  C0512F00-0181-48C0-8B71-90504B8F991E
  00/00/00  12:00a       r        1,780  B4339807-7CAC-49BA-9FB7-6231C622F270
  00/00/00  12:00a       r        1,308  E8A59290-A2AF-4099-B0AF-323FF9B7AB41
  00/00/00  12:00a       r          654  1A10742F-FA80-4B79-9DA6-357058CC397B
  00/00/00  12:00a       r       10,048  F2C1819D-10F5-4223-9236-9B4EBF1B9AE7
  00/00/00  12:00a       r        1,888  5C08E2E2-AD70-4C99-94A2-AE604EA033DA.efi
  00/00/00  12:00a       r        1,568  BD87394D-465C-40A9-9657-FBED21789860.efi
  00/00/00  12:00a       r       50,240  CCEC84CD-CDC5-4C75-8637-D4508FC79CCD.efi
  00/00/00  12:00a       r        2,144  CD51358D-6E7E-45CA-B450-57C046BDFDDC.efi
  00/00/00  12:00a       r        6,976  FF478412-38C3-4770-85F6-5D076C62125F.efi
  00/00/00  12:00a       r        3,296  2D61B52A-69EF-497D-8317-5574AEC89BE4.efi
  00/00/00  12:00a       r        6,304  56AAA799-5273-406E-85D7-05A8DF24BF2C.efi
  00/00/00  12:00a       r        9,504  E364A338-2842-4F57-A7C7-CDC8CFDF6CD7.efi
  00/00/00  12:00a       r       13,440  9EBA2D25-BBE3-4AC2-A2C6-C87F44A1278C.efi
  00/00/00  12:00a       r       41,408  E1628C66-2A2D-4DC5-BD41-B20F3538AAF7.efi
  00/00/00  12:00a       r       59,904  D0FE1B74-DEA6-4081-BFBF-3B720EB1386D.efi
  00/00/00  12:00a       r        4,672  4AA33F45-9000-4E6D-9A26-CBEA50D26B1B.efi
  00/00/00  12:00a       r        2,112  0857A2DE-A903-4021-8B13-7FDF873B33B8.efi
  00/00/00  12:00a       r        2,656  CC582C73-F48F-4B62-83E8-A586B4C88F84.efi
  00/00/00  12:00a       r        3,200  4391AA92-6644-4D8A-9A84-DDD405C312F3.efi
  00/00/00  12:00a       r           90  7E374E25-8E01-4FEE-87F2-390C23C606CD
  00/00/00  12:00a       r       11,360  EF0C99B6-B1D3-4025-9405-BF6A560FE0E0.efi
  00/00/00  12:00a       r       65,760  056E7324-A718-465B-9A84-228F06642B4F.efi
  00/00/00  12:00a       r        2,432  E2441B64-7EF4-41FE-B3A3-8CAA7F8D3017.efi
  00/00/00  12:00a       r        2,400  8B24E4D4-C84C-4FFC-81E5-D3EACC3F08DD.efi
  00/00/00  12:00a       r        3,104  57EFA8FC-B631-4FBE-88E3-E520AE57BAA3.efi
  00/00/00  12:00a       r        2,752  6F0198AA-1F1D-426D-AE3E-39AB633FCC28.efi
  00/00/00  12:00a       r        1,728  6C077FAF-8258-4C08-B86D-B8DC632632B4.efi
  00/00/00  12:00a       r        2,368  0FC0712E-CDBF-4970-81DF-3BA49C0A8B45.efi
  00/00/00  12:00a       r        3,488  1BDB371E-BD78-4120-8A1D-7C9227A41C9B.efi
  00/00/00  12:00a       r       14,048  8E6BD67D-1872-4932-A39A-FC9DCA4A98CF.efi
  00/00/00  12:00a       r        2,368  AB8DDBAA-9C47-429B-9D12-326F273D9B88.efi
  00/00/00  12:00a       r        7,104  E41A9651-43B2-484F-8EFA-D54AC7419C24.efi
  00/00/00  12:00a       r       64,672  EBF342FE-B1D3-4EF8-957C-8048606FF670.efi
  00/00/00  12:00a       r        2,144  8F26EF0A-4F7F-4E4B-9802-8C22B700FFAC.efi
  00/00/00  12:00a       r       10,880  43B93232-AFBE-11D4-BD0F-0080C73C8881.efi
  00/00/00  12:00a       r       33,696  5058F21C-BC34-11D4-BD18-0080C73C8881.efi
  00/00/00  12:00a       r        3,680  CA261A26-7718-4B9B-8A07-5178B1AE3A02.efi
  00/00/00  12:00a       r       14,208  9E863906-A40F-4875-977F-5B93FF237FC6.efi
  00/00/00  12:00a       r       12,960  CCCB0C28-4B24-11D5-9A5A-0090273FC14D.efi
  00/00/00  12:00a       r       16,608  408EDCEC-CF6D-477C-A5A8-B4844E3DE281.efi
  00/00/00  12:00a       r        4,640  51CCF399-4FDF-4E55-A45B-E123F84D456A.efi
  00/00/00  12:00a       r        6,720  87AB821C-79B8-4EF6-A913-21D22063F55F.efi
  00/00/00  12:00a       r        3,776  F5AC7057-5650-466E-B692-76A47223EFB0.efi
  00/00/00  12:00a       r        9,344  F46998C9-DD30-4C64-966C-E17777B2568A.efi
  00/00/00  12:00a       r       23,616  4CF484CD-135F-4FDC-BAFB-1AA104B48D36.efi
  00/00/00  12:00a       r        4,192  07B37006-9302-408E-B416-B524D110DD7F.efi
  00/00/00  12:00a       r        6,944  2D2E62AA-9ECF-43B7-8219-94E7FC713DFE.efi
  00/00/00  12:00a       r        7,872  2D2E62CF-9ECF-43B7-8219-94E7FC713DFE.efi
  00/00/00  12:00a       r        6,720  A5C6D68B-E78A-4426-9278-A8F0D9EB4D8F.efi
  00/00/00  12:00a       r        3,872  B40612B2-A063-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r        5,600  A3527D16-E6CC-42F5-BADB-BF3DE177742B.efi
  00/00/00  12:00a       r        5,888  B40612B9-A063-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r       17,152  240612B7-A063-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r       18,944  2FB92EFA-2EE0-4BAE-9EB6-7464125E1EF7.efi
  00/00/00  12:00a       r       72,864  07B70E53-B0EE-4DB3-82C5-195169832CD5.efi
  00/00/00  12:00a       r       57,856  7A5CFD97-8F27-458A-BD42-E0F9EE46E631.efi
  00/00/00  12:00a       r       14,272  A3F436EA-A127-4EF8-957C-8048606FF674.efi
  00/00/00  12:00a       r       14,848  A2F436EA-A127-4EF8-957C-8048606FF670.efi
  00/00/00  12:00a       r       10,272  93B80003-9FB3-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r        7,936  240612B5-A063-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r       33,312  69FD8E47-A161-4550-B01A-5594CEB2B2B2.efi
  00/00/00  12:00a       r       37,888  93B80004-9FB3-11D4-9A3A-0090273FC14D.efi
  00/00/00  12:00a       r        2,048  AD70855E-0CC5-4ABF-8979-BE762A949EA3.efi
  00/00/00  12:00a       r        2,432  A9FBF34B-E2A2-41D1-BA00-A274A55CD164.efi
  00/00/00  12:00a       r       23,072  8A107CC5-DCDA-4FB7-A272-4243B41AFBFE.efi
  00/00/00  12:00a       r        2,336  E121EC07-9C42-45EE-B0B6-FFF8EF03C521.efi
  00/00/00  12:00a       r       15,296  EAF59C0E-BD46-413A-9AE9-DD9F6D1A927D.efi
  00/00/00  12:00a       r        6,720  EF17CEE7-267D-4BFD-A257-4A6AB3EE8591.efi
  00/00/00  12:00a       r        1,472  E0ECBEC9-B193-4351-A488-36A655F22F9F.efi
  00/00/00  12:00a       r       10,752  7D8355D5-5DF3-436A-82AF-5AECC7967D26.efi
  00/00/00  12:00a       r        8,224  ABA1A080-9E7B-46D1-9E14-D6629A502D79.efi
  00/00/00  12:00a       r        9,056  AABE0074-0FAB-41FD-B68C-C04DFFD1589C.efi
  00/00/00  12:00a       r        3,264  AB444A6B-A1F8-493E-83B4-F6E5071F2965.efi
  00/00/00  12:00a       r       14,304  32D0CA85-D0EB-4A9E-AAC8-FFF748F0BED8.efi
  00/00/00  12:00a       r        3,744  7FED72EE-0170-4814-9878-A8FB1864DFAF.efi
  00/00/00  12:00a       r       11,712  9CC55D7D-FBFF-431C-BC14-334EAEA6052B.efi
  00/00/00  12:00a       r       14,688  5552575A-7E00-4D61-A3A4-F7547351B49E.efi
  00/00/00  12:00a       r       16,032  95AF7E4D-C45D-47FF-AEB2-D9BC13466B3F.efi
  00/00/00  12:00a       r        8,576  0325B5A1-0937-4A4F-B8AF-EC3F80EE6B35.efi
  00/00/00  12:00a       r        6,144  F3790689-FB90-4479-A2EF-B82A43AFE74D.efi
  00/00/00  12:00a       r        5,280  9E85F0D5-5185-482B-8D50-5671307FEA80.efi
  00/00/00  12:00a       r        1,312  6A504489-884E-4465-A02F-03B248CDEF13.efi
  00/00/00  12:00a       r       27,008  662AD66E-F52D-47F6-A350-488DB9F8AF68.efi
  00/00/00  12:00a       r        3,648  508A61DC-2C57-4848-A54A-58015179C94A.efi
  00/00/00  12:00a       r        1,472  398262C1-5165-4725-87FC-BB786A972582.efi
  00/00/00  12:00a       r        2,272  AC4CE557-F5CD-439E-963C-40F09683DAC5.efi
  00/00/00  12:00a       r        4,928  BDFDE060-7E41-4EAE-AD9B-E5BBA7A48A3A.efi
  00/00/00  12:00a       r        5,056  F57D3A5E-784C-4D32-AC3E-E61E63A79E68.efi
  00/00/00  12:00a       r        4,576  93700374-6A54-4BDA-AC0B-FF87D5507A39.efi
  00/00/00  12:00a       r        9,216  AF52DEDE-C18A-47CE-82E9-F2B660C934BA.efi
  00/00/00  12:00a       r       16,576  FCD337AB-B1D3-4EF8-957C-8048606FF670.efi
  00/00/00  12:00a       r       13,408  13AC6DD0-73D0-11D4-B06B-00AA00BD6DE7.efi
  00/00/00  12:00a       r        2,592  01C069A6-794C-4BC7-BFC7-7F8BD0993825.efi
  00/00/00  12:00a       r        5,824  506533A6-E626-4500-B14F-17939C0E5B60.efi
  00/00/00  12:00a       r        7,776  9F455D3B-2B8A-4C06-960B-A71B9714B9CD.efi
  00/00/00  12:00a       r        1,440  F099D67F-71AE-4C36-B2A3-DCEB0EB2B7D8.efi
  00/00/00  12:00a       r        5,696  378D7B65-8DA9-4773-B6E4-A47826A833E1.efi
  00/00/00  12:00a       r        1,984  45424D0C-E6AF-4AF2-AD99-FA77168742D1.efi
  00/00/00  12:00a       r        3,040  2BDED685-F733-455F-A840-43A22B791FB3.efi
  00/00/00  12:00a       r        1,664  AD608272-D07F-4964-801E-7BD3B7888652.efi
  00/00/00  12:00a       r       10,560  CBD2E4D5-7068-4FF5-B462-9822B4AD8D60.efi
  00/00/00  12:00a       r        7,552  4C862FC6-0E54-4E36-8C8F-FF6F3167951F.efi
  00/00/00  12:00a       r       11,424  9FD2360E-6B48-11D5-8E71-00902707B35E.efi
  00/00/00  12:00a       r       38,912  62D171CB-78CD-4480-8678-C6A2A797A8DE.efi
  00/00/00  12:00a       r        7,488  F78153D0-870D-4EEE-A684-741499C9A8CE.efi
  00/00/00  12:00a       r        2,592  79CA4208-BBA1-4A9A-8456-E1E66A81484E.efi
  00/00/00  12:00a       r       11,872  91538AC9-A5D3-4DEF-9A70-28A087DEFA79.efi
  00/00/00  12:00a       r        1,344  07A9330A-F347-11D4-9A49-0090273FC14D.efi
  00/00/00  12:00a       r      120,544  A6F691AC-31C8-4444-854C-E2C1A6950F92.efi
  00/00/00  12:00a       r          768  F1EFB523-3D59-4888-BB71-EAA5A96628FA.efi
  00/00/00  12:00a       r        3,456  1C6B2FAF-D8BD-44D1-A91E-7321B4C2F3D1.efi
  00/00/00  12:00a       r        3,456  E763F590-0597-11DB-9CD8-0800200C9A66.efi
  00/00/00  12:00a       r          896  A62D933A-9293-4D9F-9A16-CE81994CC4F2.efi
  00/00/00  12:00a       r        1,376  CA515306-00CE-4032-874E-11B755FF6866.efi
  00/00/00  12:00a       r        2,688  53BCC14F-C24F-434C-B294-8ED2D4CC1860.efi
  00/00/00  12:00a       r        1,248  51C9F40C-5243-4473-B265-B3C8FFAFF9FA.efi
  00/00/00  12:00a       r        4,480  B601F8C4-43B7-4784-95B1-F4226CB40CEE.efi
  00/00/00  12:00a       r        2,752  BAE7599F-3C6B-43B7-BDF0-9CE07AA91AA6.efi
  00/00/00  12:00a       r           74  C3E36D09-8294-4B97-A857-D5288FE33E28
  00/00/00  12:00a       r       28,651  35B898CA-B6A9-49CE-8C72-904735CC49B7
  00/00/00  12:00a       r       23,520  4D37DA42-3A0C-4EDA-B9EB-BC0E1DB4713B.efi
        167 File(s)   1,988,580 bytes
          0 Dir(s)

I can execute the Startup Manager (the Boot Picker) using this command:
f1:\E1628C66-2A2D-4DC5-BD41-B20F3538AAF7

The list of items in the Startup Manager is different than usual because rEFInd loaded the apfs file system and the ntfs file system drivers which the Startup Manager can use to scan apfs and ntfs volumes for volume icons and EFI folders or macOS system folders.

- One thing I would add is a modified ls command so that it can show the file type of each file (application, driver, etc.). FvSimpleFileSystem knows the type for each file which is how it know which files should have the .efi extension.
- Maybe add a guid to text converter so the names of the files are more meaningful (a newer UEFI would have names for many of these which the FvSimpleFileSystem would get from the UI section of the file).
- Maybe add support for nested directories (if it's possible for one of the items to be another firmware volume).

Petri Krohn · Oct 1, 2020

EFI is not an operating system. It has no kernel nor global variables, apart from the low-level Global Descriptor Table and Local Descriptor Tables. The global context is passed to each EFI application and driver in the call parameters
ImageHandle and SystemTable.

See this example:

Code:

EFI_STATUS
EFIAPI
InitializeSetup (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  )
{
  EFI_STATUS                  Status;
  VOID                        *Registration;
  ...

EDK and GNU EFI define some global variables like gBS for Boot Services Table in EDK or ST for System Table in GNU EFI, but these variables are only global in the build environment. Executables built separately or with different toolchains have no knowledge of each other's global variables. (Besides, you need to call InitializeLib() before they even become initialized.)

This makes it possible to launch 64-bit EFI applications from 32-bit EFI code or UEFI applications from legacy EFI code. The calling application must rebuild the System Table and populate it with wrapped or hooked versions of the system functions.

Universal 64-bit UEFI application for 32-bit EFI

The executable first builds a 64-bit version of the UEFI system table. It then checks its own filename. It looks for a file named <name>x64.efi in the same folder. If its own name ends in "-ia32" it will also look for <name>.efi. It will then call the "x64" file with the same call parameters it received, passing along the 64-bit system table. Naturally it must switch between the 32-bit and 64-bit calling conventions and processor modes,

The UEFI RunTime Services table has some additional functions compared to the table used in the Mac EFI. These can be implemented based on the EDK code and included in the reconstructed system table.

I still have not looked inside the Tiamo / Piker Alpha boot.efi file. I suspect it works somewhat similarly to the description above. If not, I believe it can be modified to this new specification.

Petri Krohn · Oct 4, 2020

TL;DR

EFI implements the boot picker application and the "Setup Interpreter" IFR browser as one application they call the Boot Manager. Some of the relevant code is located in the file BootManager.c
We could use the Boot Manager application from QEMU select the boot device and access the hidden BIOS settings. If that fails, we might try to extract the boot manager application from some Intel Server Board from around 2008 and launch it from the EFI shell on a Mac.

Long version: I am trying to gain a general understanding on how the Boot Manager, the Human Interface Infrastructure and whatever Graphics Output Protocol are put together to create the boot picker and setup interfaces. So far I have found out very little.

Searching Google for "Internal Form Representation" produces only one relevant result: the Intel® Platform Innovation Framework for EFI Human Interface Infrastructure Specification Version 0.9 from September 16, 2003. I read through the text sections and it did not make me any wiser. Useless blabber about Unicode, Japanese input methods and all 65535 Unicode glyphs taking up 2.5 MB of flash space.

I then went looking for the EDK reference implementation of the setup browser IFR interpreter. There does not seem to be any.

I found this Gitbook among the EDK2 docs: UEFI Driver Wizard – Adding HII. It describes how to add Internal Form Representations to a driver. The last page gives this advice: "Invoke Qemu". Evidently QEMU has a text mode Boot Manager application that integrates the boot picker and the setup browser.

The Apple firmware does not have a separate setup browser application. The AppleEfiList.txt file only contains five applications. BootPicker.efi is the only one related to setups.

Code:

SmmCoreDispatcher.efi APP 240612B5-A063-11D4-9A3A-0090273FC18E
LegacyLoad.efi APP 2B0585EB-D8B8-49A9-8B8C-E21B01AEF2B7
SpiUtil.efi APP 5604D863-BF24-439B-BBF6-636D72036E07
PasswordUI.efi APP 9EBA2D25-BBE3-4AC2-A2C6-C87F44A1278C
BootPicker.efi APP E1628C66-2A2D-4DC5-BD41-B20F3538AAF7

I posted in the other thread about "programming" the UEFI Boot Manager. The use of the Driver#### NVRAM variables is defined in chapter 3.1.1 Boot Manager Programming of the Unified Extensible Firmware Interface Specification. See more:

Mac Pro 3,1 NVMe support + Upgrade Guide + Questions

The use of the Driver#### NVRAM variables is defined in chapter 3.1.1 Boot Manager Programming of the Unified Extensible Firmware Interface Specification. This is from page 52 of version 2.1 from October 1, 2008. Weird, that no one has thought of using the Driver#### variables before. I have...

forums.macrumors.com

I found a blog post from 2015 on the same topic: UEFI Spec Chapter 3 Boot Manager. The post is interesting, as it links directly to lines of code in the EDK2 implementation.

UEFI Boot Manager

UEFI Spec Chapter 3 Boot ManagerLet’s see how uefi spec define boot manager:

kurtqiao.github.io

Unfortunately the links to Github are broken. IntelFrameworkModulePkg has been renamed to MdeModulePkg. I found the file BdsEntry.c but the file BdsBoot.c is missing. The structure of EDK2 is constantly changing, and it is difficult to find anything. Looking around I found the file BootManager.c. The file claims to be "The boot manager reference implementation". This is the beginning of the file:

Code:

#include "BootManager.h"

UINT16             mKeyInput;
EFI_GUID           mBootManagerGuid = BOOT_MANAGER_FORMSET_GUID;
//
// Boot video resolution and text mode.
//
UINT32    mBmBootHorizontalResolution    = 0;
UINT32    mBmBootVerticalResolution      = 0;
UINT32    mBmBootTextModeColumn          = 0;
UINT32    mBmBootTextModeRow             = 0;
//
// BIOS setup video resolution and text mode.
//
UINT32    mBmSetupTextModeColumn         = 0;
UINT32    mBmSetupTextModeRow            = 0;
UINT32    mBmSetupHorizontalResolution   = 0;
UINT32    mBmSetupVerticalResolution     = 0;

As you can see, the boot manager has four different modes of operation, graphical boot picker and BIOS setup using GOP and text-only versions of the same. I also found an older version of the file online. The names of functions have been changed. InitializeBootManager() has been renamed BootManagerUiLibConstructor() and CallBootManager() is now UpdateBootManager(). The new InitializeBootManager() takes the ImageHandle and SystemTable as arguments, but the file does not define and EFI application or an entry point, as the function does not call InitializeLib(), but instead inherits the global context of ST and gBS from somewhere else.

Right now I have about 50 tabs open on my browser. Here is another file related to the boot manager: PlatformBootManager.c. I have no idea of its role and relations to the others. Here is one file from EDK version 1 from 2009 BdsPlatform.c. (Everything bookmarked? I can now close the tabs and cleanup my desktop.)

The reason I am particularly interested in accessing the Human Interface Infrastructure, is because it should enable new modes of debugging, most notably by enabling the Port 80h POST codes. Here is a more recent example of enabling debugging options: "TL;DR you will need to enable and disable undocumented settings within UEFI by flipping several bits in a UEFI variable." Yes, we too could flip bits in the Setup NVRAM variable, but doing it through a graphical user interface would be way cooler.

Questions:

Does the Apple BootPicker have a text-only mode? Would it be possible to have a text-only BootPicker even with GOP graphics cards but without proper GOP EFI drivers?
We can now call the Apple BootPicker from the command line of an EFI shell? Is it possible to pass any command line arguments to the BootPicker? What happens if you call it with a -? help argument?

Update October 6, 2020: I should have written, What happens if you call it with a -? help argument and redirect the output to a file with command like BootPicker.efi -? > output.txt >> error.txt? (Ping @joevt !)

Update December 16, 2020: The top-level application that initiates the whole Human Interface Infrastructure (HII) is called "Front Page". In EDK2 it is defined in the files FrontPage.c and FrontPage.h. The entry point function is called UiEntry(). Searching for the function name produces only one Chinese blog post and a machine translation into English. Some related GUIDs are defined in this file.

Experiment: I downloaded a version of OVMF, a port of Intel's tianocore firmware for the QEMU virtual machine. Inside the EFI image file OVMF.fd I found an UEFI application named UiApp. I extracted it into a file named UiApp.efi and placed it on a USB drive along with the EFI shell. I then booted my Mac Pro 3,1 from this drive and entered the EFI shell. I tried to launch UiApp.efi from the command line, but it only caused the Mac to freeze. I guess it might work better on a modern PC with a modern UEFI, but I have not tried it.

Update: I also tried to launch UiApp on a Asus Vivobook laptop. All I got was a black screen with a cursor. Pressing any key returned me to the EFI shell. The laptop did not offer an EFI shell, so I used to one I had on the USB drive, which is tweaked to work with old Macs, if that makes any difference.

joevt · Oct 4, 2020

Petri Krohn said:
I posted in the other thread about "programming" the UEFI Boot Manager. The use of the Driver#### NVRAM variables is defined in chapter 3.1.1 Boot Manager Programming of the Unified Extensible Firmware Interface Specification. See more:

Mac Pro 3,1 NVMe support + Upgrade Guide + Questions

The use of the Driver#### NVRAM variables is defined in chapter 3.1.1 Boot Manager Programming of the Unified Extensible Firmware Interface Specification. This is from page 52 of version 2.1 from October 1, 2008. Weird, that no one has thought of using the Driver#### variables before. I have...

forums.macrumors.com

You linked UEFI 2.1 spec from October 1, 2008. The EFI 1.1 spec might be more applicable for these old Mac Pros? At least the Driver variables existed back then.

Firmware Development Resources

Locate source code, binary modules, and other firmware resources for project platforms based on Intel® architecture.

www.intel.com

Intel® Platform Innovation Framework for UEFI Specification

UEFI specification for the Intel® Platform Innovation Framework for UEFI includes architecture, interoperability, components, and downloads.

www.intel.com

Petri Krohn said:
I found a blog post from 2015 on the same topic: UEFI Spec Chapter 3 Boot Manager. The post is interesting, as it links directly to lines of code in the EDK2 implementation.

UEFI Boot Manager

UEFI Spec Chapter 3 Boot ManagerLet’s see how uefi spec define boot manager:

kurtqiao.github.io

Unfortunately the links to Github are broken. IntelFrameworkModulePkg has been renamed to MdeModulePkg. I found the file BdsEntry.c but the file BdsBoot.c is missing. The structure of EDK2 is constantly changing, and it is difficult to find anything. Looking around I found the file BootManager.c. The file claims to be "The boot manager reference implementation". This is the beginning of the file:

Code:

#include "BootManager.h" UINT16 mKeyInput; EFI_GUID mBootManagerGuid = BOOT_MANAGER_FORMSET_GUID; // // Boot video resolution and text mode. // UINT32 mBmBootHorizontalResolution = 0; UINT32 mBmBootVerticalResolution = 0; UINT32 mBmBootTextModeColumn = 0; UINT32 mBmBootTextModeRow = 0; // // BIOS setup video resolution and text mode. // UINT32 mBmSetupTextModeColumn = 0; UINT32 mBmSetupTextModeRow = 0; UINT32 mBmSetupHorizontalResolution = 0; UINT32 mBmSetupVerticalResolution = 0;

As you can see, the boot manager has four different modes of operation, graphical boot picker and BIOS setup using GOP and text-only versions of the same. I also found an older version of the file online. The names of functions have been changed. InitializeBootManager() has been renamed BootManagerUiLibConstructor() and CallBootManager() is now UpdateBootManager(). The new InitializeBootManager() takes the ImageHandle and SystemTable as arguments, but the file does not define and EFI application or an entry point, as the function does not call InitializeLib(), but instead inherits the global context of ST and gBS from somewhere else.

Right now I have about 50 tabs open on my browser. Here is another file related to the boot manager: PlatformBootManager.c. I have no idea of its role and relations to the others. Here is one file from EDK version 1 from 2009 BdsPlatform.c. (Everything bookmarked? I can now close the tabs and cleanup my desktop.)

The reason I am particularly interested in accessing the Human Interface Infrastructure, is because it should enable new modes of debugging, most notably by enabling the Port 80h POST codes. Here is a more recent example of enabling debugging options: "TL;DR you will need to enable and disable undocumented settings within UEFI by flipping several bits in a UEFI variable." Yes, we too could flip bits in the Setup NVRAM variable, but doing it through a graphical user interface would be way cooler.

You can flip the bits in macOS or Linux:

Intel Framebuffer patching using WhateverGreen

English: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md Russian: https://www.applelife.ru/threads/intel-hd-graphics-3000-4000-4400-4600-5000-5500-5600-520-530-630.1289648/ Chinese: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.cn.md

www.insanelymac.com

Petri Krohn said:
Questions:

Does the Apple BootPicker have a text-only mode? Would it be possible to have a text-only BootPicker even with GOP graphics cards but without proper GOP EFI drivers?

We can now call the Apple BootPicker from the command line of an EFI shell? Is it possible to pass any command line arguments to the BootPicker? What happens if you call it with a -? help argument?

I showed how to launch the BootPicker from the EFI Shell in #272 (just add Fv2OnFvThunk and FvSimpleFileSystemDxe). Adding -? to the command line doesn't appear to do anything. The Boot Picker switches to graphics mode immediately.

Fv2OnFvThunk is from UDK2018 EdkCompatibilityPkg. There may be some other stuff in there to help get edk2 drivers and programs to work in the old edk environment on the Mac Pro or to make edk compatible drivers in the edk2 environment? For example, I don't think the old Mac Pro's supported PCD so there's glue for things that depend on that such as the EdkIIGlueDebugLib which I guess replaces the DebugLib from edk2. I'll be looking at that stuff to see if I can get the XhciDxe driver to work.
https://github.com/tianocore/tianocore.github.io/wiki/EdkCompatibilityPkg
https://github.com/tianocore/tianocore.github.io/wiki/Differences-between-EDK-and-EDK-II
https://github.com/tianocore/tianocore.github.io/wiki/PCD
https://github.com/tianocore/tianocore.github.io/wiki/ECP

Updating a Mac (Pro)s CPU Microcode

macrumors newbie

macrumors 604

macrumors 68000

macrumors regular

Attachments

macrumors regular

macrumors newbie

macrumors 68000

Attachments

macrumors 68000

macrumors newbie

macrumors 68000

macrumors regular

Attachments

macrumors 6502a

macrumors 604

macrumors 604

macrumors regular

Attachments

macrumors 604

macrumors regular

macrumors 604

macrumors regular

macrumors 604

macrumors newbie

macrumors 604

macrumors regular

macrumors regular

macrumors 604

Our Staff