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 97707f12fd ("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>
When decompressing, it's possible that the algorithm only performs
a partial decompression.
This usually happens when CONFIG_SYS_BOOTM_LEN is too small for
the uncompressed image.
When that happens, image_decomp() returns an error and *load_end == load.
The error is then handled by handle_decomp_error().
handle_decomp_error() expects the number of uncompressed bytes in
uncomp_size but receives *load_end - load == load - load == 0.
Because of this, handle_decomp_error does not report the expected
"Image too large: increase CONFIG_SYS_BOOTM_LEN" error message.
Modify the image_decomp() logic to always report the decompressed size,
even when a partial decompression happened.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Remove the redundant includes of u-boot/md5.h, u-boot/sha1.h,
u-boot/sha256.h and u-boot/sha512.h
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add SPL variant of DM_RNG so that the DM_RNG can be disabled in SPL
if necessary. This may be necessary due to e.g. size constraints of
the SPL.
Signed-off-by: Marek Vasut <marex@denx.de>
Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.
This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
Enable and update simple-framebuffer node using the video handoff
bloblist if video was enabled at SPL stage and corresponding video
bloblist was received at u-boot proper with necessary parameters.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f1497 ("Kconfig: Remove all
default n/no options").
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In case of systems where DRAM bank ends at the edge of 32bit boundary,
start + size calculations would overflow. This happens on STM32MP15xx
with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
usual 32bit system DRAM size overflow, fix it by doing all DRAM size
and offset calculations using u64 types. This also covers a case where
a 32bit PAE system might be able to address up to 36bits of DRAM.
Fixes: a4df06e41f ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t")
Signed-off-by: Marek Vasut <marex@denx.de>
When "memory" node is being processed in fdt_pack_reg() on ARM64
platforms, an unaligned bus access might happen, which leads to
"synchronous abort" CPU exception. Consider next dts example:
/ {
#address-cells = <2>;
#size-cells = <1>;
memory@80000000 {
device_type = "memory";
reg = <0x0 0x80000000 0x3ab00000>,
<0x0 0xc0000000 0x40000000>,
<0x8 0x80000000 0x80000000>;
};
};
After fdt_pack_reg() reads the first addr/size entry from such memory
node, the "p" pointer becomes 12 bytes shifted from its original value
(8 bytes for two address cells + 4 bytes for one size cell). So now it's
not 64-bit aligned, and an attempt to do 64-bit bus access to that
address will cause an abort like this:
"Synchronous Abort" handler, esr 0x96000021, far 0xba235efc
This issue was originally reported by David Virag [1] who observed it
happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
was observed on Samsung Exynos850 (ARM64).
Fix the issue by using put_unaligned_be64() helper, which takes care of
possible unaligned 64-bit accesses. That solution was proposed by Simon
Glass in the original thread [1].
[1] https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Fixes: 739a01ed8e ("fdt_support: fix an endian bug of fdt_fixup_memory_banks")
Suggested-by: Simon Glass <sjg@google.com>
Reported-by: David Virag <virag.david003@gmail.com>
Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Move the variable below comment which explains what the variable means.
Update the comment. No functional change.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The lmb_alloc_base() returns phys_addr_t , map_sysmem() accepts
phys_addr_t as first parameter. Declare 'addr' as phys_addr_t and
get rid of the casts.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reduce tmp variable use and remove unnecessary type cast in
env_get_bootm_mapsize(). This aligns the env variable parsing
with env_get_bootm_low(). No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Change type of 'tmp' variable from phys_size_t to phys_addr_t and
rename it to 'low' to better describe what the variable represents,
which is either the bootm_low address from environment or start of
DRAM address.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reduce tmp variable use and remove unnecessary type cast in
env_get_bootm_size(). This aligns the env variable parsing
with env_get_bootm_low(). No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
It also updates fastboot to do a similar thing.
Use zboot_run() to boot rather than the command line. This allows
extlinux to be used (on x86) without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use bootm_run() and booti_run() to boot rather than the command line.
This allows extlinux to be used without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code undertakes a separate task from the main logic of
label_run_boot() so move it into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
The bootm_argv[3] expression is used in many places. It is the FDT
address, so use that name throughout.
Assign it to bootm_argv[3] only at the end, when all the conditions are
resolved.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is far too long and complicated. Split out the part
which actually calls the boot commands into a separate function.
Change a strncpy() to strlcpy() to keep checkpatch happy.
No functional change is intended.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new CONFIG_BOOTM symbol to determine whether SYS_BOOT_LEN is
visible or not, since we want to support decompression when CMDLINE is
disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Booting an OS does not require the 'bootm' command, so change the
condition for these options.
Move them into boot/ so they don't depend on CMDLINE
Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code
so will need some additional refactoring (and a test!) to allow it to
change over.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Create a separate Kconfig option which enables the bootm logic,
separate from the 'bootm' command. This will eventually allow booting
without CMDLINE enabled.
Update boards which disable CMD_BOOTM to disable BOOTM instead, since
CMD_BOOTM now depends on BOOTM
Signed-off-by: Simon Glass <sjg@chromium.org>
The boot menu shows Android first and then a timestamp option. Move
these later since they are less commonly used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This series refactors the zboot code to allow it to be used with
CONFIG_COMMAND disabled.
A new zboot_run() function is used to boot a zimage.
The term 'start' is used withint bootm and zboot to indicate the first
phase of booting an image.
Since zboot_start() does the whole boot, rename it to zboot_run() to
align with bootm_run() etc.
Fix a log message while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
* The sandbox must not use an arbitrary file name bootsbox.efi but the
file name matching the host architecture to properly boot the respective
file. We already have an include which provides a macro with the name of
the EFI binary. Use it.
* The path to the EFI binary should be absolute.
* The path and the file name must be capitalized to conform to the UEFI
specification. This is important when reading from case sensitive
file systems.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
