Jump to content
21 posts in this topic

Recommended Posts

Hello all,

 

I have written a simple EFI-based boot menu for Intel Macs. It is called rEFIt and is available at refit.sourceforge.net. The distribution also contains a copy of the EFI shell and some tools. It is already in use on the Ubuntu Linux Live CD produced by the mactel-linux project.

 

I hope that the rEFIt project will serve as an open platform for EFI-space components developed to boot Windows XP and other pre-EFI operating systems.

Link to comment
https://www.insanelymac.com/forum/topic/11354-announce-the-refit-boot-menu/
Share on other sites

Are you planning to add it some stuff like a pre-loaded CSM module, bios-based drivers and so...?

That will be great !!

I do not have the time or skill to develop a CSM myself. But when someone develops and releases one, I plan to integrate it into rEFIt and add the appropriate loading infrastructure.

Christoph (or may i call you chrisp? ;-), I'd like to congratulate you on your eminent achievement! Out of curiosity, I'm wondering:

 

* What existing code did you use as a base for rEFIt (elilo, Tiano, etc) - assuming you didn't just write it up on a napkin in the wee hours...?

 

* What was the critical step to make rEFIt boot to a visible state whereas loading anything from Intel/Tianocore (even with your initial effort, TextMode.efi) would not (on the MBP, mind you)?

Out of curiosity, I'm wondering:

 

* What existing code did you use as a base for rEFIt (elilo, Tiano, etc) - assuming you didn't just write it up on a napkin in the wee hours...?

 

rEFIt (the boot menu itself) was mostly written from scratch, using the EFI spec and the samples from TianoCore and Intel's EFI Application Toolkit for reference. I took a brief look at elilo initially, but it uses gnu-efi as its build environment and I couldn't get that to compile working binaries, so I put it away.

 

The shell and other tools are taken straight from the TianoCore and EFI Application Toolkit packages (both BSD-licensed).

 

* What was the critical step to make rEFIt boot to a visible state whereas loading anything from Intel/Tianocore (even with your initial effort, TextMode.efi) would not (on the MBP, mind you)?

 

It's still the ConsoleControl stuff also used in TextMode.efi, 4 lines of code. Note that the ConsoleControl protocol (implemented by the ConsoleSplitter driver) is not part of the EFI spec, but comes from Intel's Framework implementation / TianoCore.

 

The problem on the MacBook Pro is that apparently Apple has changed its custom code. TextMode.efi just switches the console mode, then passes control back to the built-in boot manager. On an iMac, you get dropped into Intel's menus in that case, and you stay in text mode. On the newer models, Apple's custom code catches that situation and continues either with Apple's volume chooser or the OS X boot loader. (Don't know exactly which one since I don't have a MBP yet.) Both of these switch the console back to graphics mode. You get the same behaviour when you choose "Exit to built-in Boot Manager" in the rEFIt menu.

 

BTW, it should be possible to get into text mode without rEFIt. You'd need to set Shell.efi as the boot loader and write a startup.nsh script that calls TextMode.efi. The difficult part is putting those files in locations where the shell will find them...

rEFIt (the boot menu itself) was mostly written from scratch, using the EFI spec and the samples from TianoCore and Intel's EFI Application Toolkit for reference. I took a brief look at elilo initially, but it uses gnu-efi as its build environment and I couldn't get that to compile working binaries, so I put it away.

 

The shell and other tools are taken straight from the TianoCore and EFI Application Toolkit packages (both BSD-licensed).

 

Neat! If I had a multi-million dollar company with a vested interest in EFI development, I'd hire you no questions asked... :)

 

It's still the ConsoleControl stuff also used in TextMode.efi, 4 lines of code. Note that the ConsoleControl protocol (implemented by the ConsoleSplitter driver) is not part of the EFI spec, but comes from Intel's Framework implementation / TianoCore.

 

The problem on the MacBook Pro is that apparently Apple has changed its custom code. TextMode.efi just switches the console mode, then passes control back to the built-in boot manager. On an iMac, you get dropped into Intel's menus in that case, and you stay in text mode. On the newer models, Apple's custom code catches that situation and continues either with Apple's volume chooser or the OS X boot loader. (Don't know exactly which one since I don't have a MBP yet.) Both of these switch the console back to graphics mode. You get the same behaviour when you choose "Exit to built-in Boot Manager" in the rEFIt menu.

 

BTW, it should be possible to get into text mode without rEFIt. You'd need to set Shell.efi as the boot loader and write a startup.nsh script that calls TextMode.efi. The difficult part is putting those files in locations where the shell will find them...

 

Ah, this explains a few things, thanks for clearing that up. Blessing TextEdit on a MBP will indeed produce a flash of blackness, then continue to load the OS.

 

Loading TextMode through the Shell is probably the only permutation of EFI tricks I (think I) did not try... Now, rEFIt makes it mostly unnecessary, but I'll give it a shot for completeness' sake.

And right you are - it works.

 

I'll be sure to play some more with rEFIt and drop feedback through sourceforge. If you need some independent testing (MBP or otherwise), just let me know...

 

For general reference, these are the steps required for booting directly into the EFI shell on any stock intel Mac. All that's needed is a copy of rEFIt (or TextMode.efi + a Shell.efi from Intel/TianoCore).

 

Using USB stick partition named Efi:

- insert USB stick

- mount rEFIt.dmg

- drag contents of rEFIt to Efi

# echo "TextMode" > /Volumes/Efi/startup.nsh

# bless --mount /Volumes/Efi --file /Volumes/Efi/efi/refit/apps/Shell.efi --setBoot --nextonly

# reboot

 

Using hidden FAT partition:

# hdiutil attach /path/to/rEFIt.dmg (or mount in Finder)

# mkdir /efi

# mount_msdos /dev/disk0s1 /efi

# cp -r /Volumes/rEFIt/* /efi/.

# echo "TextMode" > /efi/startup.nsh

# bless --mount /efi --file /efi/efi/refit/apps/Shell.efi --setBoot --nextonly

# reboot

 

In either case, wait for the white screen, then press any key (or wait 5 seconds) to drop into the EFI shell.

Could you please post a few pictures of the graphical boot menu?

Just wondering what it looks like, compared to the one blanka made-

 

Here's a screen shot. Sorry for the bad quality, that's what you get with a top-of-the-line Sony Ericsson P-series...

post-27418-1142754382_thumb.jpg

rEFIt (the boot menu itself) was mostly written from scratch, using the EFI spec and the samples from TianoCore and Intel's EFI Application Toolkit for reference. I took a brief look at elilo initially, but it uses gnu-efi as its build environment and I couldn't get that to compile working binaries, so I put it away.

 

 

The linker script in the GNU environment discards some important information. To produce working executables, add

*(.gnu.linkonce.*)

somewhere in the linker script's .data section. Mine works with it located here:

*(.sdata)

*(.gnu.linkonce.*)

*(.got.plt)

 

Trying to return from efi_main also fails for me. I instead use:

BS->Exit( image, EFI_SUCCESS, 0, NULL );

Thanks for that tip, Joshua! That lets me produce working binaries on my Debian system. Anyway, I've found that there are lots of different linker scripts floating around, and no two are exactly the same... Ubuntu and Gentoo both have working (that is, patched) gnu-efi packages, but for Debian even the 3.0c package in unstable does not work as is.

 

Anyway, I've toyed around with elilo a bit and submitted a patch on the SourceForge project that switches to text mode. So with that patch, elilo can be blessed and it will work, no rEFIt or ebounce.efi required.

 

I only found out later that Ubuntu also has a patch for elilo that adds console switching and also passes the display resolution to the kernel. I just hope this whole mess of patches clears up some time...

  • 2 years later...
Hello all,

 

I have written a simple EFI-based boot menu for Intel Macs. It is called rEFIt and is available at refit.sourceforge.net. The distribution also contains a copy of the EFI shell and some tools. It is already in use on the Ubuntu Linux Live CD produced by the mactel-linux project.

 

I hope that the rEFIt project will serve as an open platform for EFI-space components developed to boot Windows XP and other pre-EFI operating systems.

 

I love rEFIt.... unfortunately I was just informed by Apple that using rEFIt voids the part of my warrant which covers my logic board and wireless card (and some other things, but those are the biggies) because it modifies the boot sequence.... so sadly I will be uninstalling rEFIt.

 

Please make other Apple users (maybe a note in the README?) so they don't get a nasty surprise...

Way to pull up a thread that is from the grave....

Any sources for this claim (who or what part of "apple" told you this?) that the use of software that loads after initial EFI boot has completed when the rEFIt menu loads?

This is just like any other boot loader that gives the choice of several options.

  • 3 weeks later...
  • 10 months later...

I would just like to update the path to the shell as mentioned near the start

 

Using USB stick partition named Efi:

- insert USB stick

- mount rEFIt.dmg

- drag contents of rEFIt to Efi

# echo "TextMode" > /Volumes/Efi/startup.nsh

# bless --mount /Volumes/Efi --file /Volumes/Efi/efi/tools/shell.efi --setBoot --nextonly

# reboot

 

It used to say /Volumes/Efi/efi/refit/apps/Shell.efi which doesnt exist in the rEFIt 0.13 download...

×
×
  • Create New...