u-boot.git/boot, branch v2024.10-rc2 Unnamed repository; edit this file 'description' to name the repository. usb: bootm: Drop old USB-device-removal code 2024-07-31T17:20:57+00:00 Simon Glass sjg@chromium.org 2024-07-26T12:36:09+00:00 59ca3a2f20f37fd45e4ccf266ae2df9379c7af91 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> 
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>
boot: provide CONFIG_BOOTMETH_QFW Kconfig parameter 2024-07-19T22:48:07+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2024-07-16T08:35:34+00:00 4f658510074bf85ee4ddc0fb3d2cb5dd45a1c561 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> 
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>
bootstash: Do not provide a default address for all 2024-07-19T22:48:07+00:00 Tom Rini trini@konsulko.com 2024-07-15T11:42:00+00:00 b81e31a1e6c5e0b20537fa8ffba67696dec46d58 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> 
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>
boot: Correct indentation in efi bootmeth 2024-07-19T12:01:42+00:00 Simon Glass sjg@chromium.org 2024-07-17T08:31:03+00:00 6b387c9396f8df431e58d7e75bbd7ea9fd0043ca 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> 
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>
bootstd: Correct handling of script from network 2024-07-19T11:57:50+00:00 Simon Glass sjg@chromium.org 2024-07-17T08:31:00+00:00 60b180fdba1bf7bbd6181c1eef804a20fa485427 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> 
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>
bootstd: Tidy up comments on the boothmeth drivers 2024-07-19T11:57:47+00:00 Simon Glass sjg@chromium.org 2024-07-17T08:30:59+00:00 cfed2219e36946902e3bd57d5c647ab8f10f6397 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> 
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>
doc: Add a description for bootmeth_sandbox 2024-07-19T11:57:44+00:00 Simon Glass sjg@chromium.org 2024-07-17T08:30:58+00:00 95403023cfa890b4e5e7ce7040227e518b2da288 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 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>
doc: Add a description for bootmeth_qfw 2024-07-19T11:54:54+00:00 Simon Glass sjg@chromium.org 2024-07-17T08:30:56+00:00 70a4982d4fd83d18cd1951b2be9f3e7538b8c499 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> 
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>
Merge patch series "bootstd: Add Android support" 2024-07-18T23:03:47+00:00 Tom Rini trini@konsulko.com 2024-07-18T19:52:11+00:00 459560000736ac7c9c8b04522789c20fb45ff95a Mattijs Korpershoek <mkorpershoek@baylibre.com> 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 
Mattijs Korpershoek <mkorpershoek@baylibre.com> 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:30+00:00 Mattijs Korpershoek mkorpershoek@baylibre.com 2024-07-10T08:40:05+00:00 125d9f3306ea4bc8888dc991ae3aa87327b0d522 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> 
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>