Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Accessing the hidden MP3,1 BIOS setup utility?
- Thread starter lnx64
- Start date
- Sort by reaction score
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?
Last edited:
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
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.
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.
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.
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.
How to launch the built-in Duet BDS efi module?
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 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 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.
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.)
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 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 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.)
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.
Last edited: