| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 change updates the locked systemd-boot revision to v232
release which is the current in OE.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OE-Core recently renamed the recipe to have PV in the name
and the bbappend wildcard was added to make the transition
smooth.
The renaming is now complete so rename the bbappend again
to match the new versioned recipe only.
The aggresive systemd-boot% wildcard matches systemd-bootchart
too giving unexpected results.
Depends on OE-Core 8fe1e5197f6f94a49693de09f4eb9394df531cc8.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
| |
|
|
|
|
|
|
|
| |
OE-Core is in process of renaming the recipe
to have PV in recipe name. Cover that case
for bbappend
Signed-off-by: Khem Raj <raj.khem@gmail.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>
|
| |
|
|
|
|
|
|
| |
Add the new intel-x86-common to the meta-data in order to limit the
changes when the meta-intel layer is included without using
meta-intel machines.
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>
|
