Talk:Booting

External links add

Hello!

I want to add link to article. It's strict about topic (change boot order and boot from removable device). Also article is well written and has a lot of pictures. It's very close to article on link which already has "Change the Boot Order in BIOS", but I think it digs more deeply and give a lot of examples, therefore it's more useful.

Link: https://123qweasd.com/blog/tech/how-to-boot-from-flash-drive-ultimate-guide/

The FreeBSD Booting Process

Loading a kernel
Determine the root filesystem
Initialize user-land things
Interesting combinations

— Preceding unsigned comment added by Keyvan amel (talk • contribs) 10:50, 7 July 2006‎

Names of bootloading stages and number of those stages

Booting § First-stage boot loaders says

Examples of first-stage (hardware initialization stage) boot loaders include BIOS, UEFI, coreboot, Libreboot and Das U-Boot. On the IBM PC, the boot loader in the Master Boot Record (MBR) and the Partition Boot Record (PBR) was coded to require at least 32 KB (later expanded to 64 KB) of system memory and only use instructions supported by the original 8088/8086 processors.

and Booting § Second-stage boot loaders says

Second-stage (OS initialization stage) boot loaders, such as shim, GNU GRUB, rEFInd, BOOTMGR, Syslinux, and NTLDR, are not themselves operating systems, but are able to load an operating system properly and transfer execution to it; the operating system subsequently initializes itself and may load extra device drivers. The second-stage boot loader does not need drivers for its own operation, but may instead use generic storage access methods provided by system firmware such as the BIOS, UEFI or Open Firmware, though typically with restricted hardware functionality and lower performance.

Section "F.2. A Detailed Look at the Boot Process" of the Red Hat Enterprise Linux Installation Guide says, in the "F.2.1.1. BIOS-based x86 Systems" subsection, both

The Basic Input/Output System (BIOS) is a firmware interface that controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices.

and

This first-stage boot loader is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader (GRUB) and load the first part of it into memory.

which could be read as splitting the first stage of the boot process between the BIOS and the MBR code.

The Alpha SRM firmware boot-from-disk process starts by loading a small boot block, but the boot block doesn't contain code, it contains a disk logical block number (LBN) and LBN count, so it can load something larger than a single disk block. What it loads is called the "primary bootstrap image". It does not specify whether the "primary bootstrap image" loads the operating system image directly or loads a secondary bootstrap program. The Linux Alpha SRM boot process appears to involve the "primary bootstrap image" directly loading the Linux kernel, although the Linux Documentation process SRM-HOWTO calls it the "secondary bootstrap loader" (i.e., the program in the "primary bootstrap image" is the "secondary bootstrap loader").

The Advanced RISC Computing firmware for both MIPS and Alpha boot-from-disk process starts by loading an "OS loader" image from the "system partition"; that, as the name suggests, loads the OS image. They don't speak of "{first, second}-stage" or "{primary, secondary}".

The Open Firmware boot process starts by loading and running a program from a device. As an Open Firmware document says, "Often, this program is a secondary boot program, whose purpose is to load yet another program."

The UEFI boot process starts, when the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is used, by reading a file.

The IBM z/Architecture starts by a pile of firmware and, to use IBM's term, "licensed internal code" (which exists below the architecture and, in addition to hardware, implements said architecture) loading stuff into memory and running it. What happens after that is not specified by the architecture.

The "firmware loads a small MBR program and the MBR program loads something big enough to load something more complicated" is, as far as I know, a limitation of the original BIOS design; the other boot mechanisms appear to allow the firmware (or, in the case of IBM mainframes, firmware plus non-ROM-based licensed internal code that is probably machine-dependent, all of which is, as far as I know, invisible to boot loader and OS developers) to directly load something bigger than one 512-byte block.

The terminology for the various stages of the boot process is platform-dependent, and the number of stages may be platform-dependent, operating system-dependent, and perhaps, for some operating systems, user-choice-dependent.

The subsections of Booting § Modern boot loaders appear to describe:

1. PC booting, in Booting § First-stage boot loaders and Booting § Second-stage boot loaders;
2. embedded booting, in the first paragraph of Booting § Embedded and multi-stage boot loaders;
3. booting of some unspecified systems, in the second paragraph of Booting § Embedded and multi-stage boot loaders;
4. network booting, in Booting § Network booting.

I might be inclined to merge the description of PC booting into Booting § IBM-compatible personal computers (PC), the description of embedded booting into Booting § SoCs, embedded systems, microcontrollers, and FPGAs, and turn Booting § Network booting into a section at the same level as the two mentioned previously and put it after Booting § SoCs, embedded systems, microcontrollers, and FPGAs.

If somebody wants to add information about booting on system platforms other than PCs, they can do so. Guy Harris (talk) 10:46, 9 January 2025 (UTC)

References

Not all computers have boot ROM

Like its ancestor IBM System/360, the IBM z does not have a boot ROM. Instead, the ]]Initial Program Load]] (IPL) process initiates an I/O starting with a READ IPL channel command word (CCW).

I propose changing the first paragraph of the lead to When a computer is turned off, its software‍—‌including operating systems, application code, and data‍—‌remains stored on non-volatile memory. When the computer is powered on, it typically does not have an operating system or its loader in random-access memory (RAM). Most contemporary computers first execute a relatively small program stored in the boot ROM, which is read-only memory (ROM, and later EEPROM, NOR flash) along with some needed data, to initialize hardware devices such as CPU, motherboard, memory, storage and other I/O devices, to access the nonvolatile device (usually block device, e.g., NAND flash) or devices from which the operating system programs and data can be loaded into RAM. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:46, 9 January 2025 (UTC)

References