MP 1,1-5,1 Accessing the hidden MP3,1 BIOS setup utility?

[startergo]

The EFI module is a driver, so it cannot directly be launched as an application. We still do not know how to start this.

Actually this is the intent:

• When you use bless to set the boot file to an EFI driver (like the GraphicsConsole.efi driver as per the Nakfull Propaganda instructions), then the file will be loaded, but control will return to the EFI firmware because it is not an application. At this point a built-in boot menu is displayed, and on the first keypress the console is switched to text mode so you can see it. (Note: It appears that this no longer works on the Mac Book Pro.)
• Using TextMode.efi (a small EFI application) instead will switch the console to text mode immediately and return to the built-in boot menu without requiring a key press.

More on the graphical boot volume chooser:

• It displays any "blessed" volume on any available disk, including external USB and FireWire hard disks, USB flash memory disks, flash memory cards in USB card readers, and CD/DVD drives.
• It supports HFS+ partitions on disks formatted with GPT, Apple Partition Map, and even MBR.
• Apparently it doesn't support FAT partitions at all, because it looks at the info in the HFS+ volume header placed there by bless. You can use FAT only for the default boot volume (see above).
• El Torito is supported as well, but the boot image must contain a HFS+ file system to show up in the chooser. It appears that some kind of partition table (e.g. an Apple Partition Map) is also required; this might be a minor issue caused by the sector size. (Note: This no longer works with the firmware updates for Boot Camp. Details are still under investigation.)
• Displays the volume icon as set in the Finder's "More info" dialog. (NTFS partitions will always display the generic disk icon because the firmware can't read that file system.)
• The volume name label displayed is taken from a pre-rendered graphics file. It can be controlled through bless options, but the --label option is broken in current versions.

OSx86 Project | InsanelyMac

wiki.osx86project.org

 

[Petri Krohn]

If it is an efi driver it can be extracted with the same EFI tool, renamed .efi and loaded with rEFInd/RP/OC as a driver for testing

The 2006 iMac 4,1 has a 32-bit EFI. RP/OC are 64-bit only, but rEFInd has/had a 32-bit version. One could also try to load the DuetBds efi driver with Driver#### variables on a Mac Pro 1,1. But what would happen then?

 

[startergo]

The 2006 iMac 4,1 has a 32-bit EFI. RP/OC are 64-bit only, but rEFInd has/had a 32-bit version. One could also try to load the DuetBds efi driver with Driver#### variables. But what would happen then?

rEFIt uses combined binaries, which can be split in 2: 32 and 64 bit one's. @joevt can shed more light about this.

 

[joevt]

rEFIt uses combined binaries, which can be split in 2: 32 and 64 bit one's. @joevt can shed more light about this.

No need to split them on an 32 bit EFI Mac (or any Mac?) since it should know how to run a FAT EFI binary.
http://refit.sourceforge.net/info/fat_binary.html

efilipo is used to combine the EFI binaries:
https://sourceforge.net/p/refit/code/HEAD/tree/trunk/refit/efilipo/efilipo.c

There's a python script to split the EFI binaries:
http://ho.ax/posts/2012/02/carving-up-efi-fat-binaries/

About the hidden bios utility, here's a script to find all the IFRs and output the offset of all the variables and a method to get the variables from in macOS (and maybe you can set them without using the bios utility, unless there's a checksum on the Setup variable?)
#252

To run the bios utility, I would try using the EFI Shell. Load FvSimpleFileSystemDxe, and Fv2OnFvThunk from disk which then gives access to most of the EFI items in the firmware. Then you can try loading the bios utility from the exposed firmware volume.
#272

 

[Petri Krohn]

Adding NVMe and APFS drivers from Duet BDS menu

The WinRAID forum has spent the last 7 years trying figure out how to boot Windows from a NVMe drive on older PC motherboards that do not have the NVMe EFI drivers in their firmware. They have tried creating custom firmwares for the PCs and come up with multiple ways of adding NVMe support without modding the "BIOS". Yet in all these years no one has come up with the simplest and most obvious solution: Using the firmware's setup interface to simply add the needed EFI drivers to the boot sequence.

EFI stands for Extensible Firmware Interface. The whole point of the specification is to enable the user to extend the firmware by adding new drivers and functionality. Unfortunately no end user was ever figured out how to extend EFI!

Many PC motherboards use some derivative of the Duet Boot Device Selection (Duet BDS) interface (GUID: A6F691AC-31C8-4444-854C-E2C1A6950F92) for firmware setup. It may be that many manufacturers have deleted the "Driver Options" settings from their firmware. It is however present in the "Calistoga" version of Duet BDS that shipped with early Intel Macs, including the Mac Pro 3,1.

Martin Nobel (YouTube) posted this on the Low End Mac Facebook group today. It shows a iMac 4,1 displaying the Duet Boot Device Selection interface. He says he downgraded his iMac to IM41_0039_00B.fd from Firmware Restoration CD 1.7, after first intentionally corrupting his firmware. He was able to enter the Duet BDS by starting a EFI shell and exiting it.

On Martin Nobel's video the "Boot Maintenance Manager" submenu has both "Boot Options" and "Driver Options" settings.

The boot and driver options work by adding Boot#### and Driver#### variables to the NVRAM. For the drivers to be loaded, they have to be stored in an EFI partition of some hard drive that can be natively read by the firmware.

@joevt has created scripts that can be used to add the necessary Driver#### variables to NVRAM. These may be challenging to use for most Mac users. It would be nice if this could be done through a setup menu. There are however multiple other ways of adding NVMe and APFS support for older Macs.

 

[Petri Krohn]

How to launch the built-in Duet BDS efi module?

The EFI module is a driver, so it cannot directly be launched as an application.

Martin Nobel said he crated his video by first downgrading the firmware on his iMac 4,1 to the earliest version by using the Firmware Recovery CD. He then somehow entered an EFI shell and exited it.

Christoph Pfisterer explains in A Brief History of Apple and EFI:

The first firmware revisions actually had the generic text-based configuration menus aimed at PCs still in there, and you could access them by setting the boot loader to any EFI binary that would exit and return to the firmware (rather than staying running or loading an OS). Apple quickly removed this, because people were bricking their iMacs.

The Nakfull Propaganda blog post from January 2006 Says they launched Duet BDS by blessing a downloaded copy of GraphicsConsole.efi as the boot target. GraphicsConsole.efi is another driver, so it should not be possible to launch it as an EFI application. There is also a version of GraphicsConsole.efi included in the Mac firmware.

What is the EFI application that would call Duet BDS?

One "Drive-By Comment" on the blog claims this:

This is not "getting into the EFI menu" on a Macintosh.

This is "Running Intel-supplied EFI applications" on a Macintosh. The menu you've shown there is not part of the Mac firmware, it's part of the GraphicsConsole.efi program.

Likewise the shell you describe executing is from the download, not part of the Mac software.

This comment is obviously wrong, as we can find the string "Intel Mobile Calistoga CRB Framework Implementation" in the Mac firmware, but it is not present in any of the downloaded EDK modules.

EFI version 1.10.14.62

Wikipedia says that Intel ceased its development of the EFI specification at version 1.10 in July 2005. The first Intel iMacs were released on January 10, 2006. The blog post is from January 18, 2006. The blog post contains a link to an Intel page to download EFI sample implementation source code version 1.10.14.62. This must be the last version of EFI 1.10. The page is no longer online and can only be found on the Internet Archive. The download is behind a form, so it no longer works.

Fortunately I found the zip files elsewhere on the Internet Archive.

Intel EFI Toolkit 1.10.14.62 : Intel : Free Download, Borrow, and Streaming : Internet Archive

Intel EFI Toolkit 1.10.14.62 and sample code from intels old ftp site.Archived by Winocm at https://github.com/winocm/efi_samples and mirrored here

archive.org

The blob contains both the source code and the precompiled EFI binaries. These could be very useful on a Mac Pro 1,1/2,1.

(The problem with tianocore is that they do not produce binary releases, only source code. Everyone who wants to use the source must build his own toolchain. This has driven many users to use bloated alternative tianocore-based releases, like Refind and even the "Hackintosh" Clover on ordinary PCs.)

 

[Dayo]

Everyone who wants to use the source must build his own toolchain. This has driven many users to use bloated alternative tianocore-based releases

TianoCore is actually the name of an organisation created by Intel and the product they produce is EDK II; which is the EFI Development Kit (Version 2).

As the product name suggests, it is not a toolchain you need to build, but a library (basically an SDK) that provides functionality that your source code hooks into. That is, it is an extension of source code and must hence be distributed in source form.

This development kit provides prewritten functions etc (already specced correctly) that can be called and used without having to learn the entire UEFI spec and write everything related from scratch.

It does not matter how much code is in such a dev kit, as only what is actually being used by the code hooking in will be linked/compiled by the actual toolchain. That is, there is no bloat happening as a result of it coming in source form.

You can set a variety of actual toolchains, XCODE/CLANG/GCC etc, to build your binary by linking your source to required bits of EDK II and compile this. These toolchains are of course provided as compiled programs.

It offers a lot of flexibility as various EDK II based packages can be added to the base library (which is made up of a set of packages) and their functionality called in the same way the base functionality is called. RefindPlus for instance, is able to leverage some OpenCore functions having dropped this as a separate package into a base EDK II package.

Summary: TianoCore's EDK II is not a toolchain but a dev kit for UEFI applications, similar to Software Development Kits for Operating System applications. While likely possible, you never actually want to compile the whole of EDK II (probably quite a hefty amount of MB compiled) but your source code, which links into as much of EDK II as it needs (typically a few KB compiled). That is, only what is actually linked makes it into the output binary created by a toolchain (compiler) which can be one of several.

You can extend/amend EDK II as you need to ... same as your source code. So, you can add other packages using EDK II to the base package and hook into funtionality already coded and not have to reinvent those wheels. Only the specific functionality hooked into will be in the output binary as mentioned.