This function obtains lots of error codes and then throws them away.
Update it to return the error, moving the image pointer to an
argument.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function only uses one argument and just needs to know the name of
the command which called it. Adjust the function to use only what it
needs. This will make it easier to call from a non-command context.
Tidy up the function comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function does not modify its first argument, so mark it const. Also
move the comments to the header file and expand them to provide more
useful information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move this code and image_get_kernel() higher in the file to avoid the
need for a forward declaration.
No attempt is made to remove #ifdefs or adjust the code in any other
way.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move the argument decoding to the caller, to avoid needing to pass the
command-line arguments.
Add a function comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function does not use its arguments. Drop them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
While booting with efi, if fdt isn't available externally,
just use the built-in one.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.
For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.
Setting it as hex string fixes the problem.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>
EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.
A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.
Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.
Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.
Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>
During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.
Background:
During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.
I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order for a predefined "preboot" or "bootcmd" to be executed by the
running system we must have a command line. Add CMDLINE as a
dependency.
Signed-off-by: Tom Rini <trini@konsulko.com>
As this particular bootmeth requires the command line and assorted
commands to function, make sure we have CMDLINE enabled.
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to use bootmeth_cros, at least on non-X86, we need to be able
to start any type of kernel that the "bootm" code paths can handle. Add
these objects to the required list for this option.
Signed-off-by: Tom Rini <trini@konsulko.com>
This particular option is required for booting all image types,
regardless of if we are starting an OS via command line or something
else. Move the question for SYS_BOOTM_LEN to be by the question for
LEGACY_IMAGE_FORMAT, as that's where our generic OS questions start.
Signed-off-by: Tom Rini <trini@konsulko.com>
We split BOOT_DEFAULTS to have BOOT_DEFAULTS_FEATURES and
BOOT_DEFAULTS_CMDS that in turn list general features or commands that
we want enabled when BOOT_DEFAULTS is selected. We only select
BOOT_DEFAULTS_CMDS if CMDLINE is set.
Signed-off-by: Tom Rini <trini@konsulko.com>
The implementation of DISTRO_DEFAULTS is done in environment scripts and
requires the command line in order to work. Because of this, select
CMDLINE here.
Signed-off-by: Tom Rini <trini@konsulko.com>
Make AUTOBOOT depend on CMDLINE since it is mostly meaningless without it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Today, the bootmeth for using the EFI loader via bootefi depends on
calling the bootefi command directly, so make this in turn depend on
CMD_BOOTEFI.
Signed-off-by: Tom Rini <trini@konsulko.com>
This has a typo which makes the method inoperable. Correct it so that
'bootflow read' works correctly for ChromeOS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Two bugs have appeared:
- arguments can have an equals sign embedded in them, which must be
considered part of the value
- arguments must fully match the name; partial matches should be
ignored
Fix these and add a test to cover both.
Signed-off-by: Simon Glass <sjg@chromium.org>
Enable the bootflow based on this bootmeth if the BootOrder EFI
variable is set.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmU7j50ACgkQgS8AYozs
+qIh8w/+O4UjT0sG1NLwmyV7U1Ypk+EyYaE6wmSWzpsJLfH/YvtObBJOYRuXxRVh
J9lkgCsw8Ct1ZNCrp8iVO+Dz1DtV8+QvTecrUHZqcOhTYDaqxXnlvEH2/EUhgo5T
9a/ZaDtOP1mKz754C4G6G363+iRCvbcqDECeKg9VYxfWCo1cINOmqyQCqlGxFT+h
PKiB5VzUpN/K/yiie+Hr42/+6XaykAUjUvEWeyKOsRmYY4lNiK22vG/puE42bFTh
catXwTE2a7x+yzPKkdhR0UGvDUlIKET2kF6mi+pYN2h/cSUxWTzbP/OxcU9yJOnm
qJiRZ+Woez1I7ul6ln4ci2kiWc3CTYFXfctwrBJPuJ/EO+2EEb3oHqG2S3Fc9VBZ
N17flHW7XZHEQbNexlUhk9cRpCwRuSA5OJXwW+IZIuydgNeo3xF0iYvipbjkEGgW
BBkt8PH+ivTLjEz6Gcmquvo1fHGJLHRIPg7DNb0phGHviuC0zlDJ7N5DZk0CpkiT
36siV9xK4X6qvWkOTa6Ldw60e4tN9nv3VG30uXtPHi3XdOkKfNkyIuqO/5BkkQPt
6yEc9IYXYoWNKDVUGme5+xszZp1sSvqltajG9VVNupt958dFyOSgS5aNa6B4UsWX
3XfndP1/s2bezUHoQx5zjraapKVrqBFLkGeTlCDUD+mEgP440G8=
=gvDs
-----END PGP SIGNATURE-----
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Ilias: Added some info on Kconfig explaining this is when booting !EFI
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Date Huang <tjjh89017@hotmail.com>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Reported-by: Ivan Ivanov <ivan.ivanov@suse.com>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
The current logic for "bootflow mmc" is flawed since it checks the
uclass of the bootdev instead of its parent, the media device. Correct
this and add a test that covers this scenario.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
This commit was intended to allow all bootdevs in each boot_targets
entry to be scanned. However it causes bad ordering with bootdevs, e.g.
scanning Ethernet bootdevs when it should be keeping to mmc.
Revert it so we can try another approach.
This reverts commit e824d0d0c219bc6da767f13f90c5b00eefe929f0.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Ivan T.Ivanov <iivanov@suse.de>
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
I believe at least three people reported this, but I found two.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Date Huang <tjjh89017@hotmail.com>
Reported-by: Vincent Stehlé <vincent.stehle@arm.com>
Add textline to the list of objects which tthe expo builder can build.
This allows them to be provided in the description.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present cedit only supports menu keys. For textline objects we need
to insert normal ASCII characters.
We also need to handle backspace, which is ASCII 9.
In fact, expo does not make use of all the menu keys, so partition
them accordingly and update the logic to support normal ASCII
characters, too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide an implementation for textlines in the scene code, so that they
are displayed correctly. Provide a way to have a border around the
textline, with the internal part being the same colour as the
background. This looks more natural.
Signed-off-by: Simon Glass <sjg@chromium.org>
This object needs special handling when it is opened, to set up the CLI
and the vidconsole context. Add special support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
A textline is a line of text which can be edited by the user. It has a
maximum length (in chracters) but otherwise there are no restrictions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the CLI state, a buffer to hold the old value of the text being
edited and a place to save vidconsole entry context. These will be use
by the textline object.
Set an upper limit on the maximum number of characters in a textline
object supported by expo, at least for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus have a background. When other object types are
rendered, they may have a background too. Make this code more generic
so it will be usable by new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the devicetree is too small for the property being written, we need
to expand the devicetree and retry the write.
Put this logic into a function so it can be reused.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus can be highlighted. With the coming addition of
text lines we need to be able to highlight other objects. Add a function
to determine whether an object can be highlighted.
Signed-off-by: Simon Glass <sjg@chromium.org>
In a lot of cases menus are the only objects which are have their own
behaviour in the cedit, e.g. to move between menus. With expo expanding
to support text, this is no-longer true.
Use a switch() statement so that we can simply insert a new 'case' for
the new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When building an expo fails, show some information about which node
caused the problem. Use -ENOENT consistently when the ID is missing.
This makes it easier for the user to debug things.
Signed-off-by: Simon Glass <sjg@chromium.org>
