UEFI Shell

I am confused about UEFI shells. I think I understand the UEFI boot process, but I need to update a card using a UEFI flash process. I'm on 13.1 amd64 with an ASUS motherboard. The ASUS firmware has an option to boot to a UEFI shell. Is loader.efi (which exists as /boot/efi/efi/boot/bootx64.efi, among other places) a UEFI shell or does it just function as a loader? Do I need to download a UEFI shell and put it in /boot/efi/efi/boot/shellx64.efi? (or actually build a USB memstick with the same).

Can anyone explain all this, or point me to an explanation?

Thanks in advance.
 
Not all UEFI systems have the shell.


They can be useful if you have any unusual booting requirements but not something you’d probably need that often.
 
UEFI shell is a shell of a firmware (BIOS in PCs). It resembles a bit of a DOS prompt. It has nothing to do with any OS or their loaders.

Usually what you do is you boot to the prompt or you select to boot to this shell via BIOS menu. Once you are there you have few built-in commands to look around. help or alike command should give you a list. map gives you a map of devices.

But even if you do this blindly, let's say you have FAT32 USB key with all your firmware. Doing fs0: will try to "cd" to this FS. If not try fs1: and so on.
Once you changed to the USB you can execute whatever you need to upgrade the FW on the card. Almost always you have these commands in README or similar file attached to a fw.
 
Some flashers even use a script to execute the flashing under EFI.

startup.nsh
storcli.efi /c0 download file=HBA_9400-8i_Mixed_Profile.bin
 
Okay, thanks a bunch for the replies, although at least one of my questions was not answered, but still very helpful. Here are my take a ways:

1. No, loader.efi is not a UEFI shell. It just loads!
2. A UEFI shell, at least on modern mobos, is provided by the mobo.
3. To update a UEFI card, put all the required data and UEFI flash programs on a USB in a FAT32 efi gpt partition, and reboot to the mobo UEFI shell. Then flash the card!

Sound right? And thanks again.
 
A UEFI shell, at least on modern mobos, is provided by the mobo.
Not always included though, or may be an older version. But you can download a full UEFI shell here: https://github.com/tianocore/edk2/releases/
Save it on the efi partition, if you use rEFInd store it as EFI/Tools/Shellx64.efi then rEFInd will automatically detect it and you can start the shell from the rEFInd boot menu.
 
I thought I'd put this one to bed. I downloaded a pre-built ISO with several of the UEFI shells for various CPUs and split out the AMD64 version named bootx64. I then took a memstick, created a GPT geom on it, added an efi partition, formatted it as a FAT32 filesystem, mounted it temporarily, created the directory efi/boot on the filesystem, and copied the downloaded bootx64 into that directory. That memstick shows up as bootable on my UEFI motherboards and booting it comes up as a UEFI shell.

I was able to upgrade several SAS cards with that shell and a UEFI flasher for the cards. All of this seems very nice and was easy to do.

Rick
 
I am confused about UEFI shells. I think I understand the UEFI boot process, but I need to update a card using a UEFI flash process. I'm on 13.1 amd64 with an ASUS motherboard. The ASUS firmware has an option to boot to a UEFI shell. Is loader.efi (which exists as /boot/efi/efi/boot/bootx64.efi, among other places) a UEFI shell or does it just function as a loader? Do I need to download a UEFI shell and put it in /boot/efi/efi/boot/shellx64.efi? (or actually build a USB memstick with the same).

Can anyone explain all this, or point me to an explanation?
What loader.efi is
/boot/efi/efi/boot/bootx64.efi (or /boot/loader.efi in FreeBSD) is FreeBSD’s bootloader, not a UEFI shell.
It’s the program UEFI calls to start loading FreeBSD’s kernel and system — similar to GRUB or Windows Boot Manager.
So:
loader.efi = FreeBSD bootloader (not an interactive shell).
2. What a UEFI Shell is
A UEFI Shell is a small command-line environment built for UEFI itself — kind of like a “mini-OS” that runs before any operating system.
It lets you:
Run .efi applications directly
Flash firmware
Change NVRAM boot variables
View UEFI devices, partitions, etc.
It’s completely separate from FreeBSD or any OS loaders.
3. How to get and use one
If your ASUS firmware has a “Launch EFI Shell” option, it expects to find a file called shellx64.efi in a standard path, for example:
/efi/boot/shellx64.efi
To use it:
Download the UEFI Shell binary from a trusted source, e.g.
Tianocore EDK2 Shell (official UEFI project)
Rename it to shellx64.efi.
Put it on a FAT32 USB stick in the path:
\EFI\Boot\shellx64.efi
Boot from that USB, or use your BIOS “Launch EFI Shell” option.
That gives you the interactive UEFI command prompt you can use to run firmware utilities, including flash tools.
In short:
loader.efi = FreeBSD’s bootloader (not a shell).
shellx64.efi = actual UEFI shell, downloaded separately.
Place it on a FAT32 USB at \EFI\Boot\shellx64.efi and boot to it to run UEFI commands or firmware flash tools.
 
I don't disagree with any of that but I do believe some boards have "shell64.efi" baked in and some don't. Not just EDK2 based boards either.

Not all UEFI systems have the shell.
Totally Agree.

Some boards when they fail to find a bootable EFI device they present a UEFI shell.
Unlike legacy/csm BIOS mode where it messages "Can't Find Boot Device. Hit any key to reboot"
 
My UEFI machines don't support a UEFI CLI shell. There's only the GUI. They get nasty when they cannot find a bootable system. As my systems are clones of my standard install I cloned from one of my non-UEFI machines, creating the EFI partition myself, then booting using the "FILE" selector in the UEFI shell GUI. It "remembers" the setting. Never had a problem since.
 
loader.efi = FreeBSD bootloader (not an interactive shell).
Well, the FreeBSD loader(8) is a kind of shell. The entire boot menu is a script that runs in this shell. You can drop to loader prompt from the boot menu or interrupt the boot process and you are in a shell/CLI like environment. Originally it was Forth but they switched to LUA with FreeBSD 12.0.

Originally loader(8) was stage 3 of the boot process. But with UEFI and the efi boot partition stage 1 and 2 became somewhat obsolete.

 
Before UEFI bootcode functionality is implemented in loader.efi, boot1.efi was the UEFI bootcode and loader.efi was OS loader kicked by boot1.efi in previously mentioned UEFI spec.

Currently, loader.efi works as both UEFI bootcode and OS loader in single binary.
 
Back
Top