Does '/boot/efi' locate in Memory as ROM

Question

I learned from the book Computer Science: An Overview that boot loader resides on Memory

In a general-purpose computer, a program called the boot loader is perma- nently stored in the machine’s ROM. This, then, is the program that is initially executed when the machine is turned on. The instructions in the boot loader

However, in other book, it state that the boot loader is located on hard disk.

As for BIOS

the boot process begins with the BIOS. As described in Chapter 3, you tell the BIOS which boot device to use—a hard disk, a USB stick, a CD/DVD drive, or something else. Assuming that you pick a hard disk as the primary boot device (or if higher-priority devices aren’t bootable), the BIOS loads code from the Master Boot Record (MBR), which is the first sector on the hard disk.

for UEFI

In order to work, the EFI must know about the boot loaders installed on the hard disk’s ESP.

Put my question in another way

me@host:~$ df -h | grep 'boot'
/dev/sda1       511M  7.3M  504M   2% /boot/efi

Does the /boot/efi locates as ROM in Memory?

Answer 1

No, the /boot/efi is a filesystem on the system disk, typically a FAT32 filesystem.

The terminology here is far from uniform: your first book takes the view that the part of BIOS that handles the selecting the disk to boot from and loading the first stuff from the disk is the bootloader... or at least the primary one.

In BIOS firmware, the primary bootloader embedded in the firmware has very limited capabilities: it essentially just reads one block from the beginning of a disk and then executes it.

In UEFI firmware, the primary bootloader is way more capable: it understands FAT32 filesystems (and optionally may understand other filesystem types also), and so it can load a specified file from a specified filesystem, or from a standard fallback file from any supported filesystem; for 64-bit x86 systems, the standard fallback file pathname is \EFI\BOOT\BOOTx64.efi.

Your other book glosses over the BIOS component of the boot process, and focuses more on the second part of the boot process: the on-disk bootloader, which can be (but does not have to be) specific to the operating system being booted. This could be called a secondary bootloader, if you need to talk about both it and the in-firmware primary bootloader. But if you are not talking about the internals of the system firmware, it is common to refer to the on-disk secondary bootloader as just "bootloader" also.

For an alternative terminology, let me describe how HP-UX did it on PA-RISC hardware:

• the firmware was known as PDC.
• the PDC firmware included an in-ROM bootloader routine called IPL, or Initial Program Loader. As the name implies, its job was to just load and execute a single program.
• the first program loaded from disk by the IPL routine was called ISL, or Initial System Loader. Its job was to load the actual operating system kernel. It actually first loaded yet another module, HPUX which dealt with loading the actual HP-UX kernel.

Since firmware can be hard to update, splitting the bootloader into multiple components like that makes it easier to change the structure of the operating system kernel if required by development innovations: only the relatively small (secondary) bootloader (ISL) absolutely needs to conform to the firmware API requirements. Any subsequent components can be reprogrammed to do things completely differently if necessary.