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>
Add test for API cpu_release_core(). Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
The linux kernel has the list_count_nodes() API functions which is used for counting nodes of a list. This has now been imported in U-Boot as part of an earlier commit. Use this function and drop the list_count_items(). Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
Distinguish more clearly between source files meant for producing .dtb from those meant for producing .dtbo. In this case, the files are really meant to be compiled to .dtbo -> .dtbo.S -> .dtbo.o that get embedded in the image, which means that the begin/end symbols generated by the makefile rule changes to __dtbo_ rather than __dtb, so the consuming .c file needs updating, but this should not result in any functional change. 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. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Simon Glass <sjg@chromium.org> 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>