| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Prepare v2024.10-rc3
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Read the UPL early in boot so that it is available. For now none of the
information is used.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Suggested-by: Shantur Rathore <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Fix a minor indentation / whitespace problem in a comment.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Fix a typo in the comment and add one to the EFI driver too.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Mattijs Korpershoek <[email protected]> says:
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:
a. Get slot (A/B) from BCB
b. Run AVB (Android Verified Boot) on boot partitions
c. Load boot and vendor_boot partitions
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.
This has been tested on sandbox using:
$ ./test/py/test.py --bd sandbox --build -k test_ut
This has also been tested on the AM62X SK EVM using TI's Android SDK[6]
To test on TI board, the following (WIP) patch is needed as well:
https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04
[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/[email protected]/
[6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html
|
|
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/[email protected]/
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Some bootflows might be able to only boot from MMC devices.
Add a helper function these bootflows can use.
Reviewed-by: Igor Opaniuk <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Reviewed-by: Igor Opaniuk <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Vincent Stehlé <[email protected]> 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 <[email protected]>
Signed-off-by: Vincent Stehlé <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Marek Mojík <[email protected]> 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 <[email protected]>
Signed-off-by: Marek Mojík <[email protected]>
Reviewed-by: Marek Behún <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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é <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Simon Glass <[email protected]> # 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 <[email protected]>
|
|
Tim Harvey <[email protected]> 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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Andy Yan <[email protected]>
Cc: Akash Gajjar <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Devarsh Thakkar <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Hugo Villeneuve <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Chris Morgan <[email protected]>
Acked-by: Michal Simek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Andy Yan <[email protected]>
Cc: Akash Gajjar <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Devarsh Thakkar <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Hugo Villeneuve <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Chris Morgan <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Andy Yan <[email protected]>
Cc: Akash Gajjar <[email protected]>
Cc: Ilias Apalodimas <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Patrick Delaunay <[email protected]>
Cc: Patrice Chotard <[email protected]>
Cc: Devarsh Thakkar <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Hugo Villeneuve <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Chris Morgan <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
|
|
Show which boot protocol is being used.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
|
|
Prepare v2024.07-rc5
|
|
Correct the links to the FIT documentation in boot/Kconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This fixes a handful of typos in various help texts in Kconfig configs.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Eddie James <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Igor Opaniuk <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
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 c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
