u-boot.git/tools, branch v2025.07-rc2 Unnamed repository; edit this file 'description' to name the repository. Dockerfile: use lz4 instead of lz4-tools 2025-05-09T21:08:09+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2025-05-05T14:43:14+00:00 285d265f7dcf7b5a8984d7015b07b2e86de91420 Since Ubuntu Jammy lz4-tools is only a virtual package which pulls in lz4 as dependency. Update documentation too. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com> 
Since Ubuntu Jammy lz4-tools is only a virtual package which pulls in
lz4 as dependency.

Update documentation too.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
tools: imx8image: add i.MX95 support 2025-05-03T19:55:32+00:00 Alice Guo alice.guo@nxp.com 2025-04-28T10:37:40+00:00 5f28a6599f010333390035baa4b516d364407a53 i.MX95 uses binman to invoke mkimage to create image container. 2 image containers are needed currently. The first one is composed of ahab-container.img, LPDDR firmware images, OEI images, System Manager image and u-boot-spl.bin. The second one is consisted of ARM Trusted firmware and u-boot.bin. Because DDR OEI image and LPDDR firmware images have to be packaged together and named as m33-oei-ddrfw.bin by binman, so imx9_image.sh does not check if m33-oei-ddrfw.bin exists. When using "make imx95_19x19_evk_defconfig; make", imx9_image.sh will delete the line for u-boot.bin in container.cfg. In fact, binman is always called after the u-boot.bin is built, so imx9_image.sh does not check if u-boot.bin exists. Signed-off-by: Alice Guo <alice.guo@nxp.com> 
i.MX95 uses binman to invoke mkimage to create image container. 2 image
containers are needed currently. The first one is composed of
ahab-container.img, LPDDR firmware images, OEI images, System Manager
image and u-boot-spl.bin. The second one is consisted of ARM Trusted
firmware and u-boot.bin.

Because DDR OEI image and LPDDR firmware images have to be packaged
together and named as m33-oei-ddrfw.bin by binman, so imx9_image.sh does
not check if m33-oei-ddrfw.bin exists.

When using "make imx95_19x19_evk_defconfig; make", imx9_image.sh will
delete the line for u-boot.bin in container.cfg. In fact, binman is
always called after the u-boot.bin is built, so imx9_image.sh does not
check if u-boot.bin exists.

Signed-off-by: Alice Guo <alice.guo@nxp.com>
binman: add a new entry type for packing DDR PHY firmware images 2025-05-03T19:55:32+00:00 Alice Guo alice.guo@nxp.com 2025-04-28T10:37:39+00:00 0318c26c2fcd4e38f7a9e991409fd458c7790e07 i.MX95 needs to combine DDR PHY firmware images and their byte counts together, so add a new entry type nxp-header-ddrfw for this requirement. Signed-off-by: Alice Guo <alice.guo@nxp.com> 
i.MX95 needs to combine DDR PHY firmware images and their byte counts
together, so add a new entry type nxp-header-ddrfw for this requirement.

Signed-off-by: Alice Guo <alice.guo@nxp.com>
Docker, CI: Add vexpress_fvp / vexpress_fvp_bloblist support 2025-04-29T17:40:40+00:00 Tom Rini trini@konsulko.com 2025-04-22T19:36:56+00:00 d75998b476de439a05b2f7ec95d426410bcaae18 This adds the vexpress_fvp and vexpress_fvp_bloblist platforms to the list of platforms we test via emulator in CI. In order to do this we need to first have our container runtime have TF-A builds for the vexpress_fvp platform, both with and without transfer list support as well as installing "telnet" so that we can access console. In the CI files we check for the existence of /opt/tf-a/${TEST_PY_BD} and if found, copy bl1.bin and fip.bin to /tmp and set the variables so that we can later run FVP to run. Note that we currently disable the hostfs (semihosting) tests as they trigger a bug in FVP. This has been reported upstream, and can be enabled when fixed. Reviewed-by: Harrison Mutai <harrison.mutai@arm.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Tom Rini <trini@konsulko.com> 
This adds the vexpress_fvp and vexpress_fvp_bloblist platforms to the
list of platforms we test via emulator in CI. In order to do this we
need to first have our container runtime have TF-A builds for the
vexpress_fvp platform, both with and without transfer list support as
well as installing "telnet" so that we can access console. In the CI
files we check for the existence of /opt/tf-a/${TEST_PY_BD} and if
found, copy bl1.bin and fip.bin to /tmp and set the variables so that we
can later run FVP to run.

Note that we currently disable the hostfs (semihosting) tests as they
trigger a bug in FVP. This has been reported upstream, and can be
enabled when fixed.

Reviewed-by: Harrison Mutai <harrison.mutai@arm.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
mkimage: fix option parsing segfault 2025-04-28T19:25:59+00:00 Carlos López carlos.lopezr4096@gmail.com 2025-04-24T15:08:19+00:00 2c529839a93d886253c596449545f62bec21a4ac getopt_long() expects a NULL-terminated list of structures. The current list in mkimage does not have a zero-filled structure at the end, which can cause getopt_long() to walk past the end of the array when passing an unknown option, causing a segmentation fault. As a reproducer, the following command causes a segmentation fault (tested in Debian 12): mkimage --foobar Signed-off-by: Carlos López <carlos.lopezr4096@gmail.com> 
getopt_long() expects a NULL-terminated list of structures. The current
list in mkimage does not have a zero-filled structure at the end, which
can cause getopt_long() to walk past the end of the array when passing
an unknown option, causing a segmentation fault.

As a reproducer, the following command causes a segmentation fault
(tested in Debian 12):

    mkimage --foobar

Signed-off-by: Carlos López <carlos.lopezr4096@gmail.com>
python: Use and refer to the venv module rather than virtualenv 2025-04-24T21:37:27+00:00 Tom Rini trini@konsulko.com 2025-04-15T18:10:26+00:00 efd00b03455644b18eaf2b6dcd07f6d55b95b39e Using some form of sandbox with Python modules is a long standing best practice with the language. There are a number of ways to have a Python sandbox be created. At this point in time, it seems the Python community is moving towards using the "venv" module provided with Python rather than a separate tool. To match that we make the following changes: - Refer to a "Python sandbox" rather than virtualenv in comments, etc. - Install the python3-venv module in our container and not virtualenv. - In our CI files, invoke "python -m venv" rather than "virtualenv". - In documentation, tell users to install python3-venv and not virtualenv. Signed-off-by: Tom Rini <trini@konsulko.com> 
Using some form of sandbox with Python modules is a long standing best
practice with the language. There are a number of ways to have a Python
sandbox be created. At this point in time, it seems the Python community
is moving towards using the "venv" module provided with Python rather
than a separate tool. To match that we make the following changes:

- Refer to a "Python sandbox" rather than virtualenv in comments, etc.
- Install the python3-venv module in our container and not virtualenv.
- In our CI files, invoke "python -m venv" rather than "virtualenv".
- In documentation, tell users to install python3-venv and not
  virtualenv.

Signed-off-by: Tom Rini <trini@konsulko.com>
rockchip: mkimage: Add rk3576 support 2025-04-23T14:12:05+00:00 Xuhui Lin xuhui.lin@rock-chips.com 2025-04-15T21:51:15+00:00 ec8c6fb0a66180258d1e1a724f774a5334685c02 Add support for rk3576 package header in mkimage tool. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> 
Add support for rk3576 package header in mkimage tool.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rockchip: mkimage: Add support for RK3528 2025-04-23T14:12:04+00:00 Yifeng Zhao yifeng.zhao@rock-chips.com 2025-04-07T22:46:47+00:00 68424ac83a876c1222121dedf564cd39551c67aa Add support for generating Rockchip Boot Image for RK3528. Similar to RK3568, the RK3528 has 64 KiB SRAM and 4 KiB of it is reserved for BootROM. Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> 
Add support for generating Rockchip Boot Image for RK3528.

Similar to RK3568, the RK3528 has 64 KiB SRAM and 4 KiB of it is
reserved for BootROM.

Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
buildman: Update to grabbing gcc-14.2.0 toolchains by default 2025-04-15T17:55:17+00:00 Tom Rini trini@konsulko.com 2025-04-11T17:04:06+00:00 05a2b6984159e83d91420af283dd204bdbe07d65 With the switch to using GCC 14.2.0 in commit 001bac5f16ad ("Dockerfile: Update to gcc-14.2.0 and clang-18") in CI, we should make buildman match this. Signed-off-by: Tom Rini <trini@konsulko.com> 
With the switch to using GCC 14.2.0 in commit 001bac5f16ad ("Dockerfile:
Update to gcc-14.2.0 and clang-18") in CI, we should make buildman match
this.

Signed-off-by: Tom Rini <trini@konsulko.com>
Merge patch series "binman: Check code-coverage requirements" 2025-04-11T22:47:29+00:00 Tom Rini trini@konsulko.com 2025-04-11T20:32:02+00:00 a40fc5afaec079ee4e621965fed18dcc94240d8c Simon Glass <sjg@chromium.org> says: This series adds a cover-coverage check to CI for Binman. The iMX8 tests are still not completed, so a work-around is included for those. A few fixes are included for some other problems. Link: https://lore.kernel.org/r/20250410124333.843527-1-sjg@chromium.org 
Simon Glass <sjg@chromium.org> says:

This series adds a cover-coverage check to CI for Binman. The iMX8 tests
are still not completed, so a work-around is included for those.

A few fixes are included for some other problems.

Link: https://lore.kernel.org/r/20250410124333.843527-1-sjg@chromium.org