Use the API function list_count_nodes() to count the number of list
entries.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When a device fails to probe, the next device should be tried, until
either we find a suitable device or run out of devices. A device
should never be tried twice.
When we run out of devices of a particular priority, the hunter should
be used to generate devices of the next priority. Only if all attempts
fail should this function return an error.
Update the function to use the latent 'found' boolean to determine
whether another loop iteration is warranted, rather than setting 'dev'
to NULL, which creates confusion, suggesting that no devices have been
scanned and the whole process is starting from the beginning.
Note that the upcoming bootflow_efi() test is used to test this
behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/17
This turns out to be insufficient to fix the problem, since when
bootdev_next_prio() exits, the caller has no idea that this really
is the end. Nor is it, since there may be other devices which should
be checked.
The caller iterates which calls iter_incr() which calls
bootdev_next_prio() again, which finds the same device and the loop
continues.
We never did create a test for this[1], which makes it hard to be
sure which problem was fixed.
The original code had the virtue of staying in the loop looking for a
bootdev, so let's go back to that and try to fix this another way.
A future patch will make bootdev_next_prio() continue after failure
which should provide same effect.
This reverts commit 9d92c418acfb7576e12e2bd53fed294bb9543724.
Signed-off-by: Simon Glass <sjg@chromium.org>
android_image_get_ramdisk() will return an error if there is no ramdisk.
Using the android image without a ramdisk worked until commit
1ce8e10f3b4b ("image: Fix up ANDROID_BOOT_IMAGE ramdisk code") because
the return code wasn't checked until then. Return -ENOENT in case
there is no ramdisk and translate that into -ENOPKG in the calling
code, which will then indicate "no ramdisk" to its caller
(boot_get_ramdisk()).
This way, we can get rid of the "*rd_data = *rd_len = 0;" in the error
path, too.
With this, I'm able to boot a linux kernel using fastboot again:
fastboot --base 0x41000000 --header-version 2 --dtb /path/to/dtb \
--cmdline "root=/dev/mmcblk0p1 rootwait" boot path/to/Image
Signed-off-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20240729213657.2550935-1-mwalle@kernel.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
For SATA devices the class name is 'ahci' but the block device name is
'sata'.
Use function blk_get_uclass_name() to retrieve the correct string.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Specify the FIT and include information about each loaded image, as
required by the UPL handoff.
Write the UPL handoff into the bloblist before jumping to the next phase.
Control this using a runtime flag to avoid conflicting with other
handoff mechanisms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'upl' command to work with Universal Payload features. For now it
only supports reading and writing a handoff structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for writing the handoff information from
a structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
Universal Payload provides a standard way of handing off control between
two firmware phases. Add support for reading the handoff information into
a structure.
Signed-off-by: Simon Glass <sjg@chromium.org>
USB is stopped using driver model now, in dm_remove_devices_flags() in
announce_and_cleanup() at the top of this file.
The usb_stop() call actually unbinds devices.
When a USB device is unbound, it causes any bootflows attached to it to
be removed, via a call to bootdev_clear_bootflows() from
bootdev_pre_unbind(). This obviously makes it impossible to boot the
bootflow.
However, when booting a bootflow that relies on USB, usb_stop() is
called, which unbinds the device. At that point any information
attached to the bootflow is dropped.
This is quite risky since the contents of freed memory are not
guaranteed to remain unchanged. Depending on what other options are
done before boot, a hard-to-find bug may crop up.
Drop the call to this old function.
Leave the netconsole call there, since this needs conversion to
driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Shantur Rathore <i@shantur.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
U-Boot is often used conjunction with QEMU to boot via EFI or syslinux.
Here the QFW boot method is not needed.
At least for qemu-riscv64_smode_defconfig the kernel parameter is used
to specify the U-Boot binary. Trying to run U-Boot as a kernel makes
no sense.
Provide Kconfig parameter CONFIG_BOOTMETH_QFW to decide if the QFW boot
method shall be provided.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A valid memory location to stash bootstage information at will be
architecture dependent. Move the existing defaults to the main Kconfig
file for this option and set 0x0 as the default only for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Fix a minor indentation / whitespace problem in a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glkp@gmx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When reading a script from a network, no block device is available.
Update the implementation to support this correctly, avoiding setting
environment variables which relate only to block devices.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Fix a typo in the comment and add one to the EFI driver too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Add documentation for the sandbox bootmeth.
Fix up the compatible string to drop the 'extlinux' part, which is not
relevant to this bootmeth.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Add documentation for the qfw bootmeth.
Fix up the compatible string to drop the 'extlinux' part, which is not
relevant to this bootmeth.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Android boot flow is a bit different than a regular Linux distro.
Android relies on multiple partitions in order to boot.
A typical boot flow would be:
1. Parse the Bootloader Control Block (BCB, misc partition)
2. If BCB requested bootonce-bootloader, start fastboot and wait.
3. If BCB requested recovery or normal android, run the following:
3.a. Get slot (A/B) from BCB
3.b. Run AVB (Android Verified Boot) on boot partitions
3.c. Load boot and vendor_boot partitions
3.d. Load device-tree, ramdisk and boot
The AOSP documentation has more details at [1], [2], [3]
This has been implemented via complex boot scripts such as [4].
However, these boot script are neither very maintainable nor generic.
Moreover, DISTRO_DEFAULTS is being deprecated [5].
Add a generic Android bootflow implementation for bootstd.
For this initial version, only boot image v4 is supported.
[1] https://source.android.com/docs/core/architecture/bootloader
[2] https://source.android.com/docs/core/architecture/partitions
[3] https://source.android.com/docs/core/architecture/partitions/generic-boot
[4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h
[5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When calling android_image_get_dtb_by_index() using boot image v3+,
we should also pass the vendor_boot ramdisk address.
Use get_avendor_bootimg_addr() to do so.
Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr()
returns -1.
for legacy implementations that don't have CMD_ABOOTIMG, add a weak
implementation to avoid linking errors.
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Tested-by: Guillaume La Roque <glaroque@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Vincent Stehlé <vincent.stehle@arm.com> says:
Hi,
This is a respin of this patch [1] after discussion [2]. Thanks to
Simon and Heinrich for their reviews.
To use the guidcmp() function, as suggested by Heinrich, we need to
make it available to bootmeth_cros.c and I think that the cleanest way
to do that is (arguably) to move the guid helper functions to efi.h
near the efi_guid_t definition; this is why the original patch has now
become a series of two patches.
The alternative would be to include efi_loader.h from bootmeth_cros.c
but I think this does not sound "right". If this is in fact the
preferred approach just let me know and I will respin.
There is no difference in the sandbox binaries before/after this
series on Arm and on PC, and all the tests I have run on the sandbox
are unchanged.
The scan_part() function uses a struct uuid to store the little-endian
partition type GUID, but this structure should be used only to contain a
big-endian UUID. Use an efi_guid_t instead and use guidcmp() for the
comparison.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Marek Mojík <marek.mojik@nic.cz> says:
Hello all,
this is a continuation of previous work by Pali to add support for the
Turris 1.x board. As the patches were based on u-boot v2022.04, a
nontrivial rebasing was needed.
Some notes:
- Some options that are in SD defconfig are disabled in NOR defconfig
because over the years u-boot grew and the old NOR defconfig will not
fit into NOR memory.
- SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We
were not able to fix this yet)
Add support for CZ.NIC Turris 1.x routers.
CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they
have dual-core PowerPC Freescale P2020 CPU and are based on reference
Freescale P2020RDB-PC-A board design.
Hardware design is fully open source, all firmware and hardware design
files are available at Turris project website:
https://docs.turris.cz/hw/turris-1x/turris-1x/https://project.turris.cz/en/hardware.html
The P2020 BootROM can load U-Boot either from NOR flash or from SD card.
We add the new defconfigs, turris_1x_nor_defconfig, which configures
U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which
configures U-Boot for building an image suitable for SD card.
The defconfig for NOR image is stripped-down a - many config options
enabled in SD defconfig are disabled for NOR defconfig. This is because
U-Boot grew non-trivially in the last two years and it would not fit
into the space allocated for U-Boot in the NOR memory. In the future we
may try to use LTO to reduce the size of the code and enable more
options.
The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A
board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked
into Turris 1.x board code.
Turris 1.x code in this patch uses modern distroboot and can boot Linux
kernel from various locations, including NAND, SD card, USB flash disks,
NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers).
Via distroboot is implemented also rescue NOR boot for factory recovery,
triggered by reset button, like on other existing Turris routers.
SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were
not able to fix this yet)
[ Because various CONFIG_ macros were migrated to Kconfig since the last
time this worked on upstream U-Boot (in 2022), a non-trivial rebasing
was needed and some issues were solved. ]
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Mojík <marek.mojik@nic.cz>
Reviewed-by: Marek Behún <kabel@kernel.org>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
The scan_part() function uses a struct uuid to store the little-endian
partition type GUID, but this structure should be used only to contain a
big-endian UUID. Use an efi_guid_t instead.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Documentation:
Update requirements.txt to use current Python module versions
Add a page describing debugging U-Boot with GDB
FIT: describe data-size as a conditionally mandatory property
Correct link to FIT specification in SPL code.
Correct kaslrseed command long text description
UEFI:
Add unit test checking that don't have kaslr-seed when measuring boot
Deduplicate code for measured boot.
Other:
Print size information in fwu command
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmaBU44ACgkQhO4vgnE3
U0s1JRAAgyxfK6mjgS0rGI3wBv9N9twxYm/+2XcBFxqywcazuls31uNs+XO+U14u
pS73qzRn4gempz8FxOEjlEhzN4ycEjlR1zpO39Z21/wq1TSGSVjnRPmGnBx5t19Y
wxtptXr1A8mnaoqv3A3seEepC3/PDNSANjo/euHwHruepVM+f9VdotqVbr4Y4kFM
qYHuIBKawjMWDy8BB0HlbMgGDDanZZKbXjus8h0RVrbHQePUgAiztZ5bQCRSp9A7
uFNVvuIKSl2SUQ3kHIL9pwYhRCOXaNTSCsyiaxwfAMkhK9Em6QP2647ddvNNKAw2
V4EUf52lTUnd527iLqjvEvKcGcrVNCoYWsKtuRS8YHk/2jn7BjPY/bHW8MCiWN3Z
sG48Cqbq+fVG0+Qk2/I68kvGYGh4S4f9AeNihtQRXaxDzrLk1jBESakzUXI52ub3
YK+aZ83t232n9pyXZe855Qxpcp5HLfg6ZtdjnB/Oqp7NpSpuPeo8FmFwZ2Nz/+5u
qk29LwA5U8gO3N3qbwjIt7FpjlYuYyo8A3kiZttOy9epSM+0YrHx7V+dx8RJPKrD
a1NT1dONWL2QhoYC5788o/L+WPJprEy38aY3LYrbdtxlbqoTV1RRg5/RVfD6D6vk
lVR+RP/l/5iCa6nw5Cls6DZcMgV7DyCtyp0uMTJDVe7L62qhBFk=
=7g5n
-----END PGP SIGNATURE-----
Merge tag 'efi-2024-10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request efi-2024-10-rc1
Documentation:
Update requirements.txt to use current Python module versions
Add a page describing debugging U-Boot with GDB
FIT: describe data-size as a conditionally mandatory property
Correct link to FIT specification in SPL code.
Correct kaslrseed command long text description
UEFI:
Add unit test checking that don't have kaslr-seed when measuring boot
Deduplicate code for measured boot.
Other:
Print size information in fwu command
Simon reports that after enabling all algorithms on the TPM some boards
fail since they don't have enough storage to accommodate the ~5KB growth.
The choice of hash algorithms is determined by the platform and the TPM
configuration. Failing to cap a PCR in a bank which the platform left
active is a security vulnerability. It might allow unsealing of secrets
if an attacker can replay a good set of measurements into an unused bank.
If MEASURED_BOOT or EFI_TCG2_PROTOCOL is enabled our Kconfig will enable
all supported hashing algorithms. We still want to allow users to add a
TPM and not enable measured boot via EFI or bootm though and at the same
time, control the compiled algorithms for size reasons.
So let's add a function tpm2_allow_extend() which checks the TPM active
PCRs banks against the one U-Boot was compiled with. We only allow
extending PCRs if the algorithms selected during build match the TPM
configuration.
It's worth noting that this is only added for TPM2.0, since TPM1.2 is
lacking a lot of code at the moment to read the available PCR banks.
We unconditionally enable SHA1 when a TPM is selected, which is the only
hashing algorithm v1.2 supports.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-link
commit 97707f12fdab ("tpm: Support boot measurements") moved out code
from the EFI subsystem into the TPM one to support measurements when
booting with !EFI.
Those were moved directly into the TPM subsystem and in the tpm-v2.c
library. In hindsight, it would have been better to move it in new
files since the TCG2 is governed by its own spec, it's overeall cleaner
and also easier to enable certain parts of the TPM functionality.
So let's start moving the headers in a new file containing the TCG
specific bits.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tim Harvey <tharvey@gateworks.com> says:
This series will automatically add /chosen/kaslr-seed to the dt if
DM_RNG is enabled
during the boot process.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to overwrite
the node if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Use the fdt_kaslrseed function to deduplicate code doing the same thing.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Michal Simek <michal.simek@amd.com>
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Michal Simek <michal.simek@amd.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Akash Gajjar <gajjar04akash@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Devarsh Thakkar <devarsht@ti.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
The global bootmeths don't set the dev in bootflow struct which means
the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and
crash U-Boot.
So before trying to handle a bootflow, check that the associated
bootmeth isn't global, otherwise skip it.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This fixes a handful of typos in various help texts in Kconfig configs.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The PC client spec [0], doesn't describe measurements for DTBs. It does
describe what do to for ACPI tables though.
There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS,
and Embedded Drivers and they explicitly mention ACPI in there. There's
no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration.
However, in Figure 6 -- PCR Mapping of UEFI Components ACPI is shown
in PCR1. The general description also mentions PCR0 is for code and PCR1
is for data such as ACPI and SMBIOS.
So let's switch over the DTB measurements to PCR1 which seems a better
fit.
[0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
UEFI:
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
-----BEGIN PGP SIGNATURE-----
iQJWBAABCABAFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmZoOXUiHGhlaW5yaWNo
LnNjaHVjaGFyZHRAY2Fub25pY2FsLmNvbQAKCRCE7i+CcTdTS36HEACegzro+P2f
XZbdiRi0zN+ef5UkUVm/LECwBWXo0p9R5L3XWsRtxz8nqzG5JgB4lzDr0X3cRAVr
uUeg6xf5LSXCbme/Ct68bi27F54Z0OQDmVlvPC/zUQ6CUDPg+0HFlHiBgKGvkAy+
0HZY57OhXbviyuZ8JND/zL5GBGnyVGjyoghS0OvtSeWZ+6JIHYrMGH9fc1jtdS4+
jleIkKE4NKIJPOPQVpCr84SgtbsfFeaOtsAM6u5Asd8FkmKLjcgNpKw5Kj03vJwP
javMY/hG7LkAxHLEfDOe1A3z8AKqN+zrHZ0Rj7Xy+TdwEmh6IgsPkorPCjWa5g0W
Cp7pjf2Bq/dAZLhHCMPFBQ/aSv9t3b+LSdrGYJUffwmjhcJ/6+J+2ioD50cJc31E
Ov85HF7FpB9s82+3LL9QuFkQIdDdseNPCPUdEesA1GJjZUa8QrrrmmeTDuZZAmXm
HpAy3/hw1lTYG/yPSavQdr0bZNTcersvpIqchI5b/SXfAH+riSSuGGobtaYE61su
2esMKTMma1/aO2X3i7QCTntG4fKd/7Wfbf3lcjIJ3nuWlty+AvXZiD1nHM48d2P4
U3/Wbsls60mlAG/P15/eC8jxhkanrbSXNwGOjJMbh+OmwUukhvYg+35t5qZkCwuW
OHIFOWhFuIs+tsEUoOllZldDgmWB9hpjxg==
=D5PO
-----END PGP SIGNATURE-----
Merge tag 'efi-next-20240611' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request efi-next-20240611
UEFI:
* Allow specifying a device-tree in an EFI load option
using the efidebug or eficonfig command.
* Let the EFI boot manager fall back to an OS provided device-tree
if no device-tree is specified.
Move distro_efi_get_fdt_name() to a separate C module
and rename it to efi_get_distro_fdt_name().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Quote from [1]:
"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."
While at it, update wrong error handling message when vendor_boot
cannot be loaded.
[1]: https://source.android.com/docs/core/architecture/partitions/generic-boot
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
The boot_ramdisk and vendor_ramdisk must be both concatenated together.
Without this change, Android root is missing some of the necessary tools
to complete virtual AB OTA.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
