| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
X32 builds require that the bootloader is built as x86_64 binary.
This patch splits the build definitions of the RMC userspace application
and the RMC EFI library into separate recipes and builds an x86_64 EFI library
when DEFAULTTUNE is x32.
Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the RMC library was always linked into systemd-boot. Non
rmc-boot EFI_PROVIDERs will not build the rmc.db and userspace tool and
therefore linking the library into these bootloaders is redundant.
This change disables RMC completely when the EFI_PROVIDER is not rmc-boot.
The default EFI_PROVIDER in meta-intel is rmc-boot. To use systemd-boot
without RMC, set EFI_PROVIDER to systemd-boot in your conf/local.conf.
Example:
EFI_PROVIDER = "systemd-boot"
Signed-off-by: Todor Minchev <todor.minchev@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With some UEFI shells LoadOptionsSize is reported being > 0
but the corresponding LoadOptions does not contain any data
(the first element has value 0).
When that happens, the stub feature that allows .cmdline to be
replaced by what's in LoadOptions ends up copying nothing/random
data to the kernel cmdline resulting in different kinds of boot
problems.
To fix this, add a check to see if LoadOptions contains data
before replacing the .cmdline.
Upstream-Status: Accepted [https://github.com/systemd/systemd/pull/5467]
Fixes [YOCTO #11078].
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
systemd-boot's EFI stub can be built in an EFI executable
with the kernel, cmdline, and initrd.
This commit enables the EFI stub code to use the RMC database
and appends the board specific cmdline (KBOOTPARAM) to the
built-in cmdline.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a whole package of rmc work in meta-intel to reflect
some major changes in the upstream project:
In rmc.bb recipe, EFI_ARCH, path of EFI header files, and
dependency on gnu-efi are removed with the updated revision.
In systemd-boot, patches to integrate with rmc are re-worked
mainly because of new APIs. Size of patches are smaller than
the previous implementation. Notice we still use multiple APIs
instead of calling an one-step interface multiple times, to get
some potential runtime performance benefit. (rmc tool in user
space is changed to use single API in the upstream project.)
Fixes [YOCTO #10086]
Fixes [YOCTO #10671]
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
| |
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
|
Invoke RMC APIs in this bootloader to query board-specific data
from RMC database(DB) file on ESP. Data can be boot entries or a
global kernel boot command line fragment specific to a type of
board supported in RMC DB.
Bootloader queries a file blob named BOOTENTRY.CONFIG from RMC
DB first. In success, bootloader parses BOOTENTRY.CONFIG to get
name of each boot entry file associated to the type of running
board, and then tries to load the entry into internal config data
structure. Once any entry is loaded from RMC DB, bootloader skips
loading conf files on ESP.
BOOTENTRY.CONFIG has a very simple format - every line is a boot
entry file's name. For example, to specify two boot entries in it:
boot.conf
install.conf
Bootloader also seeks another file named KBOOTPARAM in RMC dB.
when it can obtain this file associated to the type of running
board, it appends what in file to the end of kernel command
line before it boots up kernel. The appending is effective on
every boot entry, so it is called "global" cmdline fragment.
When Bootloader doesn't get config, an entry or cmdline fragment
for the type of board, it simply moves to the next step.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Reviewed-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
|
