Compare commits
2 Commits
HEAD
...
docs/docke
| Author | SHA1 | Date |
|---|---|---|
Samuel Dolt
|
162c0098b8 | |
|
Samuel Dolt
|
f275e7e499 |
|
|
@ -3,5 +3,4 @@ vscode-bitbake-build/
|
|||
documentation/_build/
|
||||
documentation/oe-logs
|
||||
documentation/oe-workdir
|
||||
__pycache__
|
||||
.venv/
|
||||
|
||||
|
|
|
|||
|
|
@ -2,35 +2,23 @@
|
|||
path = bitbake
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/bitbake.git
|
||||
branch = 2.0
|
||||
[submodule "openembedded-core"]
|
||||
path = external-layers/openembedded-core
|
||||
[submodule "layers/openembedded-core"]
|
||||
path = layers/openembedded-core
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/openembedded-core.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-openembedded"]
|
||||
path = external-layers/meta-openembedded
|
||||
[submodule "layers/meta-openembedded"]
|
||||
path = layers/meta-openembedded
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-openembedded.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-virtualization"]
|
||||
path = external-layers/meta-virtualization
|
||||
[submodule "layers/meta-virtualization"]
|
||||
path = layers/meta-virtualization
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-virtualization.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-efibootguard"]
|
||||
path = external-layers/meta-efibootguard
|
||||
[submodule "layers/meta-efibootguard"]
|
||||
path = layers/meta-efibootguard
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-efibootguard.git
|
||||
branch = master
|
||||
[submodule "meta-swupdate"]
|
||||
path = external-layers/meta-swupdate
|
||||
branch = coreos/master
|
||||
[submodule "layers/meta-swupdate"]
|
||||
path = layers/meta-swupdate
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-swupdate.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-arm"]
|
||||
path = external-layers/meta-arm
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-arm.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-ti"]
|
||||
path = external-layers/meta-ti
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-ti.git
|
||||
branch = kirkstone
|
||||
[submodule "meta-lts-kernel-mixin"]
|
||||
path = external-layers/meta-lts-kernel-mixin
|
||||
url = ssh://git@bitbucket.gad.local:7999/ico/meta-lts-mixins.git
|
||||
branch = coreos/kirkstone/kernel
|
||||
|
|
|
|||
|
|
@ -1,10 +1,6 @@
|
|||
{
|
||||
"recommendations": [
|
||||
"ms-vscode.makefile-tools",
|
||||
"timonwong.shellcheck",
|
||||
"kweihmann.oelint-vscode",
|
||||
"lextudio.restructuredtext",
|
||||
"trond-snekvik.simple-rst",
|
||||
"yocto-project.yocto-bitbake"
|
||||
"timonwong.shellcheck"
|
||||
]
|
||||
}
|
||||
|
|
@ -1,47 +1,8 @@
|
|||
{
|
||||
"files.watcherExclude": {
|
||||
"**/build/**": true,
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"search.exclude": {
|
||||
"**/build/**": true,
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"C_Cpp.files.exclude": {
|
||||
"**/build": true,
|
||||
"**/_build": true,
|
||||
},
|
||||
"python.analysis.exclude": [
|
||||
"**/build/**",
|
||||
"**/_build/**",
|
||||
],
|
||||
"python.formatting.provider": "black",
|
||||
"editor.rulers": [80,100,120],
|
||||
"bitbake.pathToBuildFolder": "${workspaceFolder}/build",
|
||||
"bitbake.pathToEnvScript": "${workspaceFolder}/coreos-init-build-env",
|
||||
"bitbake.pathToBitbakeFolder": "${workspaceFolder}/bitbake",
|
||||
"python.autoComplete.extraPaths": [
|
||||
"${workspaceFolder}/bitbake/lib",
|
||||
"${workspaceFolder}/meta/lib"
|
||||
],
|
||||
"python.analysis.extraPaths": [
|
||||
"${workspaceFolder}/bitbake/lib",
|
||||
"${workspaceFolder}/meta/lib"
|
||||
],
|
||||
"[python]": {
|
||||
"diffEditor.ignoreTrimWhitespace": false,
|
||||
"gitlens.codeLens.symbolScopes": [
|
||||
"!Module"
|
||||
],
|
||||
"editor.formatOnType": true,
|
||||
"editor.wordBasedSuggestions": "off",
|
||||
"files.trimTrailingWhitespace": false
|
||||
},
|
||||
"[shellscript]": {
|
||||
"files.eol": "\n",
|
||||
"files.trimTrailingWhitespace": false
|
||||
},
|
||||
"bitbake.sdkImage": "coreos-image-minimal",
|
||||
"bitbake.workingDirectory": "${workspaceFolder}",
|
||||
"task.saveBeforeRun": "always",
|
||||
"**/build/cache/**": true,
|
||||
"**/build/downloads/**": true,
|
||||
"**/build/sstate-cache/**": true,
|
||||
"**/build/tmp/**": true
|
||||
}
|
||||
}
|
||||
2
bitbake
2
bitbake
|
|
@ -1 +1 @@
|
|||
Subproject commit 40fd5f4eef7460ca67f32cfce8e229e67e1ff607
|
||||
Subproject commit ac576d6fad6bba0cfea931883f25264ea83747ca
|
||||
|
|
@ -26,7 +26,7 @@ COREOS_ROOT=$(readlink -f "${COREOS_ROOT}")
|
|||
# Set the path to bitbake, openembedded-core and the template directory
|
||||
# All theses values can be overriden by the caller of coreos-init-build-env
|
||||
BITBAKEDIR="${BITBAKEDIR:-${COREOS_ROOT}/bitbake}"
|
||||
OEROOT="${OEROOT:-${COREOS_ROOT}/external-layers/openembedded-core}"
|
||||
OEROOT="${OEROOT:-${COREOS_ROOT}/layers/openembedded-core}"
|
||||
TEMPLATECONF="${TEMPLATECONF:-${COREOS_ROOT}/templates}"
|
||||
|
||||
# Sanity checks
|
||||
|
|
@ -84,11 +84,6 @@ coreos_path_add "${COREOS_ROOT}/scripts"
|
|||
# Add support for ##COREOS_LAYERSDIR## inside of bblayer template
|
||||
coreos-bblayers-envsub COREOS_LAYERSDIR "${COREOS_ROOT}/layers"
|
||||
|
||||
# Add support for ##COREOS_EXTLAYERSDIR## inside of bblayer template
|
||||
coreos-bblayers-envsub COREOS_EXTLAYERSDIR "${COREOS_ROOT}/external-layers"
|
||||
|
||||
# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything
|
||||
# if the directory already exist so it's safe to call it everytime
|
||||
# stdout is redirected to reduce the amount of output but not stderr
|
||||
#
|
||||
#Note: if a final build is detected all the dev keys are deleted
|
||||
# Generate the ${BUILDDIR}/key directory. The scripts doesn't generate anything it
|
||||
# the directory already exist, so it's safe to call it everytime
|
||||
coreos-keygen > /dev/null 2> /dev/null
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
{
|
||||
"recommendations": [
|
||||
"ms-vscode.makefile-tools",
|
||||
"lextudio.restructuredtext",
|
||||
"trond-snekvik.simple-rst"
|
||||
]
|
||||
}
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
{
|
||||
"files.watcherExclude": {
|
||||
"**/_build/**": true,
|
||||
},
|
||||
"python.formatting.provider": "black",
|
||||
"editor.rulers": [
|
||||
80,
|
||||
100,
|
||||
120
|
||||
],
|
||||
"esbonio.sphinx.confDir": ""
|
||||
}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
|
||||
/* Make tables more convenient by wrapping line instead of using an
|
||||
horizontal scrollbar */
|
||||
.wy-table-responsive table td, .wy-table-responsive table th {
|
||||
white-space: normal;
|
||||
}
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
***************************
|
||||
CMake with Bitbake recipes
|
||||
***************************
|
||||
|
||||
Example of using CMake with Bitbake recipes.
|
||||
|
||||
Please find the example here:
|
||||
`CMake Yocto Example <https://bitbucket.gad.local/projects/ICO/repos/coreos/browse/layers/meta-belden-coreos-demo/recipes-demo/cmake-demo/cmake-demo_0.1.bb>`_.
|
||||
|
||||
.. warning::
|
||||
This simple example has the code in the same repo as the recipe. However, it is recommended to have the code in a separate git repo.
|
||||
To use remote git repo, it's necessary to have settings as follows:
|
||||
|
||||
* SRC_URI = "git://github.com/<link to your repo>"
|
||||
* S="${WORKDIR}/git
|
||||
|
||||
|
||||
BitBake recipe
|
||||
===============
|
||||
|
||||
Bitbake recipe inherits the cmake class and then ``CMakeLists.txt`` file can be used for building and installing.
|
||||
``CMakeLists.txt`` is expected at top of the sources tree pointed by ``SRC_URI``.
|
||||
Usually this file is fetched using git or by downloading a tarball (.tar.gz).
|
||||
If this file is created locally it should be placed somewhere in path (usually ``<Package Name>/files``). Files that are going to be used in
|
||||
package need to be included using ``SRC_URI +=``, files need to be included with paths relative to files directory.
|
||||
Installation of generated files can also be done using native CMake install command (which is recommended),
|
||||
but in case something specific is needed, developer can override CMake installation with a BitBake ``do_install`` function.
|
||||
|
||||
.. warning::
|
||||
When using CMake for installation of some files, and using Bitbake recipe
|
||||
for installing other files. Bitbake's ``do_install`` will override the CMake
|
||||
installation, therefore, one should use ``do_install:append``.
|
||||
|
||||
|
||||
|
||||
``CMakeLists.txt`` file
|
||||
========================
|
||||
When building binaries and libraries in the same package, it's a good idea to keep ``CMakeLists.txt``
|
||||
files split up over all source directories with top ``CMakeLists.txt`` to keep common info:
|
||||
|
||||
* ``cmake_minimum_required`` - Defines minimum version of CMake required for desired build. Please check what version is supported by installed Yocto.
|
||||
* ``project`` - Defines project name and version.
|
||||
* ``add_subdirectory`` - If the package uses multiple ``CMakeLists.txt`` files, their directories should be included using this command.
|
||||
|
||||
optional: ``set(CMAKE_VERBOSE_MAKEFILE ON)`` - can be used for debugging
|
||||
|
||||
|
||||
|
||||
Helloworld - Simple binary example
|
||||
===================================
|
||||
|
||||
This method shows a simple "Hello world" program written in C,
|
||||
that uses CMake for building and installing the binary in Yocto.
|
||||
|
||||
Additional information about this topic can be found in official
|
||||
documentation: :external:ref:`Yocto Project - CMake
|
||||
<ref-classes-cmake>`.
|
||||
|
||||
|
||||
|
||||
CMake file - explanation
|
||||
-------------------------
|
||||
``CMakeLists.txt`` inherits top ``CMakeLists.txt``, so only minimal information is defined in this file:
|
||||
|
||||
* ``add_executable`` - Creating binary file
|
||||
* ``install`` - Installing binary file
|
||||
|
||||
|
||||
|
||||
|
||||
Hello service - Simple binary is started in systemd
|
||||
====================================================
|
||||
|
||||
A simple service that starts binary on boot is created. Service
|
||||
file is installed using Bitbake method, as using CMake can be
|
||||
avoided in this case (no need to build).
|
||||
|
||||
|
||||
|
||||
|
||||
Libdemo - Simple library example
|
||||
=================================
|
||||
|
||||
Demo library with one function is built and installed using CMake.
|
||||
An include file is also installed.
|
||||
|
||||
Further information about building different types of libraries can
|
||||
be found on official CMake page: :external:ref:`Yocto Project Library documentation
|
||||
<dev-manual/common-tasks:working with libraries>`.
|
||||
|
||||
|
||||
|
||||
CMake file - explanation
|
||||
-------------------------
|
||||
|
||||
``CMakeLists.txt`` inherits top ``CMakeLists.txt``, but this ``CMakeLists.txt`` is somewhat different compared to Helloworld:
|
||||
|
||||
* ``add_library`` - declare the library target.
|
||||
* ``set_target_properties`` - define different properties that are useful for creating library (e.g. defining include files)
|
||||
* ``set_target_properties`` - installing files to desired locations
|
||||
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
|
||||
==============================
|
||||
Belden CoreOS Best Practices
|
||||
==============================
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
overview
|
||||
cmake
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
************************
|
||||
Best Practices Overview
|
||||
************************
|
||||
|
||||
To ease the support and developement of CoreOS on multiple plateform,
|
||||
some examples were made to show developers good practices when working with yocto.
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
digraph G {
|
||||
fw [label = "Firmware";shape = rect;];
|
||||
|
||||
btl [label = "Bootloader";shape = rect;];
|
||||
|
||||
os [label = "Operating System";shape = rect;];
|
||||
|
||||
fw -> btl -> os;
|
||||
}
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
@startuml
|
||||
!theme cloudscape-design
|
||||
start
|
||||
:**Firmware**;
|
||||
note right
|
||||
Implement a subset of the UEFI specification
|
||||
Usually implemented by u-boot
|
||||
end note
|
||||
:**Bootloader**
|
||||
efibootguard;
|
||||
note right
|
||||
The bootloader is responsible to find and load the Operating System
|
||||
It's an UEFI application that can be signed
|
||||
end note
|
||||
:**Operating System**
|
||||
Unified Kernel Image;
|
||||
note right
|
||||
The Operating System is a single UEFI application that can be signed
|
||||
This application has to call the ExitBootService UEFI protocol
|
||||
This application contains at least the Linux Kernel
|
||||
end note
|
||||
end
|
||||
@enduml
|
||||
|
|
@ -3,9 +3,7 @@ digraph G {
|
|||
|
||||
uboot [label = "u-boot with EFI/EBBR support";shape = rect;];
|
||||
|
||||
btl [label = "EFIBootGuard";shape = rect;];
|
||||
|
||||
kernel [label = "OS (EFI Stub + Kernel + Initramfs";shape = rect;];
|
||||
kernel [label = "UKI (EFI Stub + Kernel + DTS + Initramfs";shape = rect;];
|
||||
|
||||
rom -> uboot -> btl -> kernel;
|
||||
rom -> uboot -> kernel;
|
||||
}
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
***********
|
||||
Disk Layout
|
||||
***********
|
||||
|
||||
Standard Disk Layout
|
||||
====================
|
||||
|
||||
|
||||
|
||||
Disk Layout using GPT
|
||||
======================
|
||||
|
||||
Modern product use a GPT partionning disk with at least 5 partitions:
|
||||
|
||||
- EFI
|
||||
- PLATFORM0
|
||||
- PLATFORM1
|
||||
- BOOT0
|
||||
- BOOT1
|
||||
|
||||
Order and position of theses partitions doesn't matter as long as the
|
||||
right partition label, partition label and filesystem are used.
|
||||
|
||||
.. image:: disk/disk-layout.png
|
||||
|
||||
Partitions
|
||||
==========
|
||||
|
||||
EFI
|
||||
---
|
||||
|
||||
The EFI partition contains the bootloader (efibootguard).
|
||||
|
||||
.. image:: disk/part-efi.png
|
||||
|
||||
BOOT0 and BOOT1
|
||||
---------------
|
||||
|
||||
The BOOT0 and BOOT1 partition contains a kernel and a configuration files.
|
||||
|
||||
.. image:: disk/part-boot0.png
|
||||
|
||||
PLATFORM0 and PLATFORM1
|
||||
-----------------------
|
||||
|
||||
The PLATFORM0 and PLATFORM1 partitions contains a Linux root filesystem.
|
||||
|
||||
.. image:: disk/part-platform0.png
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
|
|
@ -0,0 +1,100 @@
|
|||
************************
|
||||
Bootloader: efibootguard
|
||||
************************
|
||||
|
||||
Efibootguard is the default bootloader of CoreOS. It's an open source
|
||||
bootloader based on UEFI made by Siemens and released under GPLv2, that
|
||||
implement the A/B booting scheme.
|
||||
|
||||
Efibootguard allow us to have a redondant boot partition that contain a
|
||||
configuration file for efibootguard and a signed Unified Kernel Image
|
||||
|
||||
A/B Switch
|
||||
==========
|
||||
|
||||
Two partition are used to store two diffrent configuration. The first partition
|
||||
is called boot0 and the second one boot1.
|
||||
|
||||
At boot, efibootguard find the configuration file stored inside each boot
|
||||
partition and load it. Inside the configuration, the field "revision" is used
|
||||
to select the configuration to use to boot the board. It will be the one
|
||||
with the highest revision
|
||||
|
||||
.. uml::
|
||||
|
||||
@startuml
|
||||
!theme cloudscape-design
|
||||
start
|
||||
partition A/B selector {
|
||||
|
||||
:read boot0 configuration;
|
||||
:read boot1 configuration;
|
||||
|
||||
if (boot0.revision > boot1.revision") then (yes)
|
||||
:select boot0;
|
||||
else (no)
|
||||
:select boot1;
|
||||
endif
|
||||
}
|
||||
|
||||
end
|
||||
@enduml
|
||||
|
||||
State checking
|
||||
==============
|
||||
|
||||
After having selecting the configuration to use, efibootguard will use the
|
||||
state field to determine is the configuration is already know to work or not.
|
||||
|
||||
Theses states are possible:
|
||||
|
||||
- ok: the configuration is known to be working
|
||||
- installed: the configuration was just updated and was never booted
|
||||
- testing: the configuration was just updated and was already booted once
|
||||
- failed: the configuration is not working
|
||||
|
||||
.. uml::
|
||||
|
||||
@startuml
|
||||
!theme cloudscape-design
|
||||
start
|
||||
partition state checking {
|
||||
switch (state?)
|
||||
case ( ok )
|
||||
:set state to ok;
|
||||
case ( installed )
|
||||
:set state to testing;
|
||||
case ( testing )
|
||||
:set state to failed;
|
||||
:set revision to 0;
|
||||
:reboot;
|
||||
stop
|
||||
case ( failed )
|
||||
:set revision to 0;
|
||||
:reboot;
|
||||
stop
|
||||
endswitch
|
||||
}
|
||||
end
|
||||
@enduml
|
||||
|
||||
Image loading
|
||||
==============
|
||||
|
||||
The last part of the boot process just consist of reading kernel image
|
||||
from the selected boot partition and then calling the load_image EFI function
|
||||
to let the EFI firmware start the given image. The firmware will then first
|
||||
check the signature of the kernel before starting it.
|
||||
|
||||
.. uml::
|
||||
|
||||
@startuml
|
||||
!theme cloudscape-design
|
||||
start
|
||||
partition kernel loading {
|
||||
: read unified kernel image from boot partition;
|
||||
: load image to memory;
|
||||
}
|
||||
: call EFI load_image();
|
||||
end
|
||||
@enduml
|
||||
|
|
@ -11,4 +11,6 @@ Belden CoreOS Boot Concepts
|
|||
|
||||
overview
|
||||
uboot
|
||||
secure-boot
|
||||
efibootguard
|
||||
uki
|
||||
disk
|
||||
|
|
@ -13,8 +13,8 @@ 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>`.
|
||||
Program that implement some of the boot and runtime services defined by
|
||||
the :ext+uefi:ref:`UEFI specifications <maincontent>`.
|
||||
|
||||
Application
|
||||
Program written according to the UEFI specification that can be started
|
||||
|
|
@ -25,17 +25,26 @@ In this document, the following terms have specific meanings:
|
|||
configuration or autodetection.
|
||||
|
||||
Operating system
|
||||
Application that include at least the Linux Kernel and the initial RAM
|
||||
disk.
|
||||
Application that include at least the Linux Kernel.
|
||||
|
||||
Unified Kernel Image
|
||||
Application that include the Linux kernel and the command line to pass to
|
||||
the kernel and optionaly one or more device trees and a RAM disk
|
||||
|
||||
|
||||
Generic Boot Flow
|
||||
=================
|
||||
|
||||
.. graphviz:: bootflow-generic.dot
|
||||
.. uml:: bootflow-generic.plantuml
|
||||
|
||||
CoreOS use a standardized workflow based on UEFI: the firmware automatically
|
||||
start the bootloader. The bootloader is stored inside the EFI partition, under:
|
||||
`/EFI/BOOT/BOOT<ARCH>.EFI` where `<ARCH>` is:
|
||||
|
||||
- ARM for Arm32 CPU
|
||||
- A64 for Aarch64 CPU
|
||||
- X64 for Amd64 CPU
|
||||
|
||||
CoreOS use a standardized workflow: the firmware can start either an
|
||||
optional bootloader or an operating system as an UEFI application.
|
||||
|
||||
Firmware
|
||||
========
|
||||
|
|
@ -63,11 +72,6 @@ machine.
|
|||
Firmware requirements
|
||||
---------------------
|
||||
|
||||
.. warning::
|
||||
|
||||
CoreOS support at the moment only hardware that contains a block storage
|
||||
device (SD Card, eMMC, ...) formatted with GPT. MBR disk or MTD device are
|
||||
not supported.
|
||||
|
||||
ARM32 / AArch32 based machine
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -75,10 +79,13 @@ 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.
|
||||
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).
|
||||
an ACPI based table (as allowed by the specification)
|
||||
|
||||
We also require the firmware to implement the UEFI Secure Boot functionality.
|
||||
|
||||
|
|
@ -86,12 +93,16 @@ ARM64 / AArch64 based machine
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The firmware for ARM64 should implement a subset of the UEFI specification, as
|
||||
defined by the EBBR Specification.
|
||||
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). The DeviceTree provided
|
||||
by the firmware can be very minimal as it can be replaced at boot time
|
||||
by a device-tree contained inside the Operating System Image.
|
||||
an ACPI based table (as allowed by the specification)
|
||||
|
||||
We also require the firmware to implement the UEFI Secure Boot functionality.
|
||||
|
||||
|
|
@ -104,13 +115,36 @@ The firmware for AMD64 should implement the UEFI specification.
|
|||
Bootloader
|
||||
==========
|
||||
|
||||
CoreOS only support `efibootguard` as bootloader. The usage of the bootloader
|
||||
is mandated.
|
||||
CoreOS only support `efibootguard` as bootloader.
|
||||
|
||||
|
||||
Operating system
|
||||
================
|
||||
|
||||
The operating system image is an UEFI application that contain the kernel. It's
|
||||
a Unified Kernel Image generated by tools from the EFIBootGuard project.
|
||||
The operating system image is an UEFI application that contain the kernel.
|
||||
|
||||
Two ways can be used to generate this application:
|
||||
|
||||
Kernel built with the built-in EFI stub
|
||||
---------------------------------------
|
||||
|
||||
This method use the EFI stub provided by the kernel.
|
||||
|
||||
|
||||
Unified Kernel Images (UKI)
|
||||
---------------------------
|
||||
|
||||
This is the most secure method. The UEFI entry point is provided by
|
||||
`efibootguard/stub` and the image contains the Linux Kernel with it's built-in
|
||||
EFI stub, the boot arguments of the kernel and optionaly multiple device trees
|
||||
and an initial RAM disk.
|
||||
|
||||
This allows to have all these part authenticated via UEFI secure boot just by
|
||||
signing the UKI.
|
||||
|
||||
.. important::
|
||||
|
||||
Only the Unified Kernel Image methods is supported by the CoreOS teams. Using
|
||||
the kernel directly should be used only for new hardware bring-up. By default
|
||||
we only sign UKI to ensure that it's the only method used for hardware that
|
||||
ship with secure boot enabled.
|
||||
|
|
|
|||
|
|
@ -1,268 +0,0 @@
|
|||
*******************
|
||||
Secure Boot Concept
|
||||
*******************
|
||||
|
||||
Currently CoreOS provide a Proof Of Concept of some of the secure boot element that we want to
|
||||
implement a full secure-boot solution based on UEFI secure boot.
|
||||
|
||||
The current proof of concept is structured as follows:
|
||||
|
||||
Hardware Requirements
|
||||
=====================
|
||||
|
||||
- The device must have an `eMMC`.
|
||||
- The architecture of the device must be either `ARM32` or `AARCH64`.
|
||||
|
||||
|
||||
eMMC Embedded MultiMediaCard
|
||||
============================
|
||||
|
||||
eMMC, or Embedded MultiMediaCard, represents a prevalent storage format in devices such as
|
||||
smartphones, tablets, and other embedded systems. It encapsulates NAND flash memory and a dedicated
|
||||
controller within one package. This structure not only eases integration for device manufacturers
|
||||
but also ensures a compact, efficient storage medium.
|
||||
|
||||
Within eMMC's architecture, distinct hardware partitions cater to diverse operational demands:
|
||||
|
||||
.. graphviz::
|
||||
|
||||
digraph emmcStructure {
|
||||
rankdir=TB;
|
||||
node [shape=box, style=filled, fillcolor="#e6f2ff"];
|
||||
edge [color="#0099cc", fontsize=12];
|
||||
|
||||
compound=true;
|
||||
|
||||
subgraph cluster_eMMC {
|
||||
label="eMMC";
|
||||
color="#0099cc";
|
||||
|
||||
Boot0 [label="Boot0"];
|
||||
Boot1 [label="Boot1"];
|
||||
RPMB [label="RPMB"];
|
||||
|
||||
subgraph cluster_User {
|
||||
label="User";
|
||||
color="#00cc99";
|
||||
GPT [label="GPT Table"];
|
||||
|
||||
subgraph cluster_GPT {
|
||||
label="Software Partitions (GPT)";
|
||||
color="#99e6e6";
|
||||
|
||||
SoftwarePartition1 [label="Partition 1"];
|
||||
SoftwarePartition2 [label="Partition 2"];
|
||||
SoftwarePartitionN [label="Partition N"];
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
#. **Boot0 and Boot1**: The boot partitions cater to device start-up requirements, typically hosting
|
||||
the firmware. Boot0 predominantly initiates the boot-up, while Boot1 stands as a secondary guard
|
||||
or backup, ensuring booting is resilient and failsafe.
|
||||
|
||||
#. **RPMB (Replay Protected Memory Block)**: As a secure partition, RPMB shelters data against
|
||||
potential tampering. It's tailored for sensitive information storage, such as cryptographic keys.
|
||||
Its design counters data replays or rollbacks, fortifying against particular attack types.
|
||||
|
||||
#. **User**: The primary storage domain, the User partition accommodates the OS, applications,
|
||||
and user-centric data. It's reminiscent of the primary storage drive in larger computing devices.
|
||||
Importantly, the User partition has a layered structure. Using the GPT (GUID Partition Table), it
|
||||
is further divided into multiple software partitions, which can house diverse datasets or file
|
||||
systems.
|
||||
|
||||
The boot concept of CoreOS rely on the presence of an eMMC to implement the following feature:
|
||||
|
||||
- Storage of two copy of the firmware with a way to switch from a copy to another using the eMMC
|
||||
boot0 and boot1 hardware partition
|
||||
- Storage of keys used by the UEFI Secure Key specification inside the secure RPMB hardware
|
||||
partition.
|
||||
- Storage of the bootloader, kernel and rootfs inside the user hardware partition using multiple
|
||||
software partition in the GPT format.
|
||||
|
||||
Firmware
|
||||
========
|
||||
|
||||
The firmware of the device should implement a subset of the UEFI specification as defined in the
|
||||
ARM Base Boot Requirements (EBBR) and should implement the optional UEFI Secure Boot part of the
|
||||
EBBR specifications.
|
||||
|
||||
This is done in CoreOS by levering the built-in EBBR and UEFI Secure Boot present into the u-boot
|
||||
project.
|
||||
|
||||
The hardware should verify the validity of the firmware using a hardware specific way. Then the
|
||||
generic secure boot concept explained here can be used to valide all the following component of
|
||||
CoreOS.
|
||||
|
||||
UEFI Key used by UEFI Secure Boot
|
||||
=================================
|
||||
|
||||
|
||||
- **PK (Platform Key)**: This top-tier key shoulders the responsibility of KEK verification and its
|
||||
potential revocation. PK holders have the exclusive privilege to configure the KEK and the `db`
|
||||
database. It's the gatekeeper ensuring only authorized software can touch the firmware or
|
||||
bootloader.
|
||||
|
||||
- **KEK (Key Exchange Key)**: As a medium for data exchange, the KEK is pivotal for signing the `db`
|
||||
and `dbx` databases.
|
||||
|
||||
- **db (Allowed Database)**: This is the white list. It houses the keys or hashes of permitted
|
||||
firmware and OS loaders. Execution is only granted to software with a signature that resonates
|
||||
with the keys/hashes in this database.
|
||||
|
||||
- **dbx (Forbidden Database)**: The black sheep are here. Housing keys or hashes of known
|
||||
unauthorized software, it ensures any associated software is prohibited from executing.
|
||||
|
||||
Currently all theses public keys are built-in into u-boot at build time and are read only. In the
|
||||
future we will use the OP-TEE support into u-boot to use OP-TEE to manage the keys.
|
||||
|
||||
OP-TEE and RPMB as key manager
|
||||
==============================
|
||||
|
||||
OP-TEE, or Open Portable Trusted Execution Environment, is an open-source implementation of the
|
||||
Trusted Execution Environment (TEE) designed for ARM-powered platforms. In essence, a TEE is a
|
||||
secure enclave that provides a separated, isolated environment where specific applications and their
|
||||
data can run independently from the regular operating system, ensuring they are protected against
|
||||
potential tampering or unauthorized access.
|
||||
|
||||
OP-TEE guarantees confidentiality, integrity, and authenticity for critical applications by
|
||||
executing them in this secure space. It offers a wide range of security features, including secure
|
||||
storage of cryptographic keys, secure boot, and hardware-backed crypto operations.
|
||||
|
||||
In the context of UEFI secure boot, OP-TEE becomes instrumental. UEFI's secure boot mechanism
|
||||
ensures that only trusted, signed firmware, OS loaders, and OS kernels are executed during the boot
|
||||
process. To enforce this level of trust, UEFI relies on a set of cryptographic keys, including PK
|
||||
(Platform Key), KEK (Key Exchange Key), and db/dbx (allowed and forbidden signature databases).
|
||||
Safeguarding these keys is paramount to maintain the security and integrity of the boot process.
|
||||
|
||||
By leveraging OP-TEE, these UEFI secure boot keys can be securely stored in the RPMB (Replay
|
||||
Protected Memory Block) partition of the eMMC. The RPMB is a write-protected, secure area of the
|
||||
eMMC designed to hold sensitive data and protect it against tampering and replay attacks.
|
||||
Since OP-TEE manages secure access to the RPMB partition, it ensures that the UEFI secure boot keys
|
||||
are not only safely stored but are also accessible only by authorized firmware components.
|
||||
|
||||
eMMC User Partition
|
||||
===================
|
||||
|
||||
The user partition of the eMMC must be structured using the GPT (GUID Partition Table) format.
|
||||
|
||||
Within the GPT-formatted user partition, specific partitions should be established for efficient
|
||||
booting and system operation:
|
||||
|
||||
1. **EFI**: This is the Essential Firmware Interface partition. It holds the `efibootguard`
|
||||
os-loader binary, responsible for the boot sequence's initial steps and the kernel's selection
|
||||
based on its configuration. This binary is signed with a key present in the `dbx` database
|
||||
|
||||
2. **EBG0 - Efibootguard Config 0**: This partition houses the `efibootguard` configuration for the
|
||||
first kernel option. Alongside the configuration file, it also contains a Unified Kernel Image
|
||||
(UKI), a bundled package comprising the Linux kernel, device trees, and associated boot
|
||||
components. The UKI is signed with a key present in the `dbx` database
|
||||
|
||||
3. **EBG1 - Efibootguard Config 1**: Similar to EBG0, this partition carries the `efibootguard`
|
||||
configuration for the second kernel option. It too holds a Unified Kernel Image tailored for this
|
||||
alternate boot choice.
|
||||
|
||||
4. **rootfs0**: This partition stores the CoreOS root filesystem designed to complement and operate
|
||||
with the kernel embedded in the EBG0 partition. It provides the essential system files and
|
||||
structures required for the operating system's functioning when the kernel from EBG0 is booted.
|
||||
Integrety of this rootfs is assured by storing an hash of the rootfs inside the UKI image.
|
||||
|
||||
5. **rootfs1**: Analogous to `rootfs0`, this partition houses the CoreOS root filesystem tailored
|
||||
for the kernel within the EBG1 partition. It ensures that, should the system boot from the kernel
|
||||
in EBG1, the appropriate file structures and system components are readily available.
|
||||
|
||||
EFIBootGuard Configuration
|
||||
==========================
|
||||
|
||||
Efibootguard, as a part of its design, employs a configuration system to determine the appropriate
|
||||
kernel and associated resources to boot from. This configuration is stored in distinct partitions,
|
||||
EBG0 and EBG1, each holding its configuration file.
|
||||
|
||||
The configuration file itself comprises several fields, but most crucially, it contains a revision
|
||||
field. This field is a numerical identifier indicating the version or update level of the contained
|
||||
kernel and resources. When the system initiates its boot sequence, Efibootguard assesses the
|
||||
revision values in both the EBG0 and EBG1 configuration files.
|
||||
|
||||
The selection process is straightforward yet robust: Efibootguard chooses the partition with the
|
||||
higher revision value. By doing so, it inherently opts for the most recent or updated kernel version
|
||||
available. However, this system also supports failover mechanisms. In case the kernel in the
|
||||
partition with the higher revision encounters issues during boot, Efibootguard can revert to the
|
||||
other partition, ensuring resilience and continuity in system operations.
|
||||
|
||||
Moreover, the choice isn't rigidly fixed. When the system undergoes updates, the configuration files
|
||||
can be rewritten, and the revision values adjusted, allowing for dynamic and flexible booting in
|
||||
line with system evolutions and updates. In essence, Efibootguard, with its configuration-based
|
||||
approach, ensures a blend of up-to-date system booting and built-in fail-safes for dependable
|
||||
operation.
|
||||
|
||||
Unified Kernel Image
|
||||
====================
|
||||
|
||||
After having choosen the right configuration file, Efibootguard takes on the responsibility of
|
||||
launching the Unified Kernel Image (UKI) linked with the active configuration. This image bundle
|
||||
together essential boot components like the Linux kernel, device trees, and the kernel command
|
||||
line. The secure initiation of this image is paramount, and Efibootguard ensures this by leveraging
|
||||
UEFI's start_image system call.
|
||||
|
||||
The UEFI start_image system call verifies the image's signature against the Secure Boot keys
|
||||
(PK, KEK, db, and potentially dbx). If the signature matches, indicating that the image is trusted
|
||||
and hasn't been tampered with, the image is permitted to execute. If not, the booting halts,
|
||||
preventing any unauthorized or potentially malicious code from running.
|
||||
|
||||
Once the UKI has been securely initiated, it undertakes multiple tasks. It first extracts the
|
||||
necessary components from the bundled package, identifying and utilizing the appropriate device
|
||||
trees based on `compatible` node, by matching with the `compatible` node of the `device-tree` that
|
||||
is built into the firmware. These device trees inform the system about the hardware configuration,
|
||||
ensuring the kernel interacts correctly with the system's components.
|
||||
|
||||
The UKI os-launcher also has CoreOS specialized patches, enabling dynamic rootfs switching without
|
||||
requiring an initramfs by changing the `root=` part of the kernel command line at run time to
|
||||
point to the right rootfs partition.
|
||||
|
||||
RootFS and dm-verity
|
||||
====================
|
||||
|
||||
dm-verity is a Linux kernel feature designed to provide transparent integrity checking of block
|
||||
devices, particularly for read-only file systems. Rooted in cryptographic principles, dm-verity
|
||||
employs a hash-based approach to ensure and validate the integrity of the root filesystem (rootfs).
|
||||
|
||||
The way dm-verity operates is by building a Merkle tree, a structure where each leaf node contains a
|
||||
hash of a block of the underlying data, while each non-leaf node is a hash of its children. The
|
||||
topmost node, the root of the Merkle tree, provides a cumulative hash representing the entirety of
|
||||
the data. This top hash, known as the root hash, serves as a concise, cryptographic representation
|
||||
of the entire filesystem's state.
|
||||
|
||||
When integrating dm-verity with the Unified Kernel Image (UKI), an additional layer of security is
|
||||
established. By embedding the root hash into the signed UKI, any tampering or modification in the
|
||||
rootfs can be swiftly detected. When the system boots, the UKI, being signed, ensures that the
|
||||
embedded root hash is legitimate and untampered. As the OS accesses the rootfs, dm-verity
|
||||
recalculates the hash values in real-time and compares them to the values in the original Merkle
|
||||
tree, referenced by the embedded root hash.
|
||||
|
||||
If any discrepancies are found – that is, if the recalculated hash doesn't match the stored value –
|
||||
it indicates potential tampering, and the OS can halt access or take appropriate measures.
|
||||
|
||||
.. graphviz::
|
||||
|
||||
digraph SecureBootFlow {
|
||||
rankdir=TB;
|
||||
|
||||
node [shape=box, style=filled, fillcolor="#e6f2ff"];
|
||||
edge [color="#0099cc", fontsize=12];
|
||||
|
||||
Hardware [label="Hardware\n(ARM32/AARCH64 with eMMC)"];
|
||||
Firmware [label="u-boot Firmware\n(UEFI EBRR subset)"];
|
||||
eMMCConfig [label="eMMC Configuration\n(GPT with EFI partition)"];
|
||||
EFIBootGuard [label="EFIBootGuard\n(A/B Kernel Switching)"];
|
||||
UnifiedKernel [label="Unified Kernel Image\n(Kernel, cmd line, DTB)"];
|
||||
KernelAndRootFS [label="Kernel & RootFS\n(dm-verity validation)"];
|
||||
|
||||
Hardware -> Firmware [label="Flashed with u-boot\n+ Built-in keys"];
|
||||
Firmware -> eMMCConfig [label="eMMC boot"];
|
||||
eMMCConfig -> EFIBootGuard [label="Boots from EFI partition"];
|
||||
EFIBootGuard -> UnifiedKernel [label="Selects kernel A/B"];
|
||||
UnifiedKernel -> KernelAndRootFS [label="Kernel boot\n+ RootFS verification"];
|
||||
|
||||
}
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
************************
|
||||
Using U-Boot as Firmware
|
||||
************************
|
||||
****************
|
||||
Firmware: U-Boot
|
||||
****************
|
||||
|
||||
U-boot can be configured to support the EBBR specification. This can be
|
||||
enabled by enabling both `CONFIG_EFI_LOADER` and
|
||||
|
|
@ -21,10 +21,21 @@ to be changed at runtime.
|
|||
Device tree handling
|
||||
====================
|
||||
|
||||
As per the EBBR specification, the firmware is responsible to provide a
|
||||
device tree to the kernel. Not that it's OK to export the device tree used by
|
||||
U-Boot internally as it will be replaced by a propper device tree at a later
|
||||
stage. This avoid the need to load the device tree from a boot partition.
|
||||
As per the EBBR specification, the firmware is responsible to provide a basic
|
||||
device tree to the kernel.
|
||||
|
||||
This means that we have to build u-boot with an embedded device tree. On a
|
||||
machine configuration, this mean settings the `UBOOT_BUILDENV_DEVICE_TREE`
|
||||
variables.
|
||||
|
||||
The kernel can then override the built-in device-tree to use another.
|
||||
|
||||
.. important::
|
||||
|
||||
The `compatible` field of the device-tree embedded inside `u-boot` has to
|
||||
match with the one used inside the kernel. This allow us to automatically
|
||||
load the right `device-tree` inside the unified kernel image (UKI).
|
||||
|
||||
|
||||
Features to implement per machine
|
||||
=================================
|
||||
|
|
@ -32,15 +43,12 @@ Features to implement per machine
|
|||
The u-boot provided by CoreOS should implement the following features for each
|
||||
supported machine:
|
||||
|
||||
extension_board_scan
|
||||
--------------------
|
||||
|
||||
The extension_board_scan function has to be implemented. This function should
|
||||
return the list of add-ons board detected.
|
||||
|
||||
DT Fixup
|
||||
--------
|
||||
|
||||
U-Boot can create, modify and remove node from the device tree dynamically
|
||||
before starting the kernel. This can be used to pass dynamic information stored
|
||||
inside a "board descriptor" eeprom or CPLD to the Kernel.
|
||||
An EFI application like a UKI can overwrite the built-in device tree with a
|
||||
custom one. The DT Fixup Protocol allow an application to ask the firmware to
|
||||
some runtime fix to the new device tree, like enabling or removing node.
|
||||
|
||||
This can be used to pass dynamic information stored inside a "board descriptor"
|
||||
eeprom or CPLD to the Kernel.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
******************************
|
||||
OS: Unified Kernel Image (UKI)
|
||||
******************************
|
||||
|
||||
|
|
@ -1,104 +0,0 @@
|
|||
.. index:: EFIBOOTGUARD
|
||||
|
||||
Bootloader: EFIBootGuard
|
||||
************************
|
||||
|
||||
CoreOS use `EFIBootGuard <https://github.com/siemens/efibootguard>`_ as a
|
||||
bootloader. EFIBootGuard is the components responsible to find and load the
|
||||
right Unified Kernel Image (UKI).
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
EFIBootGuard is an UEFI application. It's installed inside the EFI System
|
||||
Partition at:
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 25
|
||||
:header-rows: 1
|
||||
|
||||
* - Platform Architecture
|
||||
- Path
|
||||
* - ARM32
|
||||
- /EFI/BOOT/bootarm.efi
|
||||
* - ARM64
|
||||
- /EFI/BOOT/bootaa64.efi
|
||||
* - x86_64
|
||||
- /EFI/BOOT/bootax64.efi
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
Configuration lookup
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When started, EFIBootGuard will scan all vFAT partition to list all the valid
|
||||
boot partition.
|
||||
|
||||
A valid boot partition is a vFAT partition that contain a valid BGENV.DAT file.
|
||||
|
||||
This file contains the following parameters:
|
||||
|
||||
- Path to a Kernel file
|
||||
- Parameter to pass to the kernel
|
||||
- Flag for in progress update
|
||||
- Update Status (OK, INSTALLED, TESTING, FAILED)
|
||||
- Watchdog timeout
|
||||
- Revision numbers
|
||||
- User data (not used)
|
||||
|
||||
Consistency of the configuration is guaranteed by a CRC check.
|
||||
|
||||
.. hint::
|
||||
CoreOS use a signed Unified Kernel Image that embed the parameters to pass
|
||||
to the Linux Kernel. Parameters from the UKI always override parameters
|
||||
set inside the EFIBootGuard configuration file.
|
||||
|
||||
This is a security measure to ensure that only a signed kernel parameters is
|
||||
used (secure boot).
|
||||
|
||||
Booting
|
||||
~~~~~~~
|
||||
|
||||
EFIBootGuard will try to load a kernel using the parameters from the
|
||||
configuration with the higher revision number.
|
||||
|
||||
Update Handling
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Before booting, EFIBootGuard will check the state flags inside the configuration
|
||||
file.
|
||||
|
||||
If it's OK it means that it's a valid configuration.
|
||||
|
||||
If the state is INSTALLED, it's mean that a new image was flash but was never
|
||||
booted. EFIBootGuard will change the state to TESTING then boot the kernel.
|
||||
|
||||
If the state is TESTING, it's mean that the kernel was already booted one time,
|
||||
but the running system has not marked the update as working. EFIBootGuard will
|
||||
set the status to FAILED and set the revision number to 0 and boot another
|
||||
configuration.
|
||||
|
||||
.. hint::
|
||||
To mark the update as working from a running system, you can use the
|
||||
following command::
|
||||
|
||||
bg_setenv --confirm
|
||||
|
||||
This should be done after an update to tell the bootloader that the new
|
||||
system image is working. CoreOS doesn't do it automatically for now.
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
.. list-table::
|
||||
:widths: 15 85
|
||||
:header-rows: 1
|
||||
|
||||
* - Bugs
|
||||
- Description
|
||||
* - `#370558 <https://tp.gad.local/entity/370558>`_
|
||||
- On machine use a Marvel CN913x CPU like the cn9130-cf-pro machine, the version
|
||||
of U-Boot provided don't provide the UEFI api needed by EFIBootGuard to update
|
||||
his configuration file at boot time. EFIBootGuard is not able to detect
|
||||
a failed update.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
======================
|
||||
CoreOS Core Components
|
||||
======================
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
Firmware: U-Boot <u-boot>
|
||||
Bootloader: EFIBootGuard <efibootguard>
|
||||
Kernel: Unified Kernel Image <kernel>
|
||||
Init System: SystemD <systemd>
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
.. index:: UKI
|
||||
|
||||
Kernel: Unified Kernel Image
|
||||
*****************************
|
||||
|
||||
CoreOS use by default a `Unified Kernel Image (UKI) <https://github.com/siemens/efibootguard/blob/master/docs/UNIFIED-KERNEL.md>`_
|
||||
generated by tools from the EFIBootGuard project.
|
||||
|
||||
An UKI is a EFI app that load in memory multiple artifacts needed by the Linux
|
||||
Kernel before loading and booting the Linux Kernel itself:
|
||||
|
||||
* The kernel commands line is always loaded from the UKI
|
||||
* A device-tree file: UKI can contain multiple UKI and will load the one
|
||||
matching the device-tree file passed by the firmware.
|
||||
|
||||
Known Issues and unimplemented feature
|
||||
--------------------------------------
|
||||
|
||||
.. note::
|
||||
|
||||
Bundling an INITRD image into the UKI is not implemented yet.
|
||||
|
||||
.. danger::
|
||||
|
||||
The Unified Kernel Image is signed but CoreOS currently provide no way to
|
||||
verify the integrity of the choosed ROOTFS partition as CoreOS doesn't
|
||||
provide an end-to-end secure boot solution yet.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
.. index:: SYSTEMD
|
||||
|
||||
Init System: SystemD
|
||||
********************
|
||||
|
||||
`SystemD <https://www.freedesktop.org/wiki/Software/systemd/>`_ is used as
|
||||
init system in CoreOS.
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
.. index:: UBOOT
|
||||
|
||||
Firmware: U-Boot
|
||||
****************
|
||||
|
||||
.. hint::
|
||||
CoreOS should work with any UEFI compliant firmware. Using U-Boot is not
|
||||
mandatory.
|
||||
|
||||
`U-Boot <https://u-boot.readthedocs.io/en/latest/>`_ is built by default with
|
||||
UEFI enabled and secure boot enabled. UEFI secure boot related keys are
|
||||
installed at build time and can't be changed from the U-Boot command line.
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
U-Boot will boot the default UEFI application from the EFI System Partition.
|
||||
|
||||
The path to the default UEFI application is architecture dependent:
|
||||
|
||||
.. list-table::
|
||||
:widths: 25 25
|
||||
:header-rows: 1
|
||||
|
||||
* - Platform Architecture
|
||||
- Path
|
||||
* - ARM32
|
||||
- /EFI/BOOT/bootarm.efi
|
||||
* - ARM64
|
||||
- /EFI/BOOT/bootaa64.efi
|
||||
* - x86_64
|
||||
- /EFI/BOOT/bootax64.efi
|
||||
|
||||
Known Issues
|
||||
------------
|
||||
|
||||
.. danger::
|
||||
|
||||
The U-Boot configuration used by CoreOS currently was not reviewed for
|
||||
security issue and is not safe (access to u-boot command line is allowed).
|
||||
|
||||
.. danger::
|
||||
|
||||
CoreOS U-Boot configuration enable UEFI Secure Boot but the U-Boot binary
|
||||
itself is not validated. Thus we don't provide a full end-to-end secure boot
|
||||
solution yet.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
==========================
|
||||
CoreOS Optional Components
|
||||
==========================
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
Network Manager: NetworkManager <networkmanager>
|
||||
SSH Server: OpenSSH <openssh>
|
||||
Container: Podman <podman>
|
||||
CoreOS Installer <installer>
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
.. index:: COREOS_INSTALLER
|
||||
|
||||
CoreOS Installer
|
||||
****************
|
||||
|
||||
The CoreOS installer is a set of scripts running on the target and a
|
||||
corresponding bitbake image that is used into the bootstrap process of CoreOS.
|
||||
|
||||
coreos-image-installer
|
||||
======================
|
||||
|
||||
The CoreOS image installer results in an image contairing only a single binary
|
||||
EFI file. This EFI file includes a kernel, a device tree and an initramfs with
|
||||
all (and only) the tools needed to install CoreOS.
|
||||
|
||||
The installer image is not automatically built in parallel of a normal image.
|
||||
This can be changed by setting `COREOS_IMAGE_GENERATE_INSTALLER` to 1 in the
|
||||
image file (as it is done for example in coreos-image-all-features.bb).
|
||||
|
||||
The installer image build by default only a single EFI binary named
|
||||
coreos-installer-MACHINE.efi. An SDCard or USB image can be generated if
|
||||
`COREOS_INSTALLER_WKS_FILE` is set to a wks file.
|
||||
|
||||
coreos-installer
|
||||
================
|
||||
|
||||
The coreos-installer recipe installs scripts that are used at startup to
|
||||
automatically format the internal emmc of the device. The recipe also contains
|
||||
a swupdate configuration file to setup swupdate correctly for that use case.
|
||||
|
||||
coreos-installer-config
|
||||
=======================
|
||||
|
||||
The coreos-installer-config recipe installs device specific configuration file
|
||||
used by the coreos-installer. This includes the partitioner config file. Distros
|
||||
and projects based on CoreOS can change the partioning scheme or partition size
|
||||
by installing their own version of this package using a `bbappend file`.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
.. index:: NETWORKMANAGER
|
||||
|
||||
Network Manager: NetworkManager
|
||||
*******************************
|
||||
|
||||
You can add `NetworkManager <https://networkmanager.dev/>`_ to an image that
|
||||
inherit from `coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "networkmanager"
|
||||
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
.. index:: OPENSSH
|
||||
|
||||
SSH Server: OpenSSH
|
||||
*******************
|
||||
|
||||
You can add an `OpenSSH <https://www.openssh.com/>`_ based ssh server to an
|
||||
image that inherit from `coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "ssh-server"
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
.. index:: PODMAN
|
||||
|
||||
Container: Podman
|
||||
*****************
|
||||
|
||||
You can add `Podman <https://podman.io/>`_ to an image that inherit from
|
||||
`coreos-image` by adding::
|
||||
|
||||
IMAGE_FEATURES += "podman"
|
||||
|
|
@ -42,8 +42,8 @@ extensions = [
|
|||
'sphinx.ext.intersphinx',
|
||||
'sphinx.ext.todo',
|
||||
'sphinx.ext.graphviz',
|
||||
'sphinxcontrib.plantuml',
|
||||
]
|
||||
# 'sphinxcontrib.plantuml',
|
||||
|
||||
|
||||
# external links and substitutions
|
||||
|
|
@ -112,10 +112,6 @@ except ImportError:
|
|||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
html_css_files = [
|
||||
'css/coreos.css',
|
||||
]
|
||||
|
||||
# Hide 'Created using Sphinx' text
|
||||
html_show_sphinx = False
|
||||
|
||||
|
|
|
|||
|
|
@ -1,61 +0,0 @@
|
|||
.. _beaglebone:
|
||||
|
||||
**********
|
||||
BeagleBone
|
||||
**********
|
||||
|
||||
.. important::
|
||||
|
||||
The BeagleBone target uses an old TI AM3358 ARM 32 BIT CPU. This processor
|
||||
of the AM335x family is used in a lot of current and legacy device at
|
||||
Hirschmann and NetModule. Thus we only support this target to ensure
|
||||
that our architecture is working on older architecture too.
|
||||
|
||||
CoreOS build instruction
|
||||
========================
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=beaglebone bitbake coreos-image-all-features
|
||||
cd tmp/deploy/images/beaglebone
|
||||
|
||||
.. list-table:: Image artifacts for BeagleBone
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Filename
|
||||
- Description
|
||||
* - <IMAGE>-beaglebone.swu
|
||||
- System image bundle used by the CoreOS installer or the CoreOS updater
|
||||
* - <IMAGE>-beaglebone.wic.xz
|
||||
- System image for SDCard
|
||||
* - coreos-image-installer-beaglebone.wic.xz
|
||||
- CoreOS installer image for SD Card
|
||||
|
||||
.. hint::
|
||||
|
||||
Only the .swu image is need if you have already a working installation of CoreOS
|
||||
running on the board that you want to update.
|
||||
|
||||
CoreOS Pre-installation guide
|
||||
=============================
|
||||
|
||||
If you want to use the internal emmc storage as boot target, you will need to
|
||||
flash coreos-image-installer-beaglebone.wic.xz to your SDCard using bmaptool.
|
||||
|
||||
If you want to use the sdcard as boot target, you will need to flash
|
||||
<IMAGE>-beaglebone.wic.xz to your SDCard using bmaptool.
|
||||
|
||||
By default the board boot on the internal emmc storage. To boot with a SDCard
|
||||
instead, you will need to push the S2 button (boot switch) while powering up the
|
||||
board.
|
||||
|
||||
.. image:: beaglebone/beaglebone-s2-switch.png
|
||||
|
||||
Serial access is available on the 5-pin header. See
|
||||
`this page <https://elinux.org/Beagleboard:BeagleBone_Black_Serial>`_ for
|
||||
more info on the serial connector.
|
||||
|
||||
Now that you have the installer running, CoreOS can be installed by following
|
||||
the :ref:`generic installation manual<Installation Manual>` using the SDCard
|
||||
mehtod.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 246 KiB |
|
|
@ -1,126 +0,0 @@
|
|||
.. _netmodule-hw34:
|
||||
|
||||
*******************************
|
||||
NetModule HW34 (XG900 A-Sample)
|
||||
*******************************
|
||||
|
||||
.. important::
|
||||
|
||||
netmodule-hw34 support is currently only available on the features branch
|
||||
feat/netmodule-bsp
|
||||
|
||||
.. image:: netmodule-hw34/hw34.png
|
||||
|
||||
CoreOS build instruction
|
||||
========================
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=netmodule-hw34 bitbake coreos-image-all-features
|
||||
cd tmp/deploy/images/netmodule-hw34
|
||||
|
||||
.. list-table:: Image artifacts for NetModule HW32
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Filename
|
||||
- Description
|
||||
* - <IMAGE>-netmodule-hw34.swu
|
||||
- System image bundle used by the CoreOS installer or the CoreOS updater
|
||||
* - coreos-installer-netmodule-hw34.efi
|
||||
- CoreOS installer bundled in a single EFI binary
|
||||
* - tiboot3.bin
|
||||
- SPL Bootloader for the wakeup domain (arm32 R5 core)
|
||||
* - tispl.bin
|
||||
- SPL bootloader for the main domain (aarch64 main core)
|
||||
* - u-boot.bin
|
||||
- Third stage bootloader the main domain (aarch64 main core)
|
||||
|
||||
.. hint::
|
||||
|
||||
Only the .swu image is need if you have already a working installation of CoreOS
|
||||
running on the board that you want to update.
|
||||
|
||||
CoreOS Pre-installation guide
|
||||
=============================
|
||||
|
||||
The CoreOS installation process expect a working EFI firmware based on u-boot
|
||||
running on the board.
|
||||
|
||||
For board that have no firmware or a defect firmware, we can provide the firmware by
|
||||
booting over USB.
|
||||
|
||||
First, we need to put the board in USB Boot mode by modifying the dip-switch
|
||||
on the back of the board:
|
||||
|
||||
.. code-block::
|
||||
|
||||
ON
|
||||
S500 ▄ ▀ ▄ ▀ ▄ ▄ ▄ ▄
|
||||
1 2 3 4 5 6 7 8
|
||||
|
||||
.. hint::
|
||||
|
||||
Unflashed board or board without a valid tiboot3.bin image will default to
|
||||
USB boot mode, so settings the dip-switch may be skipped in this case.
|
||||
|
||||
Then you need to populate the jumper X600 near the USB port:
|
||||
|
||||
.. image:: netmodule-hw34/hw34-usb-device.png
|
||||
|
||||
Then power-up the board by first apply 12V throug the main connector, then
|
||||
connect a USB-C cable. Console access to the board can be accessed using the
|
||||
serial port on the main connector.
|
||||
|
||||
|
||||
.. important::
|
||||
|
||||
When removing the power, ensure that the USB cable is removed first. Otherwise
|
||||
the processor will not get shutdown properly
|
||||
|
||||
|
||||
Now you should see the board from you computer:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
lsusb | grep DFU
|
||||
Bus 003 Device 048: ID 0451:6165 Texas Instruments, Inc. AM64x DFU
|
||||
|
||||
Now we start downloading the bootloaders into RAM by using dfu-utils:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
dfu-util -D tiboot3.bin -a 0
|
||||
dfu-util -D tispl.bin -a 0
|
||||
|
||||
# Eject and start execution of tispl
|
||||
dfu-util -e -a 0
|
||||
dfu-util -D u-boot.img -a 1
|
||||
|
||||
# Eject ans tart of u-boot.img
|
||||
dfu-util -e -a 1
|
||||
|
||||
.. hint::
|
||||
|
||||
The firmware was uploaded to the RAM, thus will not survice a reboot.
|
||||
|
||||
|
||||
Now that we have a firmware running, CoreOS can be installed by following
|
||||
the :ref:`generic installation manual<Installation Manual>`.
|
||||
|
||||
|
||||
CoreOS Post-Installation
|
||||
========================
|
||||
|
||||
When the installation of CoreOS is done, power down the board by first
|
||||
removing the USB-C cable then the main power.
|
||||
|
||||
Now, put the board back in emmc boot mode:
|
||||
|
||||
.. code-block::
|
||||
|
||||
ON
|
||||
S500 ▀ ▄ ▄ ▀ ▄ ▄ ▄ ▄
|
||||
1 2 3 4 5 6 7 8
|
||||
|
||||
Then power-up the board again and CoreOS should boot.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 3.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 MiB |
|
|
@ -1,33 +0,0 @@
|
|||
******************
|
||||
Supported Hardware
|
||||
******************
|
||||
|
||||
.. _Hardware Overview:
|
||||
.. list-table:: Supported BitBake MACHINE
|
||||
:widths: 25 75 25
|
||||
:header-rows: 1
|
||||
|
||||
* - BitBake MACHINE
|
||||
- Compatible hardware
|
||||
- Documentation
|
||||
* - cn9131-bldn-mbv
|
||||
- Falcon A3 Sample
|
||||
-
|
||||
* - netmodule-hw34
|
||||
- NetModule HW34 (XG900 Sample)
|
||||
- :ref:`🔗 links <netmodule-hw34>`
|
||||
* - cn9130-cf-pro
|
||||
- Solidrun cn9130-cf-pro
|
||||
-
|
||||
* - beaglebone
|
||||
- Beaglebone, Beaglebone Black, Beaglebone Green
|
||||
- :ref:`🔗 links <beaglebone>`
|
||||
* - vm-x64
|
||||
- Virtual Machine
|
||||
-
|
||||
|
||||
.. hint::
|
||||
|
||||
Please contact the CoreOS team when starting a new project based on CoreOS
|
||||
or want to contribute the hardware support for an existing Hardware.
|
||||
|
||||
|
|
@ -26,30 +26,12 @@ same structures.
|
|||
Setting up a CoreOS based distro <using-coreos>
|
||||
Building and using a Container Image <using-container>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Supported Hardware
|
||||
|
||||
Overview <hardware/overview>
|
||||
NetModule HW34 (XG900 Sample) <hardware/netmodule-hw34>
|
||||
BeagleBone <hardware/beaglebone>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Manuals
|
||||
|
||||
Installation Manual <installation/index>
|
||||
Reference Manual <ref-manual/index>
|
||||
Testing Manual <testing/index>
|
||||
Boot Concepts <boot/index>
|
||||
Best Practices <best_practices/index>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Software Components
|
||||
|
||||
Core Components <components/core/index>
|
||||
Optional Components <components/optional/index>
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -1,22 +0,0 @@
|
|||
|
||||
.. _Installation Manual:
|
||||
|
||||
======================================
|
||||
Belden CoreOS EMMC Installation Manual
|
||||
======================================
|
||||
|
||||
.. important::
|
||||
|
||||
This manual expect that the board you want to install CoreOS on have a
|
||||
running UEFI firmware based on u-boot. Information about how to get console
|
||||
access and a running firmware can be found for your hardware in the
|
||||
:ref:`Hardware Overview <Hardware Overview>`
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
starting
|
||||
partitionning
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
************
|
||||
Installation
|
||||
************
|
||||
|
||||
The installer automatically creates all the needed partitions when starting up.
|
||||
|
||||
Now you have to upload the .swu file to start the flashing process.
|
||||
|
||||
Choose one of these methods to upload the system image to the installer:
|
||||
|
||||
Upload the .swu file over the network using a browser
|
||||
=====================================================
|
||||
|
||||
|
||||
Now you can install the desired CoreOS version by uploading the desired
|
||||
.swu file to the board using a browser, by going to http://<TARGET_IP>:8080
|
||||
|
||||
Upload the .swu file over the network using devtool
|
||||
===================================================
|
||||
|
||||
If you have a working build environement, you can upload the image using
|
||||
the devtool command:
|
||||
|
||||
.. code-block::
|
||||
|
||||
MACHINE=<MACHINE> devtool swupdate-www-push <IMAGE> <TARGET_IP>
|
||||
|
||||
|
||||
.. hint::
|
||||
Replace <IMAGE> with the image recipe name, eg: coreos-image-all-features
|
||||
Replace <MACHINE> by the machine name (if not set in local.conf)
|
||||
Replace <TARGET_IP> by the IP adress of the board
|
||||
|
||||
Upload the .swu file over the network using coreos-device
|
||||
=========================================================
|
||||
|
||||
If you don't have a working build environement, you can upload the image using
|
||||
the coreos-device python script:
|
||||
|
||||
.. code-block::
|
||||
|
||||
./coreos-device swupdate-www-push <SWU_PATH> <TARGET_IP>
|
||||
|
||||
.. hint::
|
||||
Replace <SWU_PATH> with the the path to the SWU, eg: ./coreos-image-all-features-<MACHINE>.swu
|
||||
Replace <TARGET_IP> by the IP adress of the board
|
||||
|
||||
.. hint::
|
||||
You will find the coreos-device script under the scripts directory inside
|
||||
the CoreOS repository.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
**********************
|
||||
Starting the installer
|
||||
**********************
|
||||
|
||||
Choose one of these methods to start the bootloader:
|
||||
|
||||
Starting the installer over the network with TFTP
|
||||
=================================================
|
||||
|
||||
Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into an
|
||||
accessible TFTP server, then enter the following command into u-boot:
|
||||
|
||||
.. code-block::
|
||||
|
||||
setenv ipaddr <TARGET_IP>; setenv serverip <SERVER_IP>;
|
||||
tftp $loadaddr coreos-installer-<MACHINE>.efi
|
||||
bootefi $loadaddr
|
||||
|
||||
.. hint::
|
||||
|
||||
Replace <TARGET_IP> by a valid IP adress for the target, eg: 192.168.1.1
|
||||
Replace <SERVER_IP> by the IP adress of the server, eg: 192.168.1.254
|
||||
Replace <MACHINE> by the name of the machine set in bitbake
|
||||
|
||||
Starting the installer over the network with DHCP/BOOTP/TFTP
|
||||
============================================================
|
||||
|
||||
Use a DHCP/BOOTP/TFTP server to configure automatically the device. You can
|
||||
use dnsmasq for this task.
|
||||
|
||||
|
||||
.. code-block: ini
|
||||
|
||||
interface=<INTERFACE>
|
||||
|
||||
dhcp-range=<INTERFACE>,10.237.30.2,10.237.30.100,4h
|
||||
dhcp-range=<INTERFACE>,10.237.40.2,10.237.40.100,4h
|
||||
|
||||
enable-tftp
|
||||
dhcp-boot=tag:<INTERFACE>,coreos-installer-<MACHINE>.efi
|
||||
tftp-root=/var/lib/tftpboot
|
||||
|
||||
.. hint::
|
||||
|
||||
Replace <INTERFACE> by the name of the network interface that is connected
|
||||
to the target. Eg: enp3s0
|
||||
Replace <MACHINE> by the name of the machine set in bitbake
|
||||
|
||||
Put the coreos-installer EFI bundle (coreos-installer-<MACHINE>.efi) into the
|
||||
/var/lib/tftpboot folder then enter the following command into u-boot:
|
||||
|
||||
.. code-block::
|
||||
|
||||
setenv autoload yes
|
||||
setenv autostart no
|
||||
dhcp
|
||||
bootefi $loadaddr
|
||||
|
||||
Starting the installer using an SD Card
|
||||
=======================================
|
||||
|
||||
Flash the coreos-image-installer.wic.xz into an SDCard and put the board
|
||||
in SDCard boot mode. Insert the SDCard and power up the board. The CoreOS
|
||||
installer should start automatically.
|
||||
|
|
@ -46,8 +46,7 @@ Theses packages are needed on your build machine:
|
|||
chrpath socat cpio python3 python3-pip python3-pexpect xz-utils \
|
||||
debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \
|
||||
libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd \
|
||||
liblz4-tool bmap-tools efitools openssl sbsigntool python3-click \
|
||||
python3-aiohttp
|
||||
liblz4-tool bmap-tools efitools openssl sbsign
|
||||
|
||||
Use Git to clone CoreOS
|
||||
########################
|
||||
|
|
@ -100,11 +99,11 @@ the machine is set to `cn9130-cf-pro` but you can use any other MACHINE listed i
|
|||
occurrences of `cn9130-cf-pro` to your machine when executing a command.
|
||||
|
||||
For an image that contains a lot of developer tools, the best image to build
|
||||
is `coreos-image-all-features`.
|
||||
is `coreos-image-full-cmdline`.
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
~/img-build/build$ bitbake coreos-image-all-features
|
||||
~/img-build/build$ bitbake coreos-image-full-cmdline
|
||||
|
||||
After a long time, the build system will return. You can list all the artifacts
|
||||
produced by `bitbake` using `ls`:
|
||||
|
|
@ -119,7 +118,7 @@ be found with this command:
|
|||
.. code-block:: sh
|
||||
|
||||
~/coreos/build$ find tmp/deploy/images/${MACHINE} -type l -name "*.wic.xz"
|
||||
tmp/deploy/images/cn9130-cf-pro/coreos-image-all-features-cn9130-cf-pro.wic.xz
|
||||
tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-cn9130-cf-pro.wic.xz
|
||||
|
||||
.. hint::
|
||||
|
||||
|
|
@ -167,6 +166,6 @@ Now, flash the image file to the your card:
|
|||
|
||||
.. code-block:: sh
|
||||
|
||||
~/coreos/build$ bmaptool copy tmp/deploy/images/cn9130-cf-pro/coreos-image-all-features-cn9130-cf-pro.wic.xz /dev/<DISKNAME>
|
||||
~/coreos/build$ bmaptool copy tmp/deploy/images/cn9130-cf-pro/coreos-image-full-cmdline-cn9130-cf-pro.wic.xz /dev/<DISKNAME>
|
||||
|
||||
You have to replace `<DISKNAME>` by the name of your SD Card device.
|
||||
|
|
|
|||
|
|
@ -6,14 +6,33 @@ This chapter document the classes that are provided by Belden CoreOS. Classes
|
|||
provided by OpenEmbedded-Core are documented in the
|
||||
:external:doc:`Yocto Reference Manual <ref-manual/classes>`.
|
||||
|
||||
.. _ref-classes-coreos-container-image:
|
||||
.. index:: coreos-container-image.bbclass
|
||||
|
||||
``coreos-container-image.bbclass``
|
||||
==================================
|
||||
|
||||
The ``coreos-container-image`` class provides common definitions to create
|
||||
a container image.
|
||||
:extern:ref:`IMAGE_FEATURE <ref-features-image>`.
|
||||
|
||||
.. _ref-classes-coreos-container-package:
|
||||
.. index:: coreos-container-package.bbclass
|
||||
|
||||
``coreos-container-image.bbclass``
|
||||
==================================
|
||||
|
||||
The ``coreos-container-package`` class provides common definitions to create
|
||||
a package a container image. This allow a container image to be preinstalled
|
||||
into a standard image.
|
||||
|
||||
.. _ref-classes-coreos-efi-secureboot:
|
||||
.. index:: coreos-efi-secureboot.bbclass
|
||||
|
||||
|
||||
``coreos-efi-secureboot.bbclass``
|
||||
=================================
|
||||
|
||||
The ``coreos-efi-secureboot`` class is a class made to be inherited in a global
|
||||
The ``coreos-efi-secureboot`` class is a class made to be ihnerited in a global
|
||||
configuration file. On the CoreOS distribution, this class is inherited inside
|
||||
the CoreOS distrubtion configuration file.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,14 +10,9 @@ to Belden CoreOS.
|
|||
Machine Features
|
||||
================
|
||||
|
||||
CoreOS doesn't define any custom machine feature for now, but the
|
||||
:external:ref:`MACHINE_FEATURES <ref-features-machine>` of OpenEmbedded-Core
|
||||
can be used with CoreOS.
|
||||
|
||||
In addition, those CoreOS specific MACHINE_FEATURES can be used too:
|
||||
|
||||
- *sdcard:* the machine as an internal SD Card or MicroSD Slot.
|
||||
- *emmc:* the machine as an internal emmc based storage
|
||||
|
||||
can be used.
|
||||
|
||||
.. index:: DISTRO_FEATURES
|
||||
|
||||
|
|
@ -51,7 +46,8 @@ The *cockpit* and *dev-tools* feature are special, as they will automatically
|
|||
add package based on the other image feature that are enabled.
|
||||
|
||||
:external:ref:`IMAGE_FEATURES <ref-features-image>` defined in OpenEmbedded-Core
|
||||
are also available, but note that the
|
||||
:ref:`coreos-image <ref-classes-coreos-image>` class don't inherit from the
|
||||
are also available, but note that neither the
|
||||
:ref:`coreos-image <ref-classes-coreos-image>` class and the
|
||||
:ref:`coreos-image <ref-classes-coreos-container-image>` inherit from the
|
||||
:external:ref:`core-image <ref-classes-core-image>` class, thus `core-image`
|
||||
specific features are not available.
|
||||
|
|
|
|||
|
|
@ -4,20 +4,12 @@ Images
|
|||
|
||||
The CoreOS build system provides several examples image:
|
||||
|
||||
.. index:: coreos-image-all-features
|
||||
.. index:: coreos-image-full-cmdline
|
||||
|
||||
``coreos-image-all-features``
|
||||
``coreos-image-full-cmdline``
|
||||
=============================
|
||||
|
||||
An image with most of the optional feature of CoreOS.
|
||||
|
||||
.. index:: coreos-image-demo
|
||||
|
||||
``coreos-image-demo``
|
||||
=============================
|
||||
|
||||
An image based on `coreos-image-all-features`` that has additional demo
|
||||
features activated.
|
||||
A console-only image with more full-featured Linux system functionality installed.
|
||||
|
||||
.. index:: coreos-image-minimal
|
||||
|
||||
|
|
|
|||
|
|
@ -1,354 +0,0 @@
|
|||
.. index:: BATS
|
||||
|
||||
************************************
|
||||
BATS - Bash Automated Testing System
|
||||
************************************
|
||||
|
||||
The CoreOS distribution supports writing tests using shell syntax by providing the `bats` command.
|
||||
|
||||
If you want to use `bats`, you will need the following CoreOS packages:
|
||||
|
||||
- bats
|
||||
- bats-file
|
||||
- bats-assert
|
||||
|
||||
Overview of BATS
|
||||
================
|
||||
|
||||
A BATS test can be as simple as a single .bats file. For example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
|
||||
@test "can output to stdout" {
|
||||
run echo hello
|
||||
assert_output 'hello'
|
||||
}
|
||||
|
||||
You can run it using the command `bats <filename>.bats`
|
||||
|
||||
This will give you the following output:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats <filename>.bats
|
||||
<filename>.bats
|
||||
✓ can output to stdout
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
The run command
|
||||
================
|
||||
|
||||
In shell tests, you often need to run commands and capture their output, exit
|
||||
status, and error messages. The run command provided by `bats` allows you to
|
||||
execute commands within your test cases and collect this information for later
|
||||
assertion and validation.
|
||||
|
||||
The run command will make the following variables available:
|
||||
|
||||
- `${status}`: exit code of the command run by `run`
|
||||
- `${output}`: combined content of `stdout` and `stderr`
|
||||
- `${lines[@]}`: array of lines of the output
|
||||
- `${BATS_RUN_COMMAND}`: command run by the `run` command
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "invoking foo with a nonexistent file prints an error" {
|
||||
run foo nonexistent_filename
|
||||
[ "$status" -eq 1 ]
|
||||
[ "$output" = "foo: no such file 'nonexistent_filename'" ]
|
||||
[ "$BATS_RUN_COMMAND" = "foo nonexistent_filename" ]
|
||||
|
||||
}
|
||||
|
||||
The `run` command accepts some parameters:
|
||||
|
||||
- `-N`: Expect N as exit status and fail otherwise
|
||||
- `-!`: Expect non-zero exit status and fail if the command succeeds.
|
||||
- `--keep-empty-lines`: don't remove empty lines from `${lines}`
|
||||
- `--separate-stderr`: Use separate variables for stderr `${stderr}` and `${stderr_lines[@]}`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "invoking foo without arguments prints usage" {
|
||||
run -1 foo
|
||||
[ "${lines[0]}" = "usage: foo <filename>" ]
|
||||
}
|
||||
|
||||
The bats-assert helper
|
||||
======================
|
||||
|
||||
The `bats-assert` helper provides some functions to create more readable tests.
|
||||
These assertions use the variables created by the `run` command and can be used
|
||||
as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test 'assert_output()' {
|
||||
run echo 'have'
|
||||
assert_output 'want'
|
||||
}
|
||||
|
||||
The following functions are provided:
|
||||
|
||||
- `assert` and `refute`: Assert that a given expression evaluates to true or false.
|
||||
- `assert_equal`: Assert that two parameters are equal.
|
||||
- `assert_not_equal`: Assert that two parameters are not equal.
|
||||
- `assert_success` and `assert_failure`: Assert that the exit status is 0 or 1.
|
||||
- `assert_output` and `refute_output`: Assert that the output does (or does not) contain the given content.
|
||||
- `assert_line` and `refute_line`: Assert that a specific line of the output does (or does not) contain the given content.
|
||||
- `assert_regex` and `refute_regex`: Assert that a parameter matches (or does not match) the given pattern.
|
||||
|
||||
The bats-file helper
|
||||
====================
|
||||
|
||||
The `bats-file` helper provides functions to help work with files in tests:
|
||||
|
||||
**Test File Types:**
|
||||
|
||||
- `assert_exists` and `assert_not_exists`: Check if a file or directory exists.
|
||||
- `assert_file_exists` and `assert_file_not_exists`: Check if a file exists.
|
||||
- `assert_dir_exists` and `assert_dir_not_exists`: Check if a directory exists.
|
||||
- `assert_link_exists` and `assert_link_not_exists`: Check if a link exists.
|
||||
- `assert_block_exists` and `assert_block_not_exists`: Check if a block special file exists.
|
||||
- `assert_character_exists` and `assert_character_not_exists`: Check if a character special file exists.
|
||||
- `assert_socket_exists` and `assert_socket_not_exists`: Check if a socket exists.
|
||||
- `assert_fifo_exists` and `assert_fifo_not_exists`: Check if a fifo special file exists.
|
||||
|
||||
**Test File Attributes:**
|
||||
|
||||
- `assert_file_executable` and `assert_file_not_executable`
|
||||
- `assert_file_owner` and `assert_file_not_owner`
|
||||
- `assert_file_permission` and `assert_not_file_permission`
|
||||
- `assert_file_size_equals`
|
||||
- `assert_size_zero` and `assert_size_not_zero`
|
||||
- `assert_file_group_id_set` and `assert_file_not_group_id_set`
|
||||
- `assert_file_user_id_set` and `assert_file_not_user_id_set`
|
||||
- `assert_sticky_bit` and `assert_no_sticky_bit`
|
||||
|
||||
**Test File Content:**
|
||||
|
||||
- `assert_file_empty` and `assert_file_not_empty`
|
||||
- `assert_file_contains` and `assert_file_not_contains`
|
||||
- `assert_symlink_to` and `assert_not_symlink_to`
|
||||
|
||||
**Working with a temporary directory:**
|
||||
|
||||
- `temp_make` and `temp_del`
|
||||
|
||||
Pre- and Post-test case hooks
|
||||
==============================
|
||||
|
||||
In some cases, it's useful to have a function that runs before or after each test
|
||||
case in a bats file.
|
||||
|
||||
A function named `setup` will run before each test case, and a function
|
||||
named `teardown` will run after each test case.
|
||||
|
||||
This example creates a directory in the setup function but lacks a teardown
|
||||
that removes the directory. The second time the setup function is run, the
|
||||
setup will fail as the directory already exists:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup() {
|
||||
mkdir tmp
|
||||
echo 'a' >> ./tmp/test
|
||||
}
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats test.bats
|
||||
test.bats
|
||||
✓ test contains a single a I
|
||||
✗ test contains a single a II
|
||||
(from function `setup' in test file test.bats, line 8)
|
||||
`mkdir tmp' failed
|
||||
mkdir: cannot create directory ‘tmp’: File exists
|
||||
|
||||
2 tests, 1 failure
|
||||
|
||||
This can be easily fixed by adding a teardown function:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup() {
|
||||
mkdir tmp
|
||||
echo 'a' >> ./tmp/test
|
||||
}
|
||||
|
||||
teardown() {
|
||||
rm -rf ./tmp
|
||||
}
|
||||
|
||||
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains ./tmp/test '^a$'
|
||||
}
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats test.bats
|
||||
test.bats
|
||||
✓ test contains a single a I
|
||||
✓ test contains a single a II
|
||||
|
||||
2 tests, 0 failures
|
||||
|
||||
Pre- and Post-test file hooks
|
||||
=============================
|
||||
|
||||
To run some code before executing a test file or after executing it, the
|
||||
functions `setup_file` and `teardown_file` can be used.
|
||||
|
||||
The last example could be refactored to only create the tmp directory once:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
bats_load_library bats-file
|
||||
|
||||
setup_file() {
|
||||
export DIR="./tmp"
|
||||
export FILE="${DIR}/test"
|
||||
mkdir "${DIR}"
|
||||
}
|
||||
|
||||
teardown_file() {
|
||||
rm -rf "${DIR}"
|
||||
}
|
||||
|
||||
setup() {
|
||||
echo 'a' >> "${FILE}"
|
||||
}
|
||||
|
||||
teardown() {
|
||||
rm "${FILE}"
|
||||
}
|
||||
|
||||
@test "test contains a single a I" {
|
||||
assert_file_contains "${FILE}" '^a$'
|
||||
}
|
||||
|
||||
@test "test contains a single a II" {
|
||||
assert_file_contains "${FILE}" '^a$'
|
||||
}
|
||||
|
||||
Multiple files
|
||||
==============
|
||||
|
||||
With `bats`, a file is a test suite. If you have multiple `bats` files in a
|
||||
directory and you provide the directory in the `bats` command line, `bats`
|
||||
will execute all the test suites.
|
||||
|
||||
Example: `bats .`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats .
|
||||
./first.bats
|
||||
✓ can run our script
|
||||
✗ second test
|
||||
(in test file ./first.bats, line 27)
|
||||
`false' failed
|
||||
./second.bats
|
||||
✓ multi file
|
||||
./test.bats
|
||||
✓ test contains a single a I
|
||||
✓ test contains a single a II
|
||||
|
||||
5 tests, 1 failure
|
||||
|
||||
Pre- and Post-suite hooks
|
||||
=========================
|
||||
|
||||
If you want to execute the same function before each test suite or after
|
||||
each test suite, create a file named `setup_suite.bash`. In this file,
|
||||
create a function named `setup_suite()` and another named `teardown_suite()`.
|
||||
|
||||
Exporting the test results
|
||||
==========================
|
||||
|
||||
Test results can be exported using the JUnit XML format. This can then be
|
||||
used in other tools and merged with other JUnit XML formats to generate a final
|
||||
test report.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sam@SAVE:~/Projects/tests$ bats . -F junit
|
||||
|
||||
This will produce the following XML content on stdout:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<testsuites time="0.048">
|
||||
<testsuite name="./first.bats" tests="2" failures="1" errors="0" skipped="0" time="0.025" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./first.bats" name="can run our script" time="0.013" />
|
||||
<testcase classname="./first.bats" name="second test" time="0.012">
|
||||
<failure type="failure">(in test file ./first.bats, line 27)
|
||||
`false' failed</failure>
|
||||
</testcase>
|
||||
|
||||
</testsuite>
|
||||
<testsuite name="./second.bats" tests="1" failures="0" errors="0" skipped="0" time="0.008" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./second.bats" name="multi file" time="0.008" />
|
||||
|
||||
</testsuite>
|
||||
<testsuite name="./test.bats" tests="2" failures="0" errors="0" skipped="0" time="0.015" timestamp="2023-08-16T14:22:15" hostname="SAVE">
|
||||
<testcase classname="./test.bats" name="test contains a single a I" time="0.008" />
|
||||
<testcase classname="./test.bats" name="test contains a single a II" time="0.007" />
|
||||
|
||||
</testsuite>
|
||||
</testsuites>
|
||||
|
||||
Going further
|
||||
=============
|
||||
|
||||
`bats` scripts can be checked with shellcheck for common mistakes.
|
||||
|
||||
The `bats-assert` add-on provides many helper functions to perform
|
||||
assertions with a more readable syntax than the shell's built-in syntax.
|
||||
|
||||
See https://github.com/bats-core/bats-assert
|
||||
|
||||
The `bats-file` add-on provides helper functions to check for files. See
|
||||
https://github.com/bats-core/bats-file/
|
||||
|
||||
You can find a list of projects using `bats` on this page:
|
||||
https://github.com/bats-core/bats-core/wiki/Projects-Using-Bats
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
==============================
|
||||
Belden CoreOS Testing Manual
|
||||
==============================
|
||||
|
||||
This manual is a work on progress on how to test and how to write test for
|
||||
CoreOS or CoreOS based distribution.
|
||||
|
||||
|
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:numbered:
|
||||
|
||||
bats
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit d7b7b6fb6c7c5545e718e44f38853d1718ce5446
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit e3581b11d30d91d0363acb48a6aee47043b7e0bc
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 09d2f9391813674627ec53cb222da6c7a51221e6
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 8bb16533532b6abc2eded7d9961ab2a108fd7a5b
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 3d12b2788a45d86efcb1ad3e01f209558c54795c
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit bae3658ac0bc1c9adac7a882439cabb385cae720
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit cb2bc17e96552cdfc141d27bd9f4dbd95a872846
|
||||
|
|
@ -1 +0,0 @@
|
|||
Subproject commit 1b5405955c7c2579ed1f52522e2e177d0281fa33
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
# UEFI Secure boot configuration
|
||||
# ==============================================================================
|
||||
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR ??= "${RECIPE_SYSROOT_NATIVE}/${datadir}/keys"
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR ??= "${TOPDIR}/keys"
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
|
||||
|
||||
# UEFI Secure boot helpers
|
||||
|
|
@ -16,19 +16,40 @@ HOSTTOOLS += "sbsign"
|
|||
|
||||
# Ensure that the public keys are always deployed to the deploy directory
|
||||
# before running wic
|
||||
do_image_wic[depends] += "cos-certificates-and-keys-native:do_deploy"
|
||||
do_image_wic[depends] += "efi-secureboot-keys:do_deploy"
|
||||
|
||||
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR ??= "0"
|
||||
def get_coreos_secureboot_efi_boot_files(d):
|
||||
"""
|
||||
Return the list of pubkey file inside deploy if
|
||||
Return the list of pubkey file inside deploy if
|
||||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR is set or an empty string
|
||||
otherwise
|
||||
"""
|
||||
if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR') == '1':
|
||||
if d.getVar('COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR', True):
|
||||
return "db.auth KEK.auth PK.auth db.esl KEK.esl PK.esl db.crt KEK.crt PK.crt db.der KEK.der PK.der"
|
||||
return ""
|
||||
|
||||
IMAGE_EFI_BOOT_FILES:append = " ${@get_coreos_secureboot_efi_boot_files(d)}"
|
||||
|
||||
def get_coreos_secureboot_keydir_hash(d):
|
||||
"""
|
||||
Generate a space separate list, with a value for each file inside of
|
||||
keydir. Fromat: <filename>:md5:<md5sum>
|
||||
"""
|
||||
import hashlib
|
||||
|
||||
keydir = d.getVar('COREOS_EFI_SECUREBOOT_KEYDIR')
|
||||
value = ""
|
||||
|
||||
for filepath in os.listdir(keydir):
|
||||
if os.path.isfile(filepath):
|
||||
md5 = bb.utils.md5_file(filepath)
|
||||
value += f"{filepath}:md5:{md5} "
|
||||
|
||||
return value
|
||||
|
||||
# The build system should detect if someone change one of the key inside
|
||||
# COREOS_EFI_SECUREBOOT_KEYDIR and rebuild all the recipes and artifacts that
|
||||
# depends on this directory
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR_HASH = "${@get_coreos_secureboot_keydir_hash(d)}"
|
||||
COREOS_EFI_SECUREBOOT_KEYDIR[vardeps] += "COREOS_EFI_SECUREBOOT_KEYDIR_HASH"
|
||||
|
|
|
|||
|
|
@ -1,26 +0,0 @@
|
|||
|
||||
SWUPDATE_IMAGES += "MLO"
|
||||
SWUPDATE_IMAGES += "u-boot-beaglebone"
|
||||
SWUPDATE_IMAGES_FSTYPES[MLO] = ""
|
||||
SWUPDATE_IMAGES_FSTYPES[u-boot-beaglebone] = ".img"
|
||||
|
||||
COREOS_SWUPDATE_EXTENDS_FOR:append = "beaglebone"
|
||||
|
||||
def coreos_swupdate_extends_images_for_beaglebone(d,s):
|
||||
mlo = {
|
||||
"filename" : "MLO",
|
||||
"installed-directly" : "true",
|
||||
"device" : "/dev/disk/by-partlabel/mlo",
|
||||
"type" : "raw",
|
||||
"sha256" : swupdate_get_sha256(d, s, "MLO"),
|
||||
}
|
||||
|
||||
uboot = {
|
||||
"filename" : "u-boot-beaglebone.img",
|
||||
"installed-directly" : "true",
|
||||
"device" : "/dev/disk/by-partlabel/uboot",
|
||||
"type" : "raw",
|
||||
"sha256" : swupdate_get_sha256(d, s, "u-boot-beaglebone.img"),
|
||||
}
|
||||
|
||||
return [mlo, uboot]
|
||||
|
|
@ -5,14 +5,12 @@
|
|||
MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
|
||||
EXTRA_IMAGEDEPENDS += "virtual/bootloader"
|
||||
|
||||
|
||||
DEFAULTTUNE ?= "cortexa8hf-neon"
|
||||
include conf/machine/include/arm/armv7a/tune-cortexa8.inc
|
||||
|
||||
IMAGE_FSTYPES += "wic wic.xz wic.bmap"
|
||||
WKS_FILE ?= "beaglebone-sdcard.wks.in"
|
||||
COREOS_INSTALLER_WKS_FILE ?= "beaglebone-sdcard-installer.wks"
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image"
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
|
||||
do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot gptfdisk-native:do_populate_sysroot virtual/bootloader:do_deploy"
|
||||
do_image_wic[recrdeptask] += "do_bootimg"
|
||||
|
||||
|
|
@ -21,10 +19,10 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
|
|||
APPEND:append = " console=ttyS0,115200"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_VERSION_linux-yocto ?= "5.15%"
|
||||
|
||||
KERNEL_IMAGETYPE = "zImage"
|
||||
DTB_FILES = "ti/omap/am335x-bone.dtb ti/omap/am335x-boneblack.dtb ti/omap/am335x-bonegreen.dtb"
|
||||
KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
|
||||
KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
|
||||
|
|
@ -37,6 +35,9 @@ UBOOT_LOADADDRESS = "0x80008000"
|
|||
|
||||
MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
|
||||
|
||||
IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY}"
|
||||
IMAGE_EFI_BOOT_FILES ?= "${KERNEL_DEVICETREE}"
|
||||
|
||||
# support runqemu
|
||||
EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
|
||||
IMAGE_CLASSES += "qemuboot"
|
||||
|
|
@ -57,7 +58,5 @@ QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port
|
|||
# No watchdog available yet
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
|
||||
COREOS_IMAGE_SWUPDATE_EXTRACLASSES += "coreos-image-swupdate-beaglebone"
|
||||
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
require conf/machine/include/coreos-generic-features/legacy-mbr-disk.inc
|
||||
|
|
|
|||
|
|
@ -1,39 +0,0 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: eagle40-03
|
||||
#@DESCRIPTION: Machine support for EAGLE40-03
|
||||
#
|
||||
|
||||
require include/coreos-generic-arch/x64.inc
|
||||
|
||||
MACHINE_FEATURES += "pci usbhost x86 serial efi"
|
||||
|
||||
# Kernel configuration
|
||||
# ******************************************************************************
|
||||
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
|
||||
KERNEL_IMAGETYPE = "bzImage"
|
||||
|
||||
# getty configuration
|
||||
# ******************************************************************************
|
||||
|
||||
SERIAL_CONSOLES = "115200;ttyS0"
|
||||
SERIAL_CONSOLES_CHECK = "ttyS0"
|
||||
APPEND += "console=ttyS0,115200"
|
||||
|
||||
# Image generation
|
||||
# ******************************************************************************
|
||||
|
||||
# Ensure that both flash-image.bin and boot.scr are generated as they are needed
|
||||
# for a wic image
|
||||
WKS_FILE = "generic-uefi.wks.in"
|
||||
COREOS_INSTALLER_WKS_FILE ?= "generic-uefi-usb-installer.wks"
|
||||
IMAGE_FSTYPES += "wic.xz wic.bmap"
|
||||
|
||||
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += " kernel-modules"
|
||||
|
||||
# No watchdog available yet
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
@ -2,5 +2,15 @@
|
|||
# ==============================================================================
|
||||
|
||||
MACHINE_FEATURES:append = " efi"
|
||||
EFI_PROVIDER = "efibootguard"
|
||||
EFIBOOTGUARD_TIMEOUT ?= "60"
|
||||
|
||||
do_image_wic[depends] += "efibootguard-native:do_populate_sysroot efibootguard:do_deploy"
|
||||
|
||||
# Variable used in WKS file
|
||||
|
||||
WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --align 1024 --part-type=EF00'
|
||||
WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label platform0 --align 1024'
|
||||
WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label platform1 --align 1024'
|
||||
WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label boot0 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label boot1 --align 1024 --part-type=0700 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
|
||||
# MBR disk are still supported by CoreOS, but only for legacy product
|
||||
# This ensure that efibootguard / swupdate work with MBR disk
|
||||
|
||||
# Do not include this file in a machine configuration if the machine support
|
||||
# a GPT disk instead
|
||||
COREOS_DISK_PARTLABEL_LOOKUP_DIRECTORY ?= "/dev/disk/by-label"
|
||||
|
||||
COREOS_PLATFORM0_ROOT ?= "LABEL=platform0"
|
||||
COREOS_PLATFORM1_ROOT ?= "LABEL=platform1"
|
||||
|
||||
# MBR disk can't use --part-type but can use system-id
|
||||
WKS_PART_EFI ?= 'part --source efibootguard-efi --label efi --system-id 0xef'
|
||||
WKS_PART_EFIBOOTGUARD_A ?= 'part --source efibootguard-boot --label boot0 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=kernel0-${MACHINE}.efi;KERNEL0.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ?= 'part --source efibootguard-boot --label boot1 --sourceparams "watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=kernel1-${MACHINE}.efi;KERNEL1.EFI"'
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# Variables used in WKS file
|
||||
WKS_PART_EFI ??= 'part --source efibootguard-efi --label efi --part-type=EF00'
|
||||
WKS_PART_EFIBOOTGUARD_A ??= 'part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
|
||||
WKS_PART_EFIBOOTGUARD_B ??= 'part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI"'
|
||||
WKS_PART_ROOT_A ??= 'part / --source rootfs --fstype=ext4 --label rootfs0'
|
||||
WKS_PART_ROOT_B ??= 'part --fstype=ext4 --label rootfs1'
|
||||
WKS_PART_USERDATA ??= 'part /usr/local/data --fstype=btrfs --label userdata'
|
||||
|
||||
PART_EFI_SIZE ??= '64M'
|
||||
PART_ROOT_SIZE ??= '1G'
|
||||
PART_EFIBG_SIZE ??= '128M'
|
||||
PART_USERDATA_SIZE ??= '1G'
|
||||
|
||||
# Variables used in SFDISK file
|
||||
SFDISK_PART_EFI ??= 'type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, name="efi"'
|
||||
SFDISK_PART_EFIBOOTGUARD_A ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg0"'
|
||||
SFDISK_PART_EFIBOOTGUARD_B ??= 'type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="ebg1"'
|
||||
SFDISK_PART_ROOT_A ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs0"'
|
||||
SFDISK_PART_ROOT_B ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="rootfs1"'
|
||||
SFDISK_PART_USERDATA ??= 'type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="userdata"'
|
||||
|
|
@ -2,10 +2,8 @@
|
|||
IMAGE_FSTYPES += "container oci"
|
||||
IMGCLASSES:append = " image-oci"
|
||||
|
||||
# Add an override that work for all container image
|
||||
MACHINEOVERRIDES =. "container:"
|
||||
|
||||
# Containers don't need a kernel
|
||||
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
|
||||
|
||||
# When using coreos-image instead of coreos-container-image, we should skip
|
||||
# swu image generation and unified kernel image generation
|
||||
COREOS_IMAGE_GENERATE_UKI = "0"
|
||||
COREOS_IMAGE_GENERATE_SWU = "0"
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ MACHINE_FEATURES += "wifi efi"
|
|||
# Add an override that work for all pc image
|
||||
MACHINEOVERRIDES =. "vm:"
|
||||
|
||||
PREFERRED_VERSION_linux-yocto ?= "6.6%"
|
||||
PREFERRED_VERSION_linux-yocto ?= "5.15%"
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
|
||||
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
|
||||
|
||||
IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk wic.vhdx"
|
||||
IMAGE_FSTYPES += "ext4 wic wic.xz wic.bmap wic.vmdk"
|
||||
|
||||
WKS_FILE ?= "generic-uefi.wks.in"
|
||||
do_image_wic[depends] += "gptfdisk-native:do_populate_sysroot"
|
||||
|
|
@ -22,4 +22,3 @@ do_image_wic[recrdeptask] += "do_bootimg"
|
|||
COREOS_EFI_SECUREBOOT_INSTALL_PUBKEY_IN_EFIDIR = "1"
|
||||
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
#@TYPE: Machine
|
||||
#@NAME: qemu-generic-arm64
|
||||
#@DESCRIPTION: Generic Arm64 machine for typical SystemReady platforms, which
|
||||
#have working firmware and boot via EFI.
|
||||
|
||||
require conf/machine/qemu-generic-arm64.conf
|
||||
MACHINEOVERRIDES =. "qemu-generic-arm64:"
|
||||
|
||||
COREOS_IMAGE_GENERATE_INSTALLER = "0"
|
||||
|
||||
WKS_FILE = "qemu-efi-coreos-generic.wks.in"
|
||||
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
require conf/machine/include/coreos-generic-features/efi.inc
|
||||
require conf/machine/include/coreos-generic-features/partitions.inc
|
||||
|
|
@ -7,6 +7,3 @@ require include/coreos-generic-machine/vm.inc
|
|||
|
||||
SERIAL_CONSOLES_CHECK = "ttyS0"
|
||||
QB_SYSTEM_NAME = "qemu-system-x86_64"
|
||||
|
||||
# Currently we don't support the watchdog
|
||||
EFIBOOTGUARD_TIMEOUT ?= "0"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
SUMMARY = "A recipe to deploy UEFI public keys update files"
|
||||
LICENSE = "CLOSED"
|
||||
|
||||
|
||||
INHIBIT_DEFAULT_DEPS = "1"
|
||||
inherit nopackages
|
||||
|
||||
inherit deploy
|
||||
inherit coreos-efi-secureboot
|
||||
|
||||
# Public key needed by firmware very depending on the implementation
|
||||
# So we copy all type of public key (*.auth, *.esl, *.crt, *der)
|
||||
addtask deploy after do_compile
|
||||
do_deploy() {
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.auth ${DEPLOYDIR}/KEK.auth
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.auth ${DEPLOYDIR}/db.auth
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.auth ${DEPLOYDIR}/PK.auth
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.esl ${DEPLOYDIR}/KEK.esl
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.esl ${DEPLOYDIR}/db.esl
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.esl ${DEPLOYDIR}/PK.esl
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.crt ${DEPLOYDIR}/KEK.crt
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.crt ${DEPLOYDIR}/db.crt
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.crt ${DEPLOYDIR}/PK.crt
|
||||
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/KEK.der ${DEPLOYDIR}/KEK.der
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/db.der ${DEPLOYDIR}/db.der
|
||||
install -D -m 644 ${COREOS_EFI_SECUREBOOT_KEYDIR}/PK.der ${DEPLOYDIR}/PK.der
|
||||
|
||||
# !SECURITY WARNING!
|
||||
# .key file are not copied to DEPLOYDIR, as they contains the PRIVATE keys
|
||||
}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
# Add signature support
|
||||
|
||||
inherit coreos-efi-sbsign
|
||||
require conf/image-uefi.conf
|
||||
|
||||
do_deploy:append() {
|
||||
|
||||
if [ -f "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi" ]; then
|
||||
coreos_efi_secureboot_sign_app "${DEPLOYDIR}/efibootguard${EFI_ARCH}.efi"
|
||||
fi
|
||||
}
|
||||
|
|
@ -1,23 +1,12 @@
|
|||
# Ensure that file are found event when this file is included in another layer
|
||||
# ==============================================================================
|
||||
FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
|
||||
|
||||
# U-Boot CoreOS Distro Settings
|
||||
# ==============================================================================
|
||||
|
||||
# Enable more debug option when debug-tweaks is enabled
|
||||
SRC_URI += " \
|
||||
${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
|
||||
"
|
||||
|
||||
inherit coreos-efi-secureboot
|
||||
|
||||
# Make sure UEFI and secure boot is enabled for every u-boot build
|
||||
SRC_URI += " \
|
||||
file://uefi.cfg \
|
||||
file://uefi-secureboot.cfg \
|
||||
"
|
||||
|
||||
DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native"
|
||||
|
||||
# Generate a ubootefi.var file inside the build directory
|
||||
#
|
||||
# This file can be directly linked inside the u-boot binary to provide
|
||||
|
|
@ -26,7 +15,6 @@ SRC_URI += " \
|
|||
#
|
||||
# The efivar.py is taken from u-boot-tools recipes, so that we are sure that he
|
||||
# is found and don't depend on the u-boot version being used
|
||||
DEPENDS:append = " ${PYTHON_PN}-pyopenssl-native u-boot-tools-native cos-certificates-and-keys-native"
|
||||
addtask uboot_generate_efivar after do_configure before do_compile
|
||||
do_uboot_generate_efivar() {
|
||||
# Settings OPENSSL_MODULES is needed, otherwise efivar.py fail with
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Ensure that file are found event when this file is included in another layer
|
||||
# ==============================================================================
|
||||
FILESEXTRAPATHS:prepend := "${THISDIR}/u-boot:"
|
||||
|
||||
# Main include file for u-boot to ensure CoreOS compatibility
|
||||
# ==============================================================================
|
||||
|
||||
SRC_URI += " \
|
||||
${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "file://debug-tweaks.cfg", "", d)} \
|
||||
"
|
||||
|
||||
require u-boot-coreos-efi.inc
|
||||
|
|
@ -4,6 +4,4 @@
|
|||
|
||||
do_install:append() {
|
||||
install -m 0755 ${S}/tools/efivar.py ${D}${bindir}/uboot-efivar
|
||||
}
|
||||
|
||||
FILES:${PN} += "${bindir}/uboot-efivar"
|
||||
}
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
|
||||
require u-boot-coreos.inc
|
||||
|
|
@ -4,3 +4,5 @@ require recipes-bsp/u-boot/u-boot.inc
|
|||
SRCREV = "4debc57a3da6c3f4d3f89a637e99206f4cea0a96"
|
||||
DEPENDS += "bc-native dtc-native python3-setuptools-native"
|
||||
LIC_FILES_CHKSUM = "file://Licenses/README;md5=2ca5f2c35c8cc335f0a19756634782f1"
|
||||
|
||||
require u-boot-coreos.inc
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
label: gpt
|
||||
device: /dev/mmcblk1
|
||||
unit: sectors
|
||||
first-lba: 34
|
||||
last-lba: 7471070
|
||||
sector-size: 512
|
||||
|
||||
# EBBR 2.1.0 section 4.1.1 mandate the use of an unused type UUID and to set
|
||||
# the RequiredPartition label for part of the firmware stored in the main disk
|
||||
# https://arm-software.github.io/ebbr/#section-gpt-parts
|
||||
# next two type were generated
|
||||
/dev/mmcblk1p1 : start= 256, size= 512, type=4DA6E9DA-C803-4BE4-BAC4-8192717C5EB0, name="mlo", attrs="RequiredPartition"
|
||||
/dev/mmcblk1p2 : start= 768, size= 8192, type=5B97345D-B7A1-47D3-A491-ED40F4841639, name="uboot", attrs="RequiredPartition"
|
||||
|
||||
/dev/mmcblk1p3 : size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
|
||||
/dev/mmcblk1p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
|
||||
/dev/mmcblk1p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
|
||||
/dev/mmcblk1p6 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
|
||||
/dev/mmcblk1p7 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
label: gpt
|
||||
device: /dev/mmcblk2
|
||||
unit: sectors
|
||||
first-lba: 34
|
||||
last-lba: 7471070
|
||||
sector-size: 512
|
||||
|
||||
/dev/mmcblk2p1 : start= 256, size= ${PART_EFI_SIZE}, ${SFDISK_PART_EFI}
|
||||
/dev/mmcblk2p2 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_A}
|
||||
/dev/mmcblk2p3 : size= ${PART_ROOT_SIZE}, ${SFDISK_PART_ROOT_B}
|
||||
/dev/mmcblk2p4 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_A}
|
||||
/dev/mmcblk2p5 : size= ${PART_EFIBG_SIZE}, ${SFDISK_PART_EFIBOOTGUARD_B}
|
||||
/dev/mmcblk2p6 : size= ${PART_USERDATA_SIZE}, ${SFDISK_PART_USERDATA}
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/coreos-installer-config:"
|
||||
|
||||
SRC_URI:append:beaglebone = " file://beaglebone_1.0.sfdisk"
|
||||
SRC_URI:append:eagle40-03 = " file://eagle40-03_1.0.sfdisk"
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
CONFIG_F71808E_WDT=y
|
||||
CONFIG_WATCHDOG_SYSFS=y
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
CONFIG_HYPERVISOR_GUEST=y
|
||||
CONFIG_PARAVIRT=y
|
||||
CONFIG_PARAVIRT_SPINLOCKS=y
|
||||
CONFIG_CONNECTOR=y
|
||||
CONFIG_SCSI_FC_ATTRS=y
|
||||
CONFIG_HYPERV=y
|
||||
CONFIG_HYPERV_UTILS=y
|
||||
CONFIG_HYPERV_BALLOON=y
|
||||
CONFIG_HYPERV_STORAGE=y
|
||||
CONFIG_HYPERV_NET=y
|
||||
CONFIG_HYPERV_KEYBOARD=y
|
||||
CONFIG_FB_HYPERV=y
|
||||
CONFIG_HID_HYPERV_MOUSE=y
|
||||
CONFIG_PCI_HYPERV=y
|
||||
CONFIG_VSOCKETS=y
|
||||
CONFIG_HYPERV_VSOCKETS=y
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
|
||||
inherit coreos-efi-sbsign
|
||||
require conf/image-uefi.conf
|
||||
|
||||
# Ensure EFI STUB is enabled
|
||||
KERNEL_FEATURES:append = " cfg/efi.scc cfg/efi-ext.scc"
|
||||
|
||||
# By default we use a Unified Kernel Image that contain the kernel, the
|
||||
# kernel command line and some device tree, so we don't need to sign the output
|
||||
# of the kernel recipes
|
||||
COREOS_KERNEL_EFI_SIGNED ??= "0"
|
||||
|
||||
# Extend the kernel_do_deploy function from kernel.bbclass to sign the kernel
|
||||
kernel_do_deploy:append() {
|
||||
if [ "${COREOS_KERNEL_EFI_SIGNED}" == "1" ]; then
|
||||
deployDir="${DEPLOYDIR}"
|
||||
for imageType in ${KERNEL_IMAGETYPES} ; do
|
||||
baseName="$imageType-${KERNEL_IMAGE_NAME}"
|
||||
coreos_efi_secureboot_sign_app "$deployDir/$baseName${KERNEL_IMAGE_BIN_EXT}"
|
||||
done
|
||||
fi
|
||||
}
|
||||
|
||||
|
|
@ -1,20 +1,13 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
|
||||
KMACHINE:vm-x64 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
|
||||
|
||||
# Enable some kernel features related to virtualiuzation
|
||||
KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
|
||||
SRC_URI:append:vm-x64 = " file://hyperv.cfg"
|
||||
|
||||
KMACHINE:eagle40-03 ?= "common-pc-64"
|
||||
KBRANCH:eagle40-03 = "v5.15/standard/base"
|
||||
SRCREV_machine:eagle40-03 ?= "3baf1c5c0e6084b3f4a1d2d805168d657f872e60"
|
||||
COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
|
||||
LINUX_VERSION:eagle40-03 = "5.15.134"
|
||||
|
||||
|
||||
KBRANCH:beaglebone = "v5.15/standard/beaglebone"
|
||||
KMACHINE:beaglebone ?= "beaglebone"
|
||||
SRCREV_machine:beaglebone ?= "9aabbaa89fcb21af7028e814c1f5b61171314d5a"
|
||||
COMPATIBLE_MACHINE:beaglebone = "beaglebone"
|
||||
LINUX_VERSION:beaglebone = "5.15.54"
|
||||
|
||||
require linux-yocto-coreos-efi.inc
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
|
||||
|
||||
KMACHINE:eagle40-03 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:eagle40-03 = "eagle40-03"
|
||||
|
||||
KMACHINE:beaglebone ?= "beaglebone"
|
||||
COMPATIBLE_MACHINE:beaglebone = "beaglebone"
|
||||
|
||||
KMACHINE:vm-x64 ?= "common-pc-64"
|
||||
COMPATIBLE_MACHINE:vm-x64 = "vm-x64"
|
||||
KERNEL_FEATURES:append:vm-x64=" cfg/virtio.scc cfg/paravirt_kvm.scc"
|
||||
SRC_URI:append:vm-x64 = " file://hyperv.cfg"
|
||||
|
||||
SRC_URI += " file://eagle40-03.cfg"
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# short-description: Create SD card image for Beaglebone
|
||||
# long-description: Creates a partitioned SD card image for Beaglebone.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
|
||||
part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K
|
||||
part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M
|
||||
|
||||
# Let's define a 4MiB maximum size for the bootloader
|
||||
# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
|
||||
part --source bootimg-partition --part-type=EF00 --ondisk mmcblk0 --offset 8960S --fixed-size 125M
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,20 +1,11 @@
|
|||
# short-description: Create SD card image for Beaglebone
|
||||
# long-description: Creates a partitioned SD card image for Beaglebone.
|
||||
# Boot files are located in the first vfat partition.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
part --offset 256S --source rawcopy --sourceparams="file=MLO" --ondisk mmcblk0 --fixed-size 256K --part-name "mlo"
|
||||
part --offset 768S --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk0 --fixed-size 4M --part-name "uboot"
|
||||
|
||||
|
||||
# Let's define a 4MiB maximum size for the bootloader
|
||||
# 4MiB => 4*1024*1024/512=8192S | 768S + 8192S => 8960S
|
||||
${WKS_PART_EFI} --ondisk mmcblk0 --offset 8960S --fixed-size 32M
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --fixed-size ${PART_EFIBG_SIZE}
|
||||
${WKS_PART_ROOT_A} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
|
||||
${WKS_PART_ROOT_B} --ondisk mmcblk0 --fixed-size ${PART_ROOT_SIZE}
|
||||
bootloader --ptable gpt
|
||||
part --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --fixed-size 32
|
||||
${WKS_PART_EFI} --ondisk mmcblk0 --align 1024 --fixed-size 32
|
||||
${WKS_PART_ROOT_A} --ondisk mmcblk0 --fixed-size 2G
|
||||
${WKS_PART_ROOT_B} --ondisk mmcblk0 --fixed-size 2G
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk mmcblk0 --align 1024 --fixed-size 32
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk mmcblk0 --align 1024 --fixed-size 32
|
||||
bootloader --ptable msdos
|
||||
|
|
|
|||
|
|
@ -1,16 +0,0 @@
|
|||
# short-description: Create USB image for Eagle 40-03
|
||||
# long-description: Creates a partitioned USB image for Eagle 40-03.
|
||||
|
||||
# offset 1S => 1 sector (1x512 byte)
|
||||
# The bootloader can be at 4 different position in raw mode: 0S, 256S, 512S, 768S
|
||||
# MBR disk use only the sector 0, so 1S is free
|
||||
# GPT disk use sector 0-33S, so first free slot is 256S
|
||||
# Offset are from the BBB default settings
|
||||
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# Don't name partition in the installer disk image, otherwise the installer may not work as it rely on partition label!
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
|
||||
part --offset 256S --source bootimg-partition --part-type=EF00 --ondisk mmcblk0
|
||||
part --fixed-size 3G --fstype=vfat --label=image
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,11 +1,10 @@
|
|||
# short-description: Create an EFI disk image for genericx86*
|
||||
# long-description: Creates a partitioned EFI disk image for genericx86* machines
|
||||
${WKS_PART_EFI} --ondisk sda --align 1024 --fixed-size 32
|
||||
${WKS_PART_ROOT_A} --ondisk sda --fixed-size 2G
|
||||
${WKS_PART_ROOT_B} --ondisk sda --fixed-size 2G
|
||||
${WKS_PART_EFIBOOTGUARD_A} --ondisk sda --align 1024 --fixed-size 32
|
||||
${WKS_PART_EFIBOOTGUARD_B} --ondisk sda --align 1024 --fixed-size 32
|
||||
|
||||
${WKS_PART_EFI} --align 1024 --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_A} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_ROOT_B} --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_A} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_EFIBOOTGUARD_B} --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_USERDATA} --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
|
||||
|
||||
part swap --ondisk sda --size 44 --label swap1 --fstype=swap
|
||||
bootloader --ptable gpt
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
# short-description: Create an EFI disk image
|
||||
# long-description: Creates a partitioned EFI disk image that the user
|
||||
# can directly dd to boot media.
|
||||
|
||||
part --source efibootguard-efi --label efi --part-type=EF00 --use-uuid --offset 20480S --size ${PART_EFI_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part / --source rootfs --fstype=ext4 --label rootfs0 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --fstype=ext4 --label rootfs1 --use-uuid --size ${PART_ROOT_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --source efibootguard-boot --label ebg0 --part-type=0700 --sourceparams "args=coreos.root=rootfs0,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=2,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
part --source efibootguard-boot --label ebg1 --part-type=0700 --sourceparams "args=coreos.root=rootfs1,watchdog=${EFIBOOTGUARD_TIMEOUT},revision=1,kernel=${COREOS_KERNEL_FILENAME};KERNEL.EFI" --use-uuid --align 1024 --size ${PART_EFIBG_SIZE} --extra-space 0 --overhead-factor 1
|
||||
${WKS_PART_USERDATA} --use-uuid --size ${PART_USERDATA_SIZE} --extra-space 0 --overhead-factor 1
|
||||
|
||||
bootloader --ptable gpt
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
DESCRIPTION = "An image that includes k3s-agent"
|
||||
|
||||
require recipes-core/images/coreos-image-all-features.bb
|
||||
|
||||
IMAGE_INSTALL += "k3s-agent"
|
||||
|
||||
# To use this image, please add k3s to DISTRO_FEATURE inside your
|
||||
# local.conf config file.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
DESCRIPTION = "An image that come with most of the feature available in CoreOS"
|
||||
|
||||
inherit coreos-image
|
||||
require recipes-core/images/coreos-image-all-features.bb
|
||||
|
||||
# demos
|
||||
IMAGE_INSTALL:append = " systemd-services-demo cmake-demo"
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Example how to make a recipe that uses CMake for building
|
||||
# Please note that this is a recipe to build the package. For package to be added to an Image, another recipe needs to be changed.
|
||||
# Example: This package is added to be part of coreos-image-full-cmdline image.
|
||||
# A new line: IMAGE_INSTALL += "cmake-demo" is added to layers/meta-belden-coreos/recipes-core/images/coreos-image-full-cmdline.bb
|
||||
|
||||
DESCRIPTION = "Simple helloworld cmake application"
|
||||
|
||||
# Recipe must include a licence
|
||||
LICENSE = "CLOSED"
|
||||
|
||||
# Revision of this recipe (optional)
|
||||
PR = "r1"
|
||||
|
||||
# Systemd file
|
||||
SYSTEMD_SERVICE_${PN} = "hello.service"
|
||||
|
||||
# Recipe needs to know where the needed files are
|
||||
SRC_URI += "file://CMakeLists.txt\
|
||||
file://lib/CMakeLists.txt \
|
||||
file://src/CMakeLists.txt \
|
||||
file://src/helloworld.c \
|
||||
file://src/hello.service \
|
||||
file://lib/lib-demo.c \
|
||||
file://lib/lib-demo.h"
|
||||
|
||||
# List of files and directories that are placed in a package
|
||||
FILES:${PN} += "${systemd_unitdir}/system/hello.service"
|
||||
|
||||
# Temporary work directory for each recipe where extracted source files are kept
|
||||
S="${WORKDIR}"
|
||||
|
||||
# CMake will do most of the work, so it needs to be inherited
|
||||
inherit cmake systemd
|
||||
|
||||
# Passing any needed configure options to CMake
|
||||
EXTRA_OECMAKE = ""
|
||||
|
||||
# Systemd service is being installed using this function (this is an example). Other files are installed using CMake
|
||||
do_install:append() {
|
||||
install -d ${D}/${systemd_unitdir}/system
|
||||
install -m 0644 ${WORKDIR}/src/hello.service ${D}/${systemd_unitdir}/system
|
||||
}
|
||||
|
||||
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# Top CMakeLists.txt file
|
||||
|
||||
# Firstly a minimum required version of CMake is specified
|
||||
cmake_minimum_required(VERSION 3.22)
|
||||
|
||||
# Name the project, and give a version
|
||||
project(cmake_demo VERSION 0.0.1)
|
||||
|
||||
# Setting build logs to verbose (usefull for debugging)
|
||||
set(CMAKE_VERBOSE_MAKEFILE ON)
|
||||
|
||||
# Adding subdirectories that contain CMakeLists.txt
|
||||
add_subdirectory(lib)
|
||||
add_subdirectory(src)
|
||||
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# CMakeLists.txt file is gets some info from top CMakeLists.txt file (Minimum required version, Project name), so its not needed to redefine it here
|
||||
|
||||
|
||||
# Declare the library target.
|
||||
add_library(${PROJECT_NAME} SHARED lib-demo.c)
|
||||
|
||||
# Set the version property.
|
||||
set_target_properties(${PROJECT_NAME} PROPERTIES VERSION ${PROJECT_VERSION})
|
||||
|
||||
# Set the shared object version property to the project's major version.
|
||||
set_target_properties(${PROJECT_NAME} PROPERTIES SOVERSION ${PROJECT_VERSION_MAJOR})
|
||||
|
||||
# Set the public header property to the one with the actual API.
|
||||
set_target_properties(${PROJECT_NAME} PROPERTIES PUBLIC_HEADER lib-demo.h)
|
||||
|
||||
# Install library and dependency file
|
||||
install (TARGETS ${PROJECT_NAME} LIBRARY DESTINATION lib PUBLIC_HEADER DESTINATION include)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue