This function only uses two arguments. The 'arch' always has a constant
value, so drop it. This simplifies the function call.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function only uses one argument from bootm (argv[2]) so pass it in
directly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rather than having boot_get_fdt() calculate this, move the calculation
into the caller. This removes the access to argv[0] in this function,
so we can later refactor it to just accept argv[2] instead of the whole
argv[].
Move the function comment to the header file and fix the u8 argument,
while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The OF_LIBFDT #ifdef makes it harder to use a local variable for that
code block. Convert it to if() instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function normally only uses one argument so pass it in directly.
Move comments to the header file so could one day include these
functions in API docs. Fix up the u8 argument while here, since it
avoids the compiler having to mask the value on some machines.
The Android case here is bit strange, since it can use argv[0], so deal
with that in the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The same error message is printed in two places. Move it out to the
caller so we can avoid passing in the command name. Leave the bootstage
handling where it is.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This is a misnomer since we don't necessarily know that the image is a
FIT. Use the existing BOOTSTAGE_ID_CHECK_IMAGETYPE instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Rather than looking for a zero-sized image, use the error code returned
to determine if things are OK.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
These unmaps should happen regardless of the return value. Move them
before the 'return' statement.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
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>
