Add an example to show how cbfs is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[Removed CONFIG_CMD_CBFS from defconfig files]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Add some more output to make it easier to see what is going wrong when
a bootdev hunter fails.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use the correct function here, since there may be multiple IDE devices
available.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When CONFIG_ERRNO_STR is not enabled this shows a spurious 'E' from the
format string. Fix this.
Fixes: 7f33194132 ("lib: Support printing an error string")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When USB finds no devices it currently returns -EPERM which bootstd does
not understand. This causes other bootdevs of the same priority to be
skipped.
Fix this by returning the correct error code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support to config fragments (.config) located in the /board
directory. This will allow only base defconfigs to live in /configs and
all fragments to live in their respective device directory in /board/..
Signed-off-by: Jason Kacines <j-kacines@ti.com>
Now all linker symbols are declared as type char[]. Though we can
reference the address via both the array name 'var' and its address
'&var'. It's better to unify them to avoid confusing developers.
This patch converts all '&var' linker symbol refrences to the most
commonly used format 'var'.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
1. Convert all linker symbols to char[] type so that we can get the
corresponding address by calling array name 'var' or its address
'&var'. In this way, we can avoid some potential issues[1].
2. Remove unused symbol '_TEXT_BASE'. It has been abandoned and has
not been referenced by any source code.
3. Move '__data_end' to the arch x86's own sections header as it's
only used by x86 arch.
4. Remove some duplicate declared linker symbols. Now we use the
standard header file to declare them.
[1] This patch fixes the boot failure on MIPS target. Error log:
SPL: Image overlaps SPL
Fixes: 1b8a1be1a1 ("spl: spl_legacy: Fix spl_end address")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Documentation:
* Update examples for imx8mp_evk
* OpenOCD debugging guide for TI K3 boards
* Explain using gadget devices on TI boards
* Describe best practices for board ports
-----BEGIN PGP SIGNATURE-----
iQJWBAABCABAFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmTTNkQiHGhlaW5yaWNo
LnNjaHVjaGFyZHRAY2Fub25pY2FsLmNvbQAKCRCE7i+CcTdTS+AZD/4jPK7Ztw+W
UUP8T6bRVD4ZMiZ59E6HNvpSnnO8JphTQOyGvp+gjnvnzJEwRVljSTjWXLDzm8iM
CsbqDShSQuey5lKOZc7Ht6HH18l5Y6BDNv7hfZzRfZAKDiGn0JNo6lF9oSpzzvT7
0UZDlG6vb2Vj2MthP+ltRNX8upcJ9OMUIWJWqxMhAbGN06+qCl0vef4AwzfOuv5J
9stHSB7aAaDHKd9SzzGqem6VhXS1lLU21ObwDJ9/VGVklvlLBHzJvFiJNrS15LnV
ZEwPh0bSmH5CVLJXvuL5BK1CCo/nGcO0Q5K8ELJHI0c0qfEmcUvtQZzhFFxyJenX
xIE6C0jRjowgsYGTnxyECRPtOuEh0ZRxcFwpVzeeWkBwfgVJcSaJ8LS3u/lTvpTv
beqSi6c0o/PBLn9ubeDdKXWOUx/ZOSVU76Uu14rdAMYj+hh7JtgNnCFGSlr18sJ5
k5XE8RlUONKAl7JYntQ0/NyLI32a/ToF3va6vbNCEYCDra7DxDH06pceoqbuZbAu
RU3CP1x5oNmVoDp819Urof5MMxAK6Pr9O3OFpGCHJoaARjcrUcA+ZMp9TWpjtK/W
fJ+VaulA3+kUS831ncaZQ5vi9vE1a5yKGXloOfc9FXaGxwA8B87voCsc1/82Ey3q
+FUw5KEg1JmPkJPXI86o4qZfBuGPmqXEGQ==
=GuTp
-----END PGP SIGNATURE-----
Merge tag 'doc-2023-10-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for doc-2023-10-rc3
Documentation:
* Update examples for imx8mp_evk
* OpenOCD debugging guide for TI K3 boards
* Explain using gadget devices on TI boards
* Describe best practices for board ports
Function board_switch_core_volt has not been used since it was
defined
Signed-off-by: Shenlin Liang <liangshenlin@eswincomputing.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
To help guide developers down the right path, begin a document that
lists some best practices to follow when creating a new board port.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
To make it consistent with the instructions from other NXP imx8m boards,
such as imx8mm-evk and imx8mn-evk, use U-Boot in-tree build in the
examples.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Originally, exporting the ATF_LOAD_ADDR was required, but since binman has
been used to generate the flash.bin, it is no longer needed to do
such manual export.
The ATF address is now passed via binman in imx8mp-u-boot.dtsi:
atf {
description = "ARM Trusted Firmware";
type = "firmware";
arch = "arm64";
compression = "none";
load = <0x970000>;
entry = <0x970000>;
atf_blob: atf-blob {
filename = "bl31.bin";
type = "atf-bl31";
};
};
Remove the unneeded export ATF_LOAD_ADDR line.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Describe the current situation wrt the handling of USB devices on AM33xx
based boards, taking the example of a common board (the Beagle Bone
Black) and explaining how the different USB gadgets can be used.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Fix the Verdin module output which was missing white space for correct
rendering.
While at it also leave product links, add section author also for the
Verdin iMX8M Mini and Plus, and add a missing CROSS_COMPILE export for
the Verdin iMX8M Mini.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Nishanth Menon <nm@ti.com> #verdin-am62
Reviewed-by: Tom Rini <trini@konsulko.com>
Bootloader debug usually tends to be a bit dicey prior to DDR and
serial port getting active in the system. JTAG typically remains the
only practical debug option during the initial bringup.
OpenOCD is one of the most popular environment for providing debug
capability via a GDB compatible interface for developers to work with.
Debugging U-Boot and bootloaders on K3 platform does have a bit of
tribal knowledge that is better documented in our common platform
documentation.
Signed-off-by: Jason Kacines <j-kacines@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
If an error message contains a function name, it should match the name of
the function throwing the message.
Fixes: 7739d93d82 ("pci: Match region flags using a mask")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The btrfs_decompress() function mostly (u32)-1 on error but it can
also return -EPERM or other kernel error codes from zstd_decompress().
The "ret" variable is an int, so we could just check for negatives.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Qu Wenruo <wqu@suse.com>
The x509_cert_parse() and pkcs7_parse_message() functions return error
pointers. They don't return NULL. Update the checks accordingly.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This should be allocating the memory for "item" instead of "menu".
The item struct is 48 bytes instead of 96 (assuming a 64bit system)
so this saves a little memory.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Match the "=0x" instead of just "=0".
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Heinrich.Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This line break is not done correctly. We don't want to have all those
tabs in the printed output.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The u16_strlcat() is in units of u16 not bytes. So the limit needs to
be ARRAY_SIZE() instead of sizeof().
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
These lines are supposed to be indented one more tab. Otherwise it's
confusing to read.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
We know that "pa" is non-NULL so it's nicer to just return zero instead
of return !pa. This has no effect on runtime behavior.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The "oftree_count" is the number of entries which have been set in
the oftree_list[] array. If all the entries have been initialized then
this off by one would result in reading one element beyond the end
of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
If btrfs_read_fs_root() fails with -ENOENT, then we go to the next
entry. Fine. But if it fails for a different reason then we need
to clean up and return an error code. In the current code it
doesn't clean up but instead dereferences "root" and crashes.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Qu Wenruo <wqu@suse.com>
The ec_command_inptr() function returns negative error codes or
the number of bytes that it was able to read. The cros_ec_get_sku_id()
function should return negative error codes. Right now it returns
positive error codes or negative byte counts.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The VNBYTES() macro needs to have parentheses to prevent some (harmless)
macro expansion bugs. The VNBYTES() macro is used like this:
VID_TO_PIXEL(x) * VNBYTES(vid_priv->bpix)
The * operation is done before the / operation. It still ends up with
the same results, but it's not ideal.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The parentheses are in the wrong place so this passes the number of
bytes to write as "sizeof(index_0) != TPM_SUCCESS" when just
"sizeof(index_0)" was intended. (1 byte vs 4 bytes).
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
This returns the wrong variable. It ends up returning NULL when it was
suppose to return an error pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Both the Linux kernel and libbsd agree that strlcpy() should always
return strlen(src) and not include the NUL termination. The incorrect
U-Boot implementation makes it impossible to check the return value for
truncation, and breaks code written with the usual implementation in
mind (for example, fdtdec_add_reserved_memory() was subtly broken).
I reviewed all callers of strlcpy() and strlcat() and fixed them
according to my understanding of the intended function.
This reverts commit d3358ecc54 and adds
related fixes.
Fixes: d3358ecc54 ("lib: string: Fix strlcpy return value")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
To quote the author:
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A].
FF-A specifies interfaces that enable a pair of software execution
environments aka partitions to communicate with each other. A partition
could be a VM in the Normal or Secure world, an application in S-EL0, or
a Trusted OS in S-EL1.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by
the PSCI driver.
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
...
firmware 0 [ + ] psci |-- psci
ffa 0 [ ] arm_ffa | `-- arm_ffa
...
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
This implementation of the specification provides support for Aarch64.
The FF-A driver uses the SMC ABIs defined by the FF-A specification to:
- Discover the presence of secure partitions (SPs) of interest
- Access an SP's service through communication protocols
(e.g: EFI MM communication protocol)
The FF-A support provides the following features:
- Being generic by design and can be used by any Arm 64-bit platform
- FF-A support can be compiled and used without EFI
- Support for SMCCCv1.2 x0-x17 registers
- Support for SMC32 calling convention
- Support for 32-bit and 64-bit FF-A direct messaging
- Support for FF-A MM communication (compatible with EFI boot time)
- Enabling FF-A and MM communication in Corstone1000 platform as a use case
- A Uclass driver providing generic FF-A methods.
- An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods.
- A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides
FF-A ABIs inspection methods.
- An FF-A sandbox device driver for FF-A communication with the emulated Secure World.
The driver leverages the FF-A Uclass to establish FF-A communication.
- Sandbox FF-A test cases.
- A new command called armffa is provided as an example of how to access the
FF-A bus
For more details about the FF-A support please refer to [B] and refer to [C] for
how to use the armffa command.
Please find at [D] an example of the expected boot logs when enabling
FF-A support for a platform. In this example the platform is
Corstone1000. But it can be any Arm 64-bit platform.
More details:
[A]: https://developer.arm.com/documentation/den0077/latest/
[B]: doc/arch/arm64.ffa.rst
[C]: doc/usage/cmd/armffa.rst
[D]: example of boot logs when enabling FF-A
turn on EFI MM communication
On Corstone-1000 platform MM communication between u-boot
and the secure world (Optee) is done using the FF-A bus.
Changes made are generated using savedefconfig.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Add MM communication support using FF-A transport
This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.
An MM shared buffer and a door bell event are used to exchange
the data.
The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.
The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).
On such event, MM SP can read the data and updates the MM shared
buffer with the response data.
The response data is copied back to the communication buffer and
consumed by the EFI subsystem.
MM communication protocol supports FF-A 64-bit direct messaging.
We tested the FF-A MM communication on the Corstone-1000 platform.
We ran the UEFI SCT test suite containing EFI setVariable, getVariable and
getNextVariable tests which involve FF-A MM communication and all tests
are passing with the current changes.
We made the SCT test reports (part of the ACS results) public following the
latest Corstone-1000 platform software release. Please find the test
reports at [1].
[1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
A Sandbox test is provided for the armffa command.
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
provide a test case
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
convert UUID string to little endian binary data
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
add support for x0-x17 registers used by the SMC calls
In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
Results are returned in x0-x17.
This work is inspired from the following kernel commit:
arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
[1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
