Legacy BIOSes will continue to boot Chromium OS from the MBR. The first part of the kernel then switches to protected mode and jumps to the kernel's 32-bit entry point, passing along the pointer to the zeropage table. At this point, the CPU is still running in Real Mode. After the zeropage table is filled in, a pointer to it is placed in the ESI register and execution continues with the first part of the kernel. It also creates a special table in memory called the “zeropage table.” The bootloader initializes fields in that table by making calls to the BIOS via interrupts.

Eventually, the bootloader code identifies the kernel.

That code then continues the boot process in some unspecified way - typically that VBR code (as well as the MBR code) is generated by and installed by grub, lilo, syslinux, or some similar bootloader. It searches the four partition table entries, finds a partition flagged as bootable, copies the first 512 bytes from that partition (the so-called Volume Boot Record or VBR) into RAM, and jumps there.

Those first 440 bytes of MBR code are responsible for bootstrapping the rest of the OS.

BIOS copies this block into RAM and starts executing the first byte. This consists of 440 bytes of real-mode code, 6 ignored bytes, 4 instances of 16-byte primary partition records, and 2 signature bytes, 0x55 and 0xAA.

The BIOS looks at the first block of each drive until it finds a Master Boot Record (MBR).

Legacy boot for x86 Linux has three steps: But as with any other GNU/Linux system, the pre-kernel boot process is unavoidably dependent on the hardware, BIOS, and bootloader. We want to make as few modifications to the upstream kernel as possible, ideally none.

Provide a secure and verifiable boot path for official Google Chrome OS devices.Ĭhromium OS is essentially a specially-tailored GNU/Linux distribution.

Support a limited selection of off-the-shelf netbooks for internal trials of Chromium OS.

Support readily available development platforms so that Chromium OS software can be built and tested without waiting for final hardware/firmware.

Goals for the boot process are as follows:

Openness - Allow developers to run operating systems other than Google Chrome OS.

Robustness - Recover from failed updates or corrupt partitions.

Speed - Support fast boot, where the boot loader is part of the firmware.

Goals for the drive partitioning scheme are as follows: This document describes the layout of data on the disk drive for a Chromium OS device and the process by which the OS is booted.

Partition find and mount key