Kuan-Wei Chiu <visitorckw@gmail.com> says:
Add support for the QEMU 'virt' machine on the m68k architecture. The
QEMU virt machine models a generic system utilizing Goldfish virtual
peripherals and is capable of emulating various classic 68k CPUs.
Currently, U-Boot's m68k architecture support focuses on ColdFire
variants. This series expands support to include the classic M680x0
architecture, implementing the necessary exception vectors, startup
code, and a bootinfo parser compatible with the QEMU interface.
Drivers for Goldfish peripherals (TTY, Timer, RTC) and the QEMU
Virtual System Controller (sysreset) are also added to enable serial
console, timekeeping, and system reset functionality.
The implementation has been verified on QEMU targeting the M68040 CPU,
confirming successful hardware initialization and boot to the U-Boot
command shell. Additionally, the CI configuration was verified locally
using gitlab-ci-local "qemu_m68k_virt test.py", resulting in
PASS qemu_m68k_virt test.py.
Link: https://lore.kernel.org/r/20260107201838.3448806-1-visitorckw@gmail.com
[trini: Re-sort MAINTAINERS entries]
Signed-off-by: Tom Rini <trini@konsulko.com>
Enable CI testing for the newly introduced QEMU m68k 'virt' board on
both GitLab CI and Azure Pipelines. This ensures the new M68040
architecture support is built and booted correctly in the emulated
environment.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Greg Malysa <malysagreg@gmail.com> says:
This series adds the final pieces to enable mainline U-Boot to build and
boot all Analog Devices SC5xx SoCs and supports the associated carrier
board options. At this point it should be viable for new users for these
platforms to start with the latest version of U-Boot rather than our
vendor fork, however some features (such as OSPI support and falcon
boot) remain unavailable until we are able to unify our implementations
with the mainline implementations.
Link: https://lore.kernel.org/r/20251211080414.5363-1-malysagreg@gmail.com
[trini: Rebuild CI containers to have new tools]
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we can have "make allyesconfig" build and link, add this type
of build to the job which builds host tools as well. In GitLab, make
this job rather than binman testsuite be the job which unblocks the next
stage of the pipeline. This is because we had been using that job for
"sandbox builds", and now that we have an explicit test for that, we
should use it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Semihosting allows a virtual machine to write to the host file system.
Such dangerous settings should not be in a defconfig.
Move it to a CI configuration override.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
- Bump to noble-20251013
- Include tools for sage lab, build TF-A for platforms there.
- Switch to distro provided trace-cmd, add libengine-pkcs11-openssl
- Use mirrors for GNU projects
- Switch to QEMU 10.1.x
Signed-off-by: Tom Rini <trini@konsulko.com>
This series adds support for Gitlab pipelines to run our pytest suite on
a limited number of hardware platforms. While better documentation and
some further enhancements will be coming soon, this can be triggered by
passing '-o ci.variable="SAGE_LAB=1"' to git push, or adding
'pushOption = ci.variable="SAGE_LAB=1"' to the .git/config file for the
project. It can also be invoked manually from the pipeline webpage on a
an existing pipeline.
Link: https://lore.kernel.org/r/20251118210015.624758-1-trini@konsulko.com
This is the Gitlab side of adding support for the board lab connected to
the "konsulko-sage" runner. On the software side, this lab uses only
upstream labgrid. On the hardware side, each device under test is
connected to its own exporter (typically a Raspberry Pi 4) that must be
turned on (and cleanly turned off) as part of a given test cycle.
Add support for testing on a SolidRun Hummingboard 2 (imx6), Raspberry
Pi 3 and Raspberry Pi 4. In all cases, we enable additional options to
run more tests on the board. As we have some networking tests, we test
both the legacy network stack and lwIP. In the case of Pi platforms, we
test all of 32bit configuration, plain configuration and rpi_arm64, and
again with and without lwIP.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Move to jammy-20251013 tag
- Bring in tkinter so that FATtools should run and more tests should be
run.
- Update to QEMU 10.0.6
- Pick tags for (most of) trace-cmd
Signed-off-by: Tom Rini <trini@konsulko.com>
QEMU comes with its own OpenSBI. For running RISC-V virtual machine
using one of qemu-riscv64_smode_defconfig or
qemu-riscv64_smode_acpi_defconfig is the natural choice.
Add the riscv64 smode configurations to the test scope.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In general, we want to fail the whole pipeline as soon as we can if we
spot an error while also letting bigger jobs get started as soon as
possible. Currently we use the "Run binman, buildman, dtoc, Kconfig and
patman testsuites" job from the testsuite stage to unblock the next
stage as this test is complex enough that if it passes, likely the whole
stager will pass. Using this same logic, unblock the world build (and
sjg-lab) stages if "sandbox test.py" has completed as if there's no
failures here, there's likely not failures in the rest of the test.py
stages.
Signed-off-by: Tom Rini <trini@konsulko.com>
The changes here are that we need to ensure python setuptools are
in our build virtual environments as they will no longer come in via
python even in a virtual environment. As part of this ensure setuptools
is in our cache and also include pytest-azurepipelines as we should have
been doing. Next, we move away from using apt-key directly and move that
stanza towards the rest of the apt work. This also lets us drop
directly installing gnupg2. These steps are not strictly required for
24.04 but will be for later releases and are valid now. Finally, we drop
the unused PTYHONPATH ENV line.
In order to use these containers however, we need to stop running the
event_dump test as the 'addr2line' tool provided by binutils no longer
is able to decode those specific events in most cases. As this is a
problem with binutils and present for some time now, disabling the test
until someone has time to work with upstream this seems reasonable.
Signed-off-by: Tom Rini <trini@konsulko.com>
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we've had jobs running on both amd64 and arm64 hosts for a
while, we have enough data to look at usage and findings. For the world
build job, make use of the new DEFAULT_FAST_TAG and only build it once,
on either amd64 or arm64 as we don't run in to host specific results
there. For sandbox, continue to build on both arm64 and amd64 hosts as
we can find host specific breakage that way. Remove the mistaken
restriction on sandbox64_lwip.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we have a test for QEMU using transfer list from the previous
stage, there are two platforms testing this particular infrastructure. A
problem with the vexpress_fvp platform emulation in Gitlab is that we
often run it on hosts that are fast enough that we run in to a race
condition when trying to acquire the console and the test fails. Remove
both vexpress_fvp tests from Gitlab (they can remain in Azure) to remove
these spurious failures.
Signed-off-by: Tom Rini <trini@konsulko.com>
This also incorporates the following commits to the Dockerfile:
da7942de29 Dockerfile: remove Python 2.7
183299d9a4 docker: add OP-TEE and TF-A build for testing Firmware Handoff
Signed-off-by: Tom Rini <trini@konsulko.com>
Add qemu_arm64_tfa_fw_handoff test entries to azure and gitlab
pipelines.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Check the existence of bl1 and fip from:
1. /opt/tf-a/${board_type}_${board_ident}, if not exist, then;
2. /opt/tf-a/${board_type}
This change allows to test with TF-A with specified board ID only.
Signed-off-by: Raymond Mao <raymond.mao@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>
Changes in upstream QEMU have lead to this specific configuration of the
sifive_unleashed platform not working in QEMU. Until this can be
root caused and resolved, disable this test for now.
Link: https://gitlab.com/qemu-project/qemu/-/issues/2945
Signed-off-by: Tom Rini <trini@konsulko.com>
With a test investigation of how long each of our current build machines
can take to run the sandbox test.py job, we can see that the longest
running hosts are any of the arm64 machines. In some cases this may be a
matter of overall system load, but in others it's hard to say. The
challenge with these tests is that the run itself is single threaded and
covers a large number of tests. There may be gains made in looking in to
optimizing some individual tests. For now however we will likely gain
the most by removing potential bottle necks here and allow any amd64 or
arm64 host to run the test instead of trying to ensure they only run on
one of the few "fast" machines.
Link: https://source.denx.de/u-boot/u-boot/-/pipelines/26533/test_report
Signed-off-by: Tom Rini <trini@konsulko.com>
Adriano Cordova <adrianox@gmail.com> says:
Enable HTTP server in CI to support HTTP tests in pytest
QEMU does not emulate an HTTP server, unlike other services like DHCP or TFTP.
To enable HTTP tests during CI runs, start a simple Python HTTP server
on port 80. This allows tests that require HTTP access to run.
The HTTP server is launched on the host. For QEMU environments launched
with '-netdev,user' this means that the HTTP server runs together with DHCP
at 10.0.2.2. HTTP testing needs to be explicitly enabled with
env__efi_helloworld_net_http_test_skip = False.
We also default `WGET=y` in `ARCH_QEMU` configurations so that these HTTP
tests are included automatically when using QEMU in CI.
Link: https://lore.kernel.org/r/20250516085256.30386-1-adriano.cordova@canonical.com
There are a few differences between how the test.py stage invokes
test.py and how the sjg-lab stage invokes test.py. As a start of making
both the code and the output and artifacts similar, this updates the
sjg-lab stage with the following:
- Pass "-ra" so that we get the summary information in the job
- Make use of TEST_PY_EXTRA for passing "--capture=tee-sys"
- Re-order some of the arguments to be the same order when possible.
And most importantly:
- Create and save as an artifact the junitxml output.
The last part here is the kind of test result information that in the
future we should determine how to archive for future reference.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
As noted by Quentin, in CI we should be at least versioning the pytest
that we install. To avoid problems later, go with the whole requirements
file being used. Furthermore, our documentation building for readthedocs
must also have pytest so install the requirements file there as well.
Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to easily document pytests, we need to include the autodoc
extension. We also need to make sure that for building the docs, CI
includes pytest and that we have PYTHONPATH configured such that it will
find all of the tests and related files. Finally, we need to have our
comments in the test file by in proper pydoc format in order to be
included in the output.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Binman includes a good set of tests covering all of its functionality.
This includes a code-coverage test.
However to date the code-coverage test has not been checked
automatically by CI, relying on people to run 'binman test -T'
themselves.
Plug the gap to avoid bugs creeping in future.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The CI image does not ship with all tools required for the binman tests.
Have binman build the missing tools.
Signed-off-by: Leonard Anderweit <l.anderweit@phytec.de>
Outside of changing versions here the other visible change is that we
tell grub that riscv64 does not have "large model" support. Without this
change the resulting mkimage is non-functional. This is known upstream
already.
Link: https://savannah.gnu.org/bugs/?65909
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently, this platform is failing in CI due to seemingly platform
specific reasons. For now, remove it from CI until the maintainers have
a chance to look in to it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that U-Boot can boot this quickly, using kvm, add a test that the
installer starts up correctly.
Use the qemu-x86_64 board in the SJG lab.
Signed-off-by: Simon Glass <sjg@chromium.org>
When adding the symlink for the conf file so qemu_arm64_lwip uses
qemu_arm64 configuration information, the symlink for the boardenv file
was missed in Gitlab (but not Azure). Add that in now.
Fixes: fd10d156db ("CI: add qemu_arm64_lwip to the test matrix")
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini <trini@konsulko.com> says:
A challenge we've run in to is making it easier for more people to use
various python tools that we include in the tree. Part of the problem is
that when we have a requirements.txt file, aside from the doc one we
share with the kernel, I created it using "pip freeze". And while this
might have been a best (or at least OK) practice at the time, that's no
longer the case and is why our files have so many things in them. What
this series does is create multiple files, one per project/tool and then
has CI install them as needed. There's a few places here where this
means that we update the requirements as well, but we keep a few big
things where they are currently. This is because updating them
introduces problems of their own and delaing with that would best be a
follow up series. I've put this through GitLab and Azure to make sure
everything is still going fine on both platforms.
Link: https://lore.kernel.org/r/20250205000743.949790-1-trini@konsulko.com
We can invoke pip once to install the various requirements.txt files
that we need rather than invoking the tool multiple times.
Signed-off-by: Tom Rini <trini@konsulko.com>
We should install all of our requirements.txt files after starting the
virtualenv rather than ad-hoc throughout each test.
Signed-off-by: Tom Rini <trini@konsulko.com>
Before we invoke pip we should always have first created and started our
virtualenv. This was done most of the time, but not always.
Signed-off-by: Tom Rini <trini@konsulko.com>
