Add the path to the public key EFI Signature List(ESL) file for the
sandbox variants which enable capsule authentication. This ESL file
gets embedded into the platform's device-tree as part of the build.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a target for generating a dtsi file which contains the signature
node with the ESL file included as a property under the signature
node. Include the dtsi file in the dtb. This brings the embedding of
the ESL in the dtb into the U-Boot build flow.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
At the time of building the DTB, some dtsi files can be selected for
inclusion. Have these dtsi files as dependencies for the DTB
target. This also ensures generation or updating the dtsi files if
need be.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
At the time of building a device-tree file, all the *u-boot.dtsi files
are looked for, in a particular order, and the first file found is
included. Then, the list of files specified in the
CONFIG_DEVICE_TREE_INCLUDES symbol are included.
Combine these files that are to be included into a variable, and then
include all these files in one go.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When running the trace test on the sandbox platform, the current size
of 16MiB is no longer large enough for capturing the entire trace
history, and results in truncation. Use a size of 32MiB for the trace
buffer on the sandbox platform while running the trace test.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The EFI capsules can now be generated as part of U-Boot build, through
binman. Highlight these changes in the documentation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Support has been added for generating the EFI capsules through
binman. Make changes in the EFI capsule update testing feature to
generate capsules through binman.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Add support in binman for generating EFI capsules. The capsule
parameters can be specified through the capsule binman entry. Also add
test cases in binman for testing capsule generation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a bintool for generating EFI capsules. This calls the mkeficapsule
tool which generates the capsules.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable the EFI capsule update code on all sandbox variants. This was
already enabled on the sandbox, sandbox64 and sandbox_flattree
variants. The rest of the variants also have the EFI capsule update
module enabled now. With this commit, the mkeficapsule tool also gets
enabled on all variants.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add the private keys and public key certificates which are to be used
for capsule authentication while testing the EFI capsule update
functionality. There are two pairs of private and public keys, good
and bad. The good key pair will be used for signing capsules, whilst
the bad key pair is to be used as malicious keys for testing
authentication failure cases. The capsule_pub_key_good.crt is also
converted to an EFI Signature List(ESL) file, SIGNER.esl, which is
embedded in the platform's device-tree for capsule authentication.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a newline at the end of the dts, without which the build fails
when including a dtsi file.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
First, update CI to using gcc-13.2 from 13.1, and rebuild the CI
containers. This is needed because the second part adds utilities for
tests and provides, to quote the author:
This updates the ChromiumOS bootmeth to detect multiple kernel
partitions on a disk.
It also includes minor code improvements to the partition drivers,
including accessors for the optional fields.
This series also includes some other related tweaks in testing.
The latest kernel.org toolchains for gcc are now 13.2.0, so upgrade to
that.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The existing ChromiumOS bootmeth only supports reading a single kernel
partition, either 2 or 4. In fact there are normally two options
available.
Use the GUID to detect kernel partitions, with the BOOTMETHF_ANY_PART
flag, so that bootstd does not require a valid filesystem before calling
the bootmeth.
Tidy up and improve the logging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
[trini: Add missing select of PARTITION_TYPE_GUID]
Signed-off-by: Tom Rini <trini@konsulko.com>
Some bootmeths support scanning a partition without a filesystem on it.
Add a flag to support this.
This will allow the ChromiumOS bootmeth to find kernel partition, which
are stored in a special format, without a filesystem.
Signed-off-by: Simon Glass <sjg@chromium.org>
The ChromiumOS bootmeth has no tests at present. Before adding more
features. add a basic test.
This creates a disk which can be scanned by the bootmeth, so make sure
things work. It is quite rudimentary, since the kernel is faked, the root
disk is missing and there is no cmdline stored.
Enable the bootmeth for snow so it can build the unit test.
Signed-off-by: Simon Glass <sjg@chromium.org>
We currently use mmc4 for tests. Update the function which sets this up
so that it can handle any device.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present 'bootflow list' shows <NULL> for the filename when it is not
present. Show an empty string instead, since that is more user-friendly.
Signed-off-by: Simon Glass <sjg@chromium.org>
These are currently created in the source directory, which is not ideal.
Move them to the persistent-data directory instead. Update the test so
skip validating the filename, since it now includes a full path.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some pytests create files in the persistent-data directory. It is useful
to be able to access these files in C tests. Add a function which can
locate a file given its leaf name, using the environment variable set
up in test/py/conftest.py
Signed-off-by: Simon Glass <sjg@chromium.org>
These should be in the header file for easy browsing, not in the source
code. Move them and add a missing Return on one of the functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Follow the correct path in device_probe() when and event handler fails.
This avoids getting into a strange state where the device appears to be
activated but is not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a little more debugging for the initial signature check. Drop the
pointless check for NULL. Also set a log category while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is only present when a CONFIG is set. To avoid annoying #ifdefs
in the source code, add an accessor. Update the only usage.
Note that the accessor is optional. It can be omitted if it is known that
the option is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is only present when a CONFIG is set. To avoid annoying #ifdefs
in the source code, add accessors. Update all code to use it.
Note that the accessor is optional. It can be omitted if it is known that
the option is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
This field is only present when a CONFIG is set. To avoid annoying #ifdefs
in the source code, add accessors. Update all code to use it.
Note that the accessor is optional. It can be omitted if it is known that
the option is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some internal functions could do with a few comments, to explain what they
do. Add these, to make the code easier to follow.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the mac code to
just use 'desc'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the iso code to
just use 'desc'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the efi code to
just use 'desc'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the dos code to
just use 'desc'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the amiga code to
just use 'desc'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The dev_ prefix is a hangover from the pre-driver model days. The device
is now a different thing, with driver model. Update the partition code to
just use 'desc', as is done with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
To quote the author:
So far cedit does not support reading and writing the configuration.
This series add several features related to this:
First, it adds support for using a file on a filesystem. This is in
FDT format and provides enough information to reset the cedit back to
the saved settings.
Second, it adds support for using the U-Boot environment. Since the
environment is generally saved across reboots, this feature provides an
easy way of storing the state on most boards. The variables all have a
'c.' prefix to avoid confusion with other variables.
Finally it adds support for using CMOS RAM. This is commonly used on x86
devices to store BIOS settings. The expo schema provides information on
the register layout.
Some other minor tweaks and improvements are included along the way.
Add a command to read edit settings from CMOS RAM, using the cedit
definition to indicate which registers and bits are used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to write cedit settings to CMOS RAM so that it can be
preserved across a reboot. This uses a simple bit-encoding, where each
field has a 'bit position' and a 'bit length' in the schema.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to read cedit settings from environment variables so that
they can be restored as part of the environment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a command to write cedit settings to environment variables so that
they can be stored with 'saveenv'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Support writing settings from an expo into a file in FDT format. It
consists of a single node with a two properties for each sceneitem,
one with tag ID chosen by the user and another for its text value.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is related to standard boot, so put it under the same node. This may
simplify schema upstreaming later.
Mention themes in the documentation while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
