Talk:Booting/Archive 2

Archive 1

Archive 2

BIOS as first-stage boot loader

@奧田95: In this edit, you added BIOS to the list of examples of first-stage boot loaders. Presumably this means that the BIOS can directly load the second-stage boot loader, rather than loading a first-stage boot loader from the MBR that then loads the second-stage boot loader. Is that the case, at least with newer BIOSes? Guy Harris (talk) 19:28, 7 May 2021 (UTC)

You have a boot manager with UEFI. Does that count?

In an IPL on the S/360 line, does IPL1 count or would you call IPLTEXT in IPL2 the first stage loader? Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:26, 7 May 2021 (UTC)

UEFI counts if you're doing UEFI booting, but not if you're doing Compatibility Support Module (CSM) booting, unless there's a way to go straight from firmware to the main booting program with the legacy BIOS boot path. UEFI booting doesn't count as "BIOS"; CSM booting, at least as described in the UEFI article, appears just to be a legacy BIOS boot emulator in UEFI, using the same boot path.

As for the S/3x0 boot process (x = 10 and maybe also 11 for z/Architecture :-)), it doesn't quite fit the model used to describe booting on minis and on most microprocessor-based machines, as the very first read of IPL1 doesn't read in any CPU code, it reads in 2 CCWs worth of channel code (the second CCW of which could jump to more channel code read in by the first CCW) and a PSW to set up the machine and jump to the code that's been read in when the channel program finishes. I guess you could consider that to be a first-stage boot loader written in channel code. IPL2 would then be the second-stage loader, which also includes channel code.

This summary of the boot process in the QEMU documentation indicates that the CPU code that IPL2 loads is "either the operating system or a small program that loads the operating system from disk"; the "small program" would be the next-stage boot loader.

This strikes me as a sign that the "Modern boot loaders" section should probably be divided up into individual descriptions of the boot processes of various types of machines, with the "Personal computers (PC)" section being one of them, perhaps with separate BIOS and UEFI subsections, and perhaps with other non-x86-PC boot sequences also described - not necessarily with the language of "first-stage" and "second-stage" boot loaders, i.e. don't treat the constraints of BIOS booting as some universal characteristic of all modern boot sequences.

And, yes, given that IBM's shipping z/Architecture machines as we speak, the S/3x0 boot sequence is, indeed, a "modern" boot sequence; if its age disqualifies it, so perhaps does the age of the boot sequence of another machine IBM came out with, that one first shipping in 1981. :-) Guy Harris (talk) 22:09, 7 May 2021 (UTC)

The documentation in QEMU isn't quite right, and the Read IPL behavior applies to any DASD, not just to disk drives. I don't know of any operating system that resides in IPL2. The standard DASD initialization for OS/360 is to use IEAIPL00 as IPLTEXT for IPL2, where the code in IEAIPL00 reads the volume label from record 3, locates and reads the VTOC, locates SYS1.NUCLEUS, locates and loads the nucleus, and transfers control to the Nucleus Initialization Program (NIP) at the beginning of the nucleus. IPL for other IBM operating systems is similar, although details vary. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:53, 7 May 2021 (UTC)

The QEMU discussion is probably somewhat Linux-oriented, especially for the host machine - and I'm not certain whether it's discussiong "s390x", a/k/a z/Architecture, as the host, the guest, or both. Also, given that it's talking about z/Architecture, if "disk" should really be "DASD", that "DASD" is more likely to mean "disks and SSDs" than "disks and drums". :-)

And that makes IEAIPL00 another stage of booting, so it's either the second stage, if you include all the channel stuff (initial Read IPL CCW, CCWs from IPL1 as read with that initial CCW, and any CCWs in IPL2 as read by the pre-TIC CCWs in IPL1) in stage 1, or the third stage, if you consider the CCWs in IPL1 and IPL2 to be the first-stage and second-stage boot loaders. Again, trying to stuff S/3x0 booting - or other forms of booting, including UEFI booting - into the BIOS boot model is like trying to give someone a good night's sleep in the bed of Procrustes.

And the initial instructions of the first loaded bit of OS code in most operating systems is probably somewhat strange, e.g. the assembler-language startup code in the OS on which I'm typing this (look for "BSP CPU start here."), which I think next goes to vstart() in the first C code. Maybe MVSz/OS is stranger.

This also indicates that, for at least some OSes, one boot stage transition is between "code that doesn't understand file systems" to "code that can read the file that contains the first loaded bit of OS code" - it sounds as if IEAIPL00 understands enough about the on-disk layout of files in OS/360 etc. to be able to find the SYS1.NUCLEUS PDS and find a particular named member (as well as to determine which member to find). In at least some UN*Xes I seem to remember that the process of making a particular file a bootable kernel involved finding the raw disk block addresses of each block of that file and stuffing them into some place in a table to which the booting code had access, so the pre-OS booting code didn't have to understand the file system. Guy Harris (talk) 07:56, 8 May 2021 (UTC)

ESA/390 is a 32-bit architecture and preceded a/Architecture. That part of the QEMU documentation refers to the guest, but it is followed by a large amount of information on QEMU itself.

I don't consider switching from real mode to protected mode to be strange. However, the code needs better comments, especially the C code.

Yes, IEAIPL00 is dependent on OS/360 VTOC, PDS and load module details, as well as the specific way that sysgen link-edits the nucleus, e.g., that IEANIP00 is the first csect. Those complexities remained all the way through z/OS, with some new ones added. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:50, 9 May 2021 (UTC)

OK, so booting § Modern boot loaders says:

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). The computer first executes a relatively small program stored in read-only memory (ROM) along with a small amount of needed data, to access the nonvolatile device or devices from which the operating system programs and data can be loaded into RAM.

The small program that starts this sequence is known as a bootstrap loader, bootstrap or boot loader. This small program's only job is to load other data and programs which are then executed from RAM. ...

This seems to be saying that the part of the "ROM monitor" (or whatever you call the "relatively" small program in ROM) that loads the first bit of code into RAM is a boot loader. Would that then make it the first-stage boot loader, so that, on an IBM-compatible PC using BIOS-style booting, the BIOS code would be the first-stage boot loader and the code in the MBR would be the second-stage boot loader? - unsigned edit by user:Guy Harris 08:56, 8 May 2021‎

BIOS IS NOT only load OS, it also initializes system hardware for OS. After OS loading, the BIOS is also running (eg SMM). That's why, in x86 systems, OS (DOS, Windows, Unix-like) can be run in different machines without modifying OS. 奧田95 (talk) 15:51, 8 May 2021 (UTC)

"BIOS IS NOT only load OS" Nobody said it did only load the OS.

"After OS loading, the BIOS is also running (eg SMM). That's why, in x86 systems, OS (DOS, Windows, Unix-like) can be run in different machines without modifying OS." So modern OSes don't need to change the setup of anything in the chipsets themselves, they can rely on the ACPI to handle that? (They definitely need to be modified to include drivers for the hardware on different machines - neither Windows NT nor any Unix-like system I know of goes through the BIOS/UEFI to do I/O past a certain point in the startup code.) Guy Harris (talk) 19:18, 8 May 2021 (UTC)

BIOS: First stage.

BOOTMGR, GRUB2 (include their MBR boot code & PBR boot code, or include their .efi file): Second stage.

The MBR boot code: Real mode code.

The C:\BOOTMGR file: Protected mode code & Real mode code.

The BOOTX64.EFI file: Long mode code.

The CSM is a 16-bit module of UEFI firmware. 奧田95 (talk) 17:21, 8 May 2021 (UTC)

Is the MBR or VBR boot code considered part of the boot manager, or is that considered a separate stage? The BIOS will only load the boot sector code, as that's all it knows about, so it loads the MBR code, which may have to load the VBR code, which then loads the rest of the boot code. Are those considered separate stages of the boot process? If not, why not? Is there never a case where the MBR code comes from a different source than the VBR code, or where the VBR code comes from a different source than the rest of the boot code? Guy Harris (talk) 19:18, 8 May 2021 (UTC)

The BIOS Boot Path on Windows is: BIOS - MBR - PBR - BOOTMGR

The BIOS Boot Path on GRUB2 is: BIOS - MBR (boot.img) - core.img (similar to PBR) - normal.mod

The UEFI Boot Path is: UEFI - BOOTX64.EFI 奧田95 (talk) 17:32, 8 May 2021 (UTC)

The first stage boot loader IS NOT just load the OS. The BIOS(x86)/uboot(ARM) will parse some hardware info to the OS (eg ACPI tables/devicetrees). Uboot can load the Linux kernel file directly, but BIOS not. 奧田95 (talk) 18:14, 8 May 2021 (UTC)

If we're talking about the terms that WP:RS use, does "IBM Developer" (is that what used to be called DeveloperWorks?) considered a reliable source? If so, then its Inside the Linux boot process article considers the MBR to be the first phase (leaving the BIOS, all the way to loading the MBR code, as a stage before that - a "pre-boot" stage?) and everything after that (presumably including the VBR and the boot program that the VBR loads) as the second phase. It also considers GRUB to consist of everything including the MBR, so GRUB has a two-phase startup process.

And, again, this is all PC-specific for BIOS booting, and specific to platforms using {U}EFI for {U}EFI booting; other platforms have different boot processes - STM has a page about the boot process for Linux with their Cortex-based STM32 processor, for example.

So is there anything for Booting § Modern boot loaders to say other than "firmware does a bunch of stuff, and then loads some software, which may load other software, etc.", with the details punted entirely to sections describing the boot process for particular platforms or particular flavors of ROM monitor? Guy Harris (talk) 20:07, 8 May 2021 (UTC)

Likewise, I know of no source that considers the channel program of an IPL to be a first stage loader.Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:10, 9 May 2021 (UTC)

@奧田95: Please indent your replies with an extra :, or use {{od}} when the text is already heavily indented. Please leave tags like {{notelist-talk}} and {{reflist-talk}} at the end of the section unless there is a need to break the numbering. Please label things that are windows specific.

It's true that DOS made extensive use of the BIOS, but the BIOS code is not suitable for multiprogramming operating systems, and modern operating systems must deal with hardware idiosyncrasies on their own, other than picking up a few constants initially. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:10, 9 May 2021 (UTC)

Notes

In x86, The OS can be run in different computers without modifying OS copy (eg Windows 7 Professional x64), but additional drivers (eg Network) may needed. Modern x86 OSes have included many internal drivers, eg PCI bus driver(pci.sys in Windows), ACPI driver(acpi.sys), USB EHCI driver(usbehci.sys), AHCI driver(storahci.sys). The MBR bootcode and PBR bootcode are bootloader-specific. The BIOS/UEFI is mainboard-specific. 奧田95 (talk) 14:06, 10 May 2021 (UTC)

MBR (only 512 bytes) consist of a MBR bootcode (446 bytes), a MBR partition table (64 bytes), and 55AA signature (2 bytes). That's why BIOS need PBR bootcode, or core.img, to load the bootloader file (eg BOOTMGR, normal.mod, GRLDR). BOOTMGR and normal.mod are 32-bit code and 16-bit code hybrid.

For ARM, there are two boot methods. One is: ARM onchip ROM (onchip firmware) - uboot (uboot must be compiled for particular mainboard) - OS kernel. Another is: ARM CPU - UEFI firmware (a NOR flash chip of the mainboard) - BOOTAA64.EFI - GRUB2 (normal.mod) or Windows Boot Manager (bootmgr.efi) - OS kernel. uboot may be stored on NAND flash (for lower cost); BIOS/UEFI is usually stored on NOR flash. You can think uboot is FSBL on ARM; BIOS is FSBL on x86, UEFI is FSBL on x86/ARM, GRUB2/BOOTMGR is SSBL on BIOS/UEFI systems.

On x86, coreboot can load OS kernel directly (usually on Embedded Systems), or coreboot can load MBR / BOOTX64.EFI (similiar to BIOS/UEFI). On x86, UEFI also can load OS kernel directly (usually on Embedded Systems).

On DOS, the boot path is: BIOS - MBR - IO.SYS or BIOS - MBR - PBR - IO.SYS. On Windows 9x, the boot loader is IO.SYS. The x86 is in favor of UEFI and 64-bit OS now; many newer x86-64 computers are no longer provide Legacy Boot. 奧田95 (talk) 16:10, 10 May 2021 (UTC)

The boot code in the MBR and PBR makes heavy use of the BIOS, but modern OSs do not make use of the BIOS once they have been loaded. The MBR/PBR code is the first stage boot loader whether you're running DOS, W95, W10, Linux, FreeBSD or ArcaOS. Of course, with UEFI things are different. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:48, 10 May 2021 (UTC)

Notes

After OS loading, the BIOS is also running, eg Power Management, Thermal Management, Error Management, OS Basic Display. The real hardware is different with QEMU. 奧田95 (talk) 17:12, 10 May 2021 (UTC)

"In x86, The OS can be run in different computers without modifying OS copy (eg Windows 7 Professional x64), but additional drivers (eg Network) may needed." Network, disk controller, display, etc. OSes other than DOS have better things to do than have a bunch of "boot ROM" code read and write from file systems, draw pictures on the screen, play sounds, etc., etc., etc. on their behalf once they've started up. I don't think they even leave it entirely up to the monitor to do all power and thermal management - do they even rely on the "boot ROM" to interpret ACPI AML methods, or do some have their own interpreters? They may rely on the monitor to provide information about the system and devices present, but that's hardly unique to BIOS or UEFI; Open Firmware has done that since when it was OpenBoot. Of course, systems these days can't necessarily rely on the system configuration at boot time continuing to be the system configuration, given the number of hot-pluggable buses, including but not limited to USB, provided.

For ARM SystemReady systems, there are specifications for how to boot. Not all systems necessarily work that way, so, "for ARM" in general, there may be more boot methods, e.g. whatever Apple chooses to use.

And what should determine what Wikipedia calls a first-stage boot loader should be the term used in reliable sources, not what code starts the boot process; it may be that the term "boot loader" is reserved for software rather than system firmware, in which case you would have the "boot ROM", or whatever term is used for BIOS/UEFI/Open Firmware/etc. (if there is such a term), starting the boot process by loading the first-stage (software) boot loader and transferring control to it, beginning the chain loading process. Guy Harris (talk) 18:25, 10 May 2021 (UTC)

The Option ROM is the firmware of Video card, Network card, SAS card. Option ROM doesn't provide ACPI AML, while Video BIOS also provides VBE or UEFI GOP for basic OS display. For x86, the hardware initialization of BIOS/UEFI is usually NDA. OpROM BIOS (except Video BIOS) is 16-bit, while ACPI BIOS is 32-bit or 64-bit. In x86, Power Management, Thermal Management, is responsible by OS, BIOS/UEFI and device driver. In ARM, uboot is responsible for hardware initialization, the ARM onchip ROM is very small. After OS load (except DOS, Win3x and Win9x), all 16-bit BIOS code have been stopped, but the 32-bit/64-bit BIOS code is still running, including SMM. 奧田95 (talk) 05:40, 11 May 2021 (UTC)

"The Option ROM is the firmware of Video card, Network card, SAS card." ...which are not used by the GUI to draw pictures, by the networking stack to send or receive packets, or by the file system to read or write file system metadata or data. By the time a current OS is up, that's all handled by the OS.

"In ARM, uboot is responsible for hardware initialization" ...if the system uses U-Boot as its boot ROM. I rather doubt that the ARM-based machines designed in Cupertino do so, for example.

"but the 32-bit/64-bit BIOS code is still running, including SMM." Most of that code is only "running" if the OS calls it; when does the OS call it? As for SMM, what does it do, other than respond to requests from the OS, given current OSes take responsibility for power management? Guy Harris (talk) 06:13, 11 May 2021 (UTC)

"if the system uses U-Boot as its boot ROM." Or, rather, only if the system uses U-Boot as its first-stage boot loader; at least according to Das U-Boot, U-Boot is "both a first-stage and second-stage bootloader" and is "loaded by the system's ROM or BIOS from a supported boot device". This suggests that many boot ROMs - including BIOS, UEFI, and Open Firmware - are not first-stage boot loaders, although it appears that coreboot directly loads the OS rather than loading something that can load the OS (one-stage boot loader) or something that can load something that can load the OS (first-stage and second-stage boot loaders). Guy Harris (talk) 06:22, 11 May 2021 (UTC)

The SMM, Intel ME and AMD PSP are responsible for: Power Management, Hardware Management, and Server Management, etc. BIOS/UEFI is usually NDA on Intel/AMD, so VM ≠ real hardware. OS can invoke SCI (System Control Interrupt) or SMI (System Management Interrupt) to invoke SMM services, including shutdown, restart, sleep. BIOS, UEFI and Das U-Boot are responsible for hardware initialization; GNU GRUB and BOOTMGR are only responsible for load OS kernel. coreboot and Das U-Boot can directly load OS kernel, but BIOS not, UEFI usually not. The uboot/coreboot is usually compiled for certain mainboard and certain OS. The BIOS/UEFI is designed for universal OS, eg Windows and Linux, that is "without modifying OS copy eg Windows 7 Professional SP1 x64". 奧田95 (talk) 12:02, 11 May 2021 (UTC)

ZSBL: CPU onchip ROM stage (to load u-boot.bin, or FSBL Flash). FSBL: hardware initialization stage (eg UEFI, Das U-Boot). SSBL: OS loader stage (eg GRUB2, Das U-Boot, including Boot sector).

In modern x86, the "Boot Loader" usually means GRUB2 or BOOTMGR. The IO.SYS itself is the DOS kernel. 奧田95 (talk) 16:10, 11 May 2021 (UTC)

"The SMM, Intel ME and AMD PSP are responsible for: Power Management, Hardware Management, and Server Management, etc." They're not solely responsible for power management; few PCs run an OS that didn't have any knowledge of power management, so that BIOSes on laptops did power management out from under the OS any more, so Windows, Linux, etc. do their own power management work as well.

"BIOS, UEFI and Das U-Boot are responsible for hardware initialization"

"FSBL: hardware initialization stage" WP:RS for your claim that the term "first-stage boot loader" is used for hardware initialization, please. At least some sources (e.g., the IBM page about Linux booting that I mentioned earlier, and the STM page about the STM32 processor that I also mentioned earlier) say, for example, that the "Stage 1 bootloader"/"first-stage boot loader" is the boot code in the Master Boot Record, and that the "BIOS/Bootmonitor" is responsible for "System startup" (from the IBM page) or that

The ROM code is a piece of software that takes its name from the read only memory (ROM) where it is stored. It fits in a few tens of Kbytes and maps its data in embedded RAM. It is the first code executed by the processor, and it embeds all the logic needed to select the boot device (serial link or Flash) from which the first-stage boot loader (FSBL) is loaded to the embedded RAM.

and that

Among other things, the first stage boot loader (FSBL) initializes (part of) the clock tree and the external RAM controller. Finally, the FSBL loads the second-stage boot loader (SSBL) into the external RAM and jumps to it.

(from the STM page). The STM page seems to indicate that some hardware initialization may be done by the FSBL rather than from the ROM monitor, so, again, there is no universal division of labor between the various boot stages that applies to all platforms.

"The BIOS/UEFI is designed for universal OS, eg Windows and Linux, that is "without modifying OS copy" Windows and Linux still need drivers for 1) the disk controller on the motherboard (they are not going to go through the BIOS or UEFI for file system I/O once the system is initialized!) and 2) the graphics adapter if there's going to be a GUI, so the "universality" is not accomplished 100% by the BIOS/UEFI - it's also accomplished by making sure that either the main kernel executable image includes those drivers or the boot loading and OS startup process loads them.

"In modern x86, the "Boot Loader" usually means GRUB2 or BOOTMGR. The IO.SYS itself is the DOS kernel." In modern x86, there is rarely any IO.SYS, because there is usually no DOS (1994 called, they want their dominant PC OS back), there's Linux or Windows NT or *BSD or Solaris or, until recently, macOS. And, at least on systems with a BIOS, something has to load GRUB or BOOTMGR or other second-stage boot loaders, i.e. the MBR and VBR code. Guy Harris (talk) 18:28, 11 May 2021 (UTC)

In ARM systems, the bootloader and the OS are usually designed for certain mainboard or certain device, except UEFI systems. So BIOS/UEFI is for unified OS eg Windows and Linux.

The BIOS/UEFI is responsible for mainboard, CPU, chipset, RAM and peripherals initialization. 奧田95 (talk) 18:19, 13 May 2021 (UTC)

You can run Windows 10 Pro x64 on notebooks, desktops, workstations, and servers. You can run Ubuntu on desktops, workstations, and servers. That is "without modifying OS copy". 奧田95 (talk) 18:28, 13 May 2021 (UTC)

"In ARM systems, the bootloader and the OS are usually designed for certain mainboard or certain device, except UEFI systems." That can be replaced by "in ARM systems, there isn't a single way that system initialization and booting is done" without loss of information. The main ARM I use has a boot process described here. At some point one of us here will probably have a significantly larger ARM system from the same vendor, which will probably use a different boot process, as it runs a different operating system. Some other ARM systems might have a different boot process that's also different from a small embedded ARM system.

If Arm SystemReady catches on, there may be more standardization of the process, using either UEFI or LinuxBoot, depending on which "band" a system uses.

I don't see BIOS there, and doubt it's used for ARM. (How do you say "int 15" in ARM?)

"The BIOS/UEFI is responsible for mainboard, CPU, chipset, RAM and peripherals initialization." But, again, it's not responsible for 100% of making it possible for allowing an OS to run on multiple machines with the same kernel binary; part of that is the OS, or the OS loader, loading the appropriate drivers for the devices.

"You can run Windows 10 Pro x64 on notebooks, desktops, workstations, and servers." A "workstation" is just a more studly desktop, so that's not a big surprise that you can attribute to the ROM monitor.

"You can run Ubuntu on desktops, workstations, and servers." And at least some notebooks; the previous statement about workstations applies there.

In both cases, the parts you can attribute to the ROM monitor are the system initialization and the ACPI stuff that describes motherboard devices, allowing common code to handle those devices.

And none of this is sufficient to make the ROM monitor the "first-stage boot loader"; that's a question of how the term is generally used, and at least some sources use it to refer to the first software part of the boot process. Guy Harris (talk) 19:04, 13 May 2021 (UTC)

The Legacy BIOS is only for x86. UEFI is for x86 and ARM.

In ARM embedded, the OEM (eg Samsung, Apple, ASUS) is responsible for mainboard manufacturing, firmware (bootloader) developing, and OS developing (eg port OS drivers, OS kernel & bootloader for different device/mainboard, especially Android), to reduce cost. Many Android Phones have use device tree, but Android may widely used ARM UEFI in the future.

You can ref UEFI on RPi, the UEFI FW (in eMMC) is FSBL, the CPU onchip FW is ZSBL, and UEFI is responsible for hardware initialization. You can think FSBL (BIOS/UEFI) is middleware between OS and hardware.

In x86 (and ARM UEFI), the OEM (eg ASUS) is responsible for mainboard manufacturing and firmware (BIOS/UEFI) developing. The OS is provided by OSV (eg Microsoft, Canonical). Usually OEM buys BIOS/UEFI code from IBV (eg AMI). BIOS/UEFI code for Intel/AMD is NDA.

Windows Phone also uses UEFI as firmware or bootloader. 奧田95 (talk) 03:57, 14 May 2021 (UTC)

"UEFI is for x86 and ARM." EFI was originally for Itanium. It was later added to x86. The current UEFI specification also includes RISC-V; as the spec says, "UEFI uses a subset of the PE32+ image format with a modified header signature.", which is a bit annoying as it may put Microsoft in the position of gatekeeper as to which ISAs can use UEFI. It also says "Supported processors are “little endian” machines.", so its "universality" is limited to platforms with little-endian ISAs and with bi-endian ISAs run in little-endian mode. (Open Firmware didn't have that limitation....)

"You can think FSBL (BIOS/UEFI) is middleware between OS and hardware." I do think of the ROM monitor as middleware between some parts of the OS and some components of the hardware. I don't, however, call it the first-stage boot loader, because I haven't seen anybody other than you refer to it as the first-stage boot loader, and I have seen sources refer to the first software that's loaded from a boot medium by the ROM monitor as the first-stage boot loader. The only thing that appears to be common to most modern boot processes is that 1) they start with a ROM monitor and 2) the ROM monitor loads some software and the startup process is under the control of software from then on, albeit with the software possibly either using ROM monitor code (e.g., making BIOS/Open Firmware/etc. calls to read from the boot medium until a driver for the boot medium is loaded) or using information supplied by the ROM monitor and ROM monitor extensions on peripheral adapter cards (e.g., AML bytecode).

The "Modern boot loaders" section needs to be renamed to "Modern boot process", and needs to give a general (platform-independent - which means a lot more than just "BIOS and UEFI" or even "BIOS and UEFI and various platform-specific embedded platforms") discussion of what the ROM monitor does to load software and what that software does (from "loading the first stage of boot-loader software" to "being the operating system", depending on whether the ROM monitor can just load a boot sector, or can load a full operating system image, or something in between. The details of particular ROM monitors and particular platforms belong in sections after "Modern boot process", e.g. "IBM-compatible PCs and BIOS", "UEFI", and others. Guy Harris (talk) 05:39, 14 May 2021 (UTC)

Again, BIOS/UEFI OpROM does not provide AML code; Video BIOS provides VBE/UEFI GOP for OS basic display (if specific video driver is not installed in OS).

Modern OS use its own drivers (eg storahci.sys) to access hard disk drives.

The full OS image (eg WIM image) is also loaded by SSBL (GRUB/BOOTMGR).

Modern x86 computers don't have ROM BASIC and ROM MONITOR. In x86, FSBL ROM (BIOS / UEFI, NOR Flash) is loaded by CPU and chipset. x86 ZSBL (including CPU onchip firmware) is usually NDA.

SSBL and OS will use Protected Mode/Long Mode BIOS services, eg ACPI. Protected Mode has included V86 Mode, Long Mode has not included V86 Mode. 奧田95 (talk) 13:01, 14 May 2021 (UTC)

Should security be mentioned in the article?

Boot security is a big thing in modern computing. TPM/T2 chips in PCs/Apple have been designed and put into the devices for this purpose. Bootloader hacks and vulnerabilities are glorified in the common press. Secure boot is the cornerstone of device management and computer security for every company.

Should this page at least mention the topic? — Preceding unsigned comment added by Kurinurm (talk • contribs) 01:31, 28 December 2021 (UTC)

Level of detail for history

Subection IBM System/360 and successors of section History describes the original IPL process for S/360 and S/370. Since then there have been some new facilities.

When IBM introduced the Hardware Management Console (HMC) for IBM Z, it provided an interface to the HMC via the DIAGNOSE instruction and allowed the installation to define IPL profiles that included IPL parameters. The Principles of Operation manual does not document that interface.

Originally, an IPL of z/OS began in ESA/390-compatibility mode and the IPL code had to use a Signal Processor (SIGP)instruction with order 18 ('12'X) to set the z/Architecture architectural mode. On newer processors with the configuration-z/Architecture-architectural-mode (CZAM) facility, the IPL begins in z/Architecture architectural mode.

A new type of IPL, List-directed IPL, supports such devices as Fibre Channel Protocol (FCP) attached SCSI drives, and supports the secure-IPL facility. List-directed IPL is documented in the Principles of Operation manual.

How much of this belongs in the article? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:04, 13 February 2022 (UTC)

That level of detail probably belongs in an article describing the boot process of IBM's System/3x0 mainframes (what value of "x" applies to z/Architecture? :-)). I'd have a short section outside the history section giving a summary of the process and pointing to the larger article.

But at least some of the details in Booting § Personal computers (PC) probably also belong in other articles. BIOS describes the part of the boot process handled by the BIOS, and should probably have anything BIOS-related mentioned in that section moved there. The Unified Extensible Firmware Interface article also describes at least some of the boot process; any PC-specific stuff should either go there or perhaps into an article about the "IBM PC-compatible architecture" if such an article existed. The stuff done after the firmware loads something into memory and jumps to it probably belongs in other articles. Booting § Personal computers (PC) would again give a summary and point to the other articles. Guy Harris (talk) 20:43, 13 February 2022 (UTC)

I did a bare bones update mentioning the evolution but no details. The major details that I omitted are that starting with S/370-XA the device number is no longer a cuu and that when the configuration-z/Architecture-architectural-mode (CZAM) facility is installed, the PSW at real address 0 is in a different format. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:12, 23 February 2022 (UTC)