u-boot.git/boot/Kconfig, branch v2024.10

boot: provide CONFIG_BOOTMETH_QFW Kconfig parameter

2024-07-19T22:48:07Z

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 Reviewed-by: Simon Glass

bootstash: Do not provide a default address for all

2024-07-19T22:48:07Z

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 Signed-off-by: Tom Rini

Merge patch series "bootstd: Add Android support"

2024-07-18T23:03:47Z

Mattijs Korpershoek 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/20230914165615.1058529-17-sjg@chromium.org/ [6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html

bootstd: Add a bootmeth for Android

2024-07-18T19:51:30Z

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 Reviewed-by: Julien Masson Tested-by: Guillaume La Roque Signed-off-by: Mattijs Korpershoek

Merge patch series "Add Turris 1.x board"

2024-07-12T20:00:45Z

Marek Mojík 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)

powerpc: Add support for CZ.NIC Turris 1.x routers

2024-07-12T19:07:43Z

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 Signed-off-by: Marek Mojík Reviewed-by: Marek Behún

Fix Kconfig coding style from spaces to tab

2024-07-05T19:57:02Z

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

tpm: allow the user to select the compiled algorithms

2024-06-30T11:58:31Z

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 Reviewed-by: Simon Glass Tested-by: Simon Glass # chromebook-link

Merge tag 'v2024.07-rc5' into next

2024-06-24T19:34:52Z

Prepare v2024.07-rc5

boot: links to FIT documentation in Kconfig

2024-06-22T15:02:23Z

Correct the links to the FIT documentation in boot/Kconfig. Signed-off-by: Heinrich Schuchardt