Guide for Automatic Boot of a Mac using this Utility (WIP)

[0nelight]

THIS IS WORK-IN-PROGRESS - PLEASE FOLLOW DISCUSSION TO SEE WHAT IS WORKING TILL NOW

In case you successfully tested a manual startup of a Mac with the this EFI-Utility you may be intererested to automate booting this on every boot.

What you ask for is an so called "NSH-Script" - it is a Textfile which EFI-Shell commands in it that gets interpreted line-by-line by an EFI-Shell.

Here is how you do it:

1. Make sure you have a working EFI-Shell which you can access through rEFInd
   An EFI-Shell is a small program like the Windows cmd or powershell but for the EFI-Environment. You can download one here.

2. Create an Textfile with an .nsh extension
   Regarding the possible commands - you can refer to (Shell Command Reference Manual).

echo Running disable-ram-area.efi with Parameters
stall 1000000
fs7:\EFI\tools\disable-ram-area.efi 0x190000000 0x21000000 3000
echo Starting MacOs
stall 1000000
fs5:\5668A9CD-407D-35EB-87EB-59CD393D65B1\System\Library\CoreServices\boot.efi

3. Create menuentry in refind.conf to be able to call this NSH-File
   Regarding creating Manual Boot Stanzas.
   in loader you put the path for your downloaded efi-shell
   in options you put the path for your NSH script

menuentry "Boot MacOs with defective RAM-Area" {
    loader /EFI/tools/Shell_Full.efi
    options "dummyarg fs7:\EFI\tools\launch_macoswithdefectiveram.nsh exit"
}

4. Set this as default in rEFInd
   With the "default_selection" Token.

[daniel-nextgti]

Hi @0nelight

I`ve tried the method above. The .nsh-file is read but automatically kicks me out to the shell terminal and neither commands on the file are read by the shell.

I`ve recorded what happened in Slo-Mo, just so it could be read in time. Here are some prints:

I`ve ajusted the script to the correct paths:

And, here`s the rEFInd.config menuentry:

Any ideas why the script didn`t worked?

Thanks again,
Dan

[MeTalOneOEight]

At least the Booting MacOS path in the .nsh looks wrong.
It's pointing to an installer.
Compare it to the rEFInd entry.
Better check all paths.

[0nelight]

So the following nsh-file works for me - but only with the compiled version with the hard-coded ram-areas.
When trying with the command line arguments version of disable-ram-area.efi - then I get a hang immediately after entering it.

Here the Content of launch_macoswithdefectiveram.nsh:

echo Running disable-ram-area.efi with Parameters
stall 1000000
fs7:\EFI\tools\disable-ram-area.efi 0x190000000 0x21000000 3000
echo Starting MacOs
stall 1000000
fs5:\5668A9CD-407D-35EB-87EB-59CD393D65B1\System\Library\CoreServices\boot.efi

here the menuentry at the End of refind.conf:

menuentry "Boot MacOs with defective RAM-Area" {
    loader /EFI/tools/Shell_Full.efi
    options "dummyarg fs7:\EFI\tools\launch_macoswithdefectiveram.nsh exit"
}

Please note the first argument under options "dummyarg" you could write anything here - it is necessary for the way the EFI-Shell takes in the arguments. It throws aways the first one.

Also note we have to use backslashes in the options-line.

Please note that fs0: fs5: and so on could be different in your system. Best to navigate through them interactively to get an overview. Simply enter Shell_Full.efi via rEFInd Boot Manager and type in "help" - you will see all the commands.

Edit 1:

Added Command Line Options within the NSH File

[0nelight]

This is connected to how the Efi-Shell-App provides the command line parameters to the disable-ram-areas.efi-App.

I will think about a solution for this. Maybe I have to change the Code.

[0nelight]

So the refind-boot-manager only passes the three arguments to the efi-app while the efi-shell passes an additional parameter at the beginning - the name of the app.

so my efi-app gets 4 parameters instead of 3 which causes the error.

I will fix this asap so that the app counts how many parameters are provided and in case they are 4 the first one will be skipped :)

[0nelight]

Updated Release - Please test and tell me your results!

[daniel-nextgti]

Hello @0nelight !

Sorry for keeping you waiting for so long!
I have to thank you once again for the amazing work. The new version works perfectly with the .NSH script, and i think that we`re past validated your work on newer Intel Models. If you want, you can already update the Repository description to "Tested on Macbook Pro 2019 16'"

Is there a way to contribute to you? I saw a link donation on you profile. Does that help you?

Thanks,
Dan

[0nelight]

Hello @daniel-nextgti,

Great to hear 😃
I will add this to the Repository description 😎

I feel very flattered that you want to donate something to me—certainly every euro/dollar is helpful!

Although I can't judge the authors and their frugality and efficiency in terms of donations—if you look at the two much larger projects, namely memtest86+ and rEFInd, which this project depends on, it would be nice to donate part of it there as well!

Find my donations-page for this project here.
Refind has their Donations-Button on the top of its page.
memtest+ has it on the bottom of its page (altough it seems deactivated right now).

Keep in mind that I will do my best to keep this tool working, but you never know what Apple does in terms of EFI-Firmware Updates over the next years 😬 😃

In case Apple really cares about reducing E-Waste and protecting the Environment - I am sure they will not block this hidden feature of macOs in the future.

Thanks,
0nelight

[0nelight]

Regarding finding the right paths.

[adrian77]

Hi. Good work. It helped me to isolate away 32MB of bad memory from the OS.

There seem to be a way to permanently reserve the memory for firmware instead of re-setting it on every reboot by changing following:
from:
Status = uefi_call_wrapper(BS->AllocatePages, 4, 2, 8, NumPages, &Addr);
to
Status = uefi_call_wrapper(BS->AllocatePages, 4, AllocateAnyPages, EfiRuntimeServicesData, NumPages, &Addr);

This change tells UEFI to allocate the memory as EfiRuntimeServicesData, a type that can persist after the OS takes control, giving you a better chance of keeping this memory reserved during the macOS boot. However, it’s not guaranteed that macOS will respect this memory reservation unless further configuration is done at the OS or bootloader level.

I will try it and let you know if this works for me (MacBook Pro 16" 2019).

[adrian77]

It seems that the change of code did not persist after reboot. Not only macOS did not respect it, but also Memtest86 keep on hitting into bad memory segments.

[0nelight]

Happy this works for you too 😃

AllocatePages is not persistent across reboots. It is possible to write something to NVRAM area, but this doesn't help us regarding telling macOs on every boot: "hey don't touch Ram Area X to Y".