In order to build the docker container, which contains a download cache of python modules, we need to have our versions be in sync in each requirements file. Update some of the cases where which are older than the rest of the project. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
There is some potential security issue resolved by upgrading to v70.0.0 here and the latest is now v70.3.0. Reported-by: GitHub dependabot Suggested-by: Sebastian Kropatsch <seb-dev@mail.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
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
Rasmus Villemoes <rasmus.villemoes@prevas.dk> says: This is a followup to the patches that landed in 2024.01 and nearly made sure that source files for producing .dtbo files use the .dtso extension. In the same release, a few new .dts files snuck in, and there was also some test code involving .dtbo -> .dtbo.S -> .dtbo.o I didn't really know how to handle at the time. This should finish the job, bring us in sync with linux (at least in this respect), and drop the .dts -> .dtbo build rule.
Add a unit test for testing the Android bootmethod. This requires another mmc image (mmc7) to contain the following partitions: - misc: contains the Bootloader Control Block (BCB) - boot_a: contains a fake generic kernel image - vendor_boot_a: contains a fake vendor_boot image Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test this with: $ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img $ ./test/py/test.py --bd sandbox --build -k bootflow_android Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Guillaume La Roque <glaroque@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Distinguish more clearly between source files meant for producing .dtb from those meant for producing .dtbo. Note that in the linux tree, all device tree overlay sources have been renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit 81d362732bac). So this is also a step towards staying closer to linux with respect to both Kbuild and device tree sources, and eventually eliminating all .dts -> .dtbo instances. This also matches the documentation update done in commit 4fb7e570d6b. Cc: Masahisa Kojima <kojima.masahisa@socionext.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
A security issue exists with zipp before v3.19.1, and the current release is now v3.19.2. While the change in versions numbers is large, a manual inspection of the changelog shows that it's not as big as might be implied. Reported-by: GitHub dependabot Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
The tests we currently have expect the firmware update to fail when OsIndications is not set properly. However, we have a Kconfig flag that explicitly ignores that variable. Adjust the tests accordingly Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The build option to support images of type 'IMAGE_FORMAT_LEGACY' is CONFIG_LEGACY_IMAGE_FORMAT so update the pytest to check for the correct option. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
On tests which require "tftpboot" we need to depend not on cmd_net but rather cmd_tftpboot. And on tests which require cmd_pxe we do not need to also depend on cmd_net as this should be handled already via Kconfig logic. Signed-off-by: Tom Rini <trini@konsulko.com>