This also incorporates the following commits to the Dockerfile:
da7942de29f7 Dockerfile: remove Python 2.7
183299d9a400 docker: add OP-TEE and TF-A build for testing Firmware Handoff

Signed-off-by: Tom Rini <trini@konsulko.com>

We don't use Python 2 anywhere. Remove the package from our Docker image.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Fetch OP-TEE (4.7.0), TF-A (v2.13.0), MbedTLS (v3.6) and build
bl1 and fip with both Firmware Handoff and Measured Boot enabled.

Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

- Update to Ubuntu "Jammy" 20250714 tag
- Update to current Dockerfile which brings us QEMU 10.0.2 and newer
  coreboot and pulls in lz4 via the non-legacy package name.

Signed-off-by: Tom Rini <trini@konsulko.com>

At this point there's problems rebuilding coreboot-24.08 without manual
intervention. Let us upgrade to a newer version.

Signed-off-by: Tom Rini <trini@konsulko.com>

As QEMU 10.0.2 is the current release, update to that so that we can
update other features within CI.

Signed-off-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>

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>

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>

- Bump up "Jammy" tag to jammy-20250404
- Include most recent changes to the Dockerfile itself

Signed-off-by: Tom Rini <trini@konsulko.com>