- Aug 22, 2024
-
-
android_image_get_ramdisk() will return an error if there is no ramdisk. Using the android image without a ramdisk worked until commit 1ce8e10f ("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:
-
- Aug 11, 2024
-
-
Heinrich Schuchardt authored
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:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by:
-
- Jul 31, 2024
-
-
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:
Shantur Rathore <i@shantur.com> Reviewed-by:
-
- Jul 19, 2024
-
-
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:
-
Tom Rini authored
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:
Tom Rini <trini@konsulko.com>
-
Fix a minor indentation / whitespace problem in a comment. Signed-off-by:
Heinrich Schuchardt <xypron.glkp@gmx.de> Reviewed-by:
Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by:
-
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:
-
Fix a typo in the comment and add one to the EFI driver too. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by:
-
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:
-
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:
-
- Jul 18, 2024
-
-
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:
Julien Masson <jmasson@baylibre.com> Tested-by:
Guillaume La Roque <glaroque@baylibre.com> Signed-off-by:
-
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:
-
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:
-
- Jul 16, 2024
-
-
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:
Vincent Stehlé <vincent.stehle@arm.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
-
- Jul 15, 2024
-
-
Drop all duplicate newlines. No functional change. Signed-off-by:Marek Vasut <marek.vasut+renesas@mailbox.org>
-
- Jul 12, 2024
-
-
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>
-
- Jul 05, 2024
-
-
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>
-
- Jul 03, 2024
-
-
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:
-
- Jun 30, 2024
-
-
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:
-
commit 97707f12 ("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:
-
- Jun 28, 2024
-
-
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:
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:
-
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:
Caleb Connolly <caleb.connolly@linaro.org>
-
It does not make sense to enable all SHA algorithms unless they are needed. It bloats the code and in this case, causes chromebook_link to fail to build. That board does use the TPM, but not with measured boot, nor EFI. Since EFI_TCG2_PROTOCOL already selects these options, we just need to add them to MEASURED_BOOT as well. Note that the original commit combines refactoring and new features, which makes it hard to see what is going on. Fixes: 97707f12 tpm: Support boot measurements Reviewed-by:
-
- Jun 26, 2024
-
-
Show which boot protocol is being used. Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com>
-
- Jun 22, 2024
-
-
Heinrich Schuchardt authored
Correct the links to the FIT documentation in boot/Kconfig. Signed-off-by:
-
- Jun 20, 2024
-
-
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:
-
This fixes a handful of typos in various help texts in Kconfig configs. Signed-off-by:
-
- Jun 16, 2024
-
-
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:
Eddie James <eajames@linux.ibm.com>
-
- Jun 10, 2024
-
-
Heinrich Schuchardt authored
Move distro_efi_get_fdt_name() to a separate C module and rename it to efi_get_distro_fdt_name(). Signed-off-by:
-
- Jun 07, 2024
-
-
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:
-
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:
-
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:
-
- May 22, 2024
-
-
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:
-
- May 20, 2024
-
-
Tom Rini authored
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 <jonas@kwiboo.se> Signed-off-by:
-
- May 19, 2024
-
-
Tom Rini authored
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 c8ffd135, reversing changes made to 2ee6f3a5. Reported-by:
-
- May 06, 2024
-
-
Tom Rini authored
Remove <common.h> from all "boot/" files and when needed add missing include files directly. Signed-off-by:
-
- May 05, 2024
-
-
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>
-
- Apr 21, 2024
-
-
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>
-
