143 lines
4.3 KiB
ReStructuredText
143 lines
4.3 KiB
ReStructuredText
******************
|
|
Boot Flow Overview
|
|
******************
|
|
|
|
To ease the support and developement of CoreOS on multiple plateform,
|
|
we use the same boot flow mechanisums on all our supported machine.
|
|
|
|
Glossary
|
|
========
|
|
|
|
In this document, the following terms have specific meanings:
|
|
|
|
.. glossary::
|
|
|
|
Firmware
|
|
Program that implement the boot and runtime services as defined by the
|
|
:ext+uefi:ref:`UEFI specifications <maincontent>`.
|
|
|
|
Application
|
|
Program written according to the UEFI specification that can be started
|
|
by the firmware. See :ext:ref:`UEFI Applications <uefi-applications>`.
|
|
|
|
Bootloader
|
|
Application that allow to start other application based on user selection,
|
|
configuration or autodetection.
|
|
|
|
Operating system
|
|
Application that include at least the Linux Kernel and the initial RAM
|
|
disk.
|
|
|
|
|
|
Generic Boot Flow
|
|
=================
|
|
|
|
.. graphviz:: bootflow-generic.dot
|
|
|
|
CoreOS use a standardized workflow: the firmware can start either an
|
|
optional bootloader or an operating system as an UEFI application.
|
|
|
|
Firmware
|
|
========
|
|
|
|
CoreOS support two different use case:
|
|
|
|
Using a CoreOS provided firmware
|
|
--------------------------------
|
|
|
|
The most common use case is to use a firmware image provided by CoreOS as part
|
|
of the board support package.
|
|
|
|
Currently, the CoreOS provided firmware functionality is provided by `u-boot`
|
|
|
|
Using CoreOS on third party machine
|
|
-----------------------------------
|
|
|
|
As the interface between the firmware and the rest of the system is clearly
|
|
defined, we also support to run CoreOS on top of any standard UEFI complient
|
|
system.
|
|
|
|
As an example, this is the case when using a CoreOS image inside a virtual
|
|
machine.
|
|
|
|
Firmware requirements
|
|
---------------------
|
|
|
|
|
|
ARM32 / AArch32 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for ARM32 should implement a subset of the UEFI specification, as
|
|
defined by the EBBR Specification. As this architecure is used on old hardware,
|
|
it's ok to use the part of the specification that are marked as deprecated or
|
|
legacy like:
|
|
|
|
- MBR partitionning instead of GPT
|
|
- Fixed offsets to firmware data
|
|
|
|
We require the firmware to provide a DeviceTree based system description and not
|
|
an ACPI based table (as allowed by the specification)
|
|
|
|
We also require the firmware to implement the UEFI Secure Boot functionality.
|
|
|
|
ARM64 / AArch64 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for ARM64 should implement a subset of the UEFI specification, as
|
|
defined by the EBBR Specification. The part of the specification marked as
|
|
legacy or deprecated must not be used.
|
|
|
|
This means:
|
|
- Only GPT partionning disk are supported
|
|
- No fixed offsets to firmware data
|
|
|
|
We require the firmware to provide a DeviceTree based system description and not
|
|
an ACPI based table (as allowed by the specification)
|
|
|
|
We also require the firmware to implement the UEFI Secure Boot functionality.
|
|
|
|
|
|
AMD64 / x86_64 based machine
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The firmware for AMD64 should implement the UEFI specification.
|
|
|
|
Bootloader
|
|
==========
|
|
|
|
CoreOS only support `systemd-boot` as bootloader. The usage of the bootloader
|
|
is optional. It's primary use case is for system that don't use a firmware
|
|
provided by CoreOS.
|
|
|
|
|
|
Operating system
|
|
================
|
|
|
|
The operating system image is an UEFI application that contain the kernel. We
|
|
support two method to create this image:
|
|
|
|
Unified Kernel Images (UKI)
|
|
---------------------------
|
|
|
|
This is the most secure method. The UEFI entry point is provided by
|
|
`systemd-stub` and the image contains the Linux Kernel, the boot arguments of
|
|
the kernel, the os-release file and an initrd ram disk.
|
|
|
|
This allows to have all these part authenticated via UEFI secure boot.
|
|
|
|
.. warning::
|
|
UKI are not supported for ARM32 target at the moment, due to a bug in objcopy.
|
|
See https://sourceware.org/bugzilla/show_bug.cgi?id=26218
|
|
|
|
.. note::
|
|
UKI has the advantages to be discoverable by the bootloader without any
|
|
configuration file, and doesn't need a firmware that is able to set the
|
|
kernel command line.
|
|
|
|
Kernel built with the built-in EFI sub
|
|
--------------------------------------
|
|
|
|
This method use the EFI stub provided by the kernel. The initramfs image has to
|
|
be bundled with the Kernel, using `INITRAMFS_IMAGE_BUNDLE`, as otherwise it
|
|
will not be authenticated by UEFI secure boot.
|