0

I have never been comfortable with drivers, am just now learning about UEFI, and am trying to understand how much UEFI creates its own operating system with this example.


When I boot a modern Windows 10 system (which therefore uses UEFI) with a USB drive, I believe the motherboard EFI controller communicates directly with the USB controller until it eventually gets "BOOTX64.EFI" code in RAM, and it then starts the CPU. (I probably should at least write "effectively starts" - Please forgive my oversimplified explanations.)

Then, if that EFI code is specially-designed to use the USB port, the CPU (instead of the EFI controller) does the communication work. USB drivers for this can all sit in the EFI partition, so let's say they are not associated with Windows.

Then, if that code ultimately boots Windows (located on a second partition on the USB drive), Windows' USB drivers will ultimately get used.


So, can we really have these 3 distinct USB modes? To highlight the differences, let me call them "No CPU", "CPU for UEFI", and "CPU for Windows".

Normally, "CPU for UEFI" is ignorable (because "BOOTX64.EFI" is the Windows boot program), so I wonder if maybe this mode is completely killed in favor of "No CPU" (generated by some call from the CPU to the EFI controller).

1

When I boot a modern Windows 10 system (which therefore uses UEFI) with a USB drive, I believe the motherboard EFI controller communicates directly with the USB controller until it eventually gets "BOOTX64.EFI" code in RAM, and it then starts the CPU. (I probably should at least write "effectively starts" - Please forgive my oversimplified explanations.)

There is no such thing as "EFI controller". EFI is a type of the main system firmware and it runs on the same CPU as the actual OS. The CPU and RAM will have already been fully initialized and running by the time you see any sort of text or graphics coming from EFI.

At that point, the EFI firmware even works very similarly to an OS: it has a kernel which runs on the CPU; it uses the entire system RAM; it has a driver framework (allowing it to access USB devices, SATA devices, NVMe devices); it can read files from filesystems and it can launch executables (.efi files).

So in most cases you're dealing with two modes: either the USB stick is accessed by UEFI, or it's accessed by Windows. (Though I've seen some motherboards have some "pre-UEFI" USB support, used to recover from botched firmware upgrades when the firmware ROM is damaged.)

CPUs do have an internal controller which handles the most basic system initialization e.g. Intel calls it the "Management Engine", but it doesn't actually boot the main OS directly, it only boots the UEFI firmware.

USB drivers for this can all sit in the EFI partition, so let's say they are not associated with Windows.

No, the EFI partition usually doesn't contain any of that stuff. Most drivers, especially those necessary to deal with the motherboard's built-in hardware, are directly embedded in the main firmware image that's kept in your motherboard's flash memory.

(EFI does actually have a facility for loading external drivers from the EFI partition, but that's very rarely used in comparison. It could be used to load a filesystem driver, for example, giving EFI the ability to load files from an NTFS partition.)

| improve this answer | |
  • EFI is same as BIOS, it's low-level code bridging the middle- and high-level code the OS will load in RAM when it starts. EFI is supposed to be read-only unless you flash your EFI chip with new code. It doesn't really contain drivers, just snippets of firmware the components and peripherals need to power up and communicate with the motherboard, the chipset, the CPU and RAM, on up to Windows loading in memory. Then it just stops, because it's only needed when you boot up. – user1019780 Jun 16 at 16:09
  • @user1686 Thanks, I see only your two modes now (and I see that EFI/BIOS firmware indeed uses the CPU). Just to confirm: Through software alone (i.e., coding any bits on a drive, even bits inside the EFI partition, even calling functions which are inside the EFI partition), one can't use the "USB stick is accessed by UEFI" mode, right? I have mistakenly been thinking that one UEFI benefit over BIOS was that software, at least at power-up, could get UEFI IO capabilities without needing Windows. – bobuhito Jun 16 at 17:41
  • 1
    @bobuhito: If you're writing an OS bootloader (an .efi program), then yes, you can make use of all EFI Boot Services -- filesystem access, network access, timers, graphics, and so on. Though it is not meant to be an all-purpose platform for writing software that doesn't require Windows (if that's what you need, then write for Linux instead), but it does make writing a bootloader a bit easier. – user1686 Jun 16 at 18:40
  • 1
    @Didier: No, the specification actually calls them "drivers" -- they're just not Windows drivers or anything. They're used by UEFI itself. For example, here's a third-party filesystem driver pack. (As for stopping... there are EFI Runtime Services as well. For example, when the OS wants to access the "boot order" variables, it calls into the EFI 'variable services' functions.) – user1686 Jun 16 at 18:43
  • 1
    @Didier EFI is basically an OS (besides being firmware). Not a general-purpose one, but still. It can load drivers for devices, filesystems etc. It can execute binaries (I've seen a tech demo showing a web browser running in UEFI). I don't find your definition of a driver requiring it to be "dynamic" reasonable. It's an unnecessary requirement. Driver is just an interface between hardware and OS and I don't feel the need to make the definition more restricted. It's a bit too strict already, since the word "driver" is also used in embedded systems for hardware-firmware interfaces. – gronostaj Jun 18 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.