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>
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>
Without setting the shell flag to exit immediately when a command exists
with a non-zero status we can have the situation where the htmldocs
target fails with an error but the job will succeed due to infodocs
passing and being the last build target.
Signed-off-by: Tom Rini <trini@konsulko.com>
Execution time varies widely with the existing tests. Provides a way to
produce a summary of the time taken for each test, along with a
histogram.
This is enabled with the --timing flag.
Enable it for sandbox in CI.
Example:
Duration : Number of tests
======== : ========================================
<1ms : 1
<8ms : 1
<20ms : # 20
<30ms : ######## 127
<50ms : ######################################## 582
<75ms : ####### 102
<100ms : ## 39
<200ms : ##### 86
<300ms : # 29
<500ms : ## 42
<750ms : # 16
<1.0s : # 15
<2.0s : # 23
<3.0s : 13
<5.0s : 9
<7.5s : 1
<10.0s : 6
<20.0s : 12
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \
-device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function
dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL)
relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 in the CI until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini <trini@konsulko.com> says:
Hey all,
This is picking up Simon's v5 of the above-named series and making a few
more changes so that the follow-up series I have leads to arm64 being
supported for almost all jobs. To quote Simon's cover letter:
All gitlab runners are currently amd64 machines. This series attempts to
create a docker image which can also support arm64 so that sandbox tests
can be run on it.
The TARGET_... environment variables for grub could perhaps be adjusted,
using the new variables, but I have not done that for now.
Adding to what Simon said, we now build grub for all architectures as
the reason to install it was to be able to use the binaries in QEMU.
That won't provide us with amd64 binaries on arm64 hosts so we can't use
that shortcut anymore.
Link: https://lore.kernel.org/r/20241127172247.1488685-1-trini@konsulko.com
For consistency now, and future ease of testing with non-amd64 hosts,
build grub for all architectures rather than relying on host binaries
for i386/x86_64.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
Add QEMU's SBSA ref board to azure pipelines and gitlab CI to run tests on it.
TEST: Run on Azure pipelines and confirmed that tests succeed.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Soon Azure will be removing the macOS-12 container in following their
normal support schedule. Move us to macOS-14 so we won't have problems
there for a while. At the same time, our Windows container is the oldest
supported, so move to the newer option. Finally, Ubuntu 22.04 is the
middle option currently, but 24.04 should be fine.
Link: https://github.com/actions/runner-images/issues/10721
Signed-off-by: Tom Rini <trini@konsulko.com>
Build and run qemu_arm64_lwip_defconfig in CI. This tests the lightweight
IP (lwIP) implementation of the dhcp, tftpboot and ping commands.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
When we have platforms being emulated by QEMU we cannot rely on the
"sleep" command running for the expected wall-clock amount of time. Even
with our current allowance for deviation from expected time, it will
still fail from time to time. Exclude the sleep test here.
Signed-off-by: Tom Rini <trini@konsulko.com>
Jiaxun Yang <jiaxun.yang@flygoat.com> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.
Thanks
[1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
Both GitLab and Azure (and other CI systems) have native support for
displaying JUnitXML test report results. The pytest framework that we
use can generate these reports. Change our CI tests so that they will
generate these reports and then have the respective CI platform pick
them up. We write to different locations because of where each CI is
(and isn't) able to easily pass things along.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we have each stage of the world build using variables to define
what it will attempt to build, and that we have added in missing
machines, add a job to make sure that we would always be building
everything.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of commit 9aeac898da ("Azure: Rework build the world jobs") I
made a few mistakes. An errant '_' meant that we built neither at91 nor
kirkwood platforms. Further, the non-freescale (NXP) "LS1xxx" platforms
were also not being built. Adjust some jobs to have these be built
again.
Fixes: 9aeac898da ("Azure: Rework build the world jobs")
Signed-off-by: Tom Rini <trini@konsulko.com>
In order to get the list of boards that will be done in a "dry run"
build we need to have something listed and not just an exclude list.
Populate the job with all architecture directories except arm and
powerpc.
Signed-off-by: Tom Rini <trini@konsulko.com>
Instead of defining BUILDMAN to the value we'll build in each part of
the matrix job, define a variable with that name and have it list what
to build. This will allow us to reference these multiple times
consistently later on.
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point noting that we have a split in our job similar to TravisCI
(which we have not used in years) isn't helpful, and is also not true
anymore either. Instead, explain that we split the world up in to 10
jobs as that's the maximum we can have going in parallel on the free
tier of Azure.
Signed-off-by: Tom Rini <trini@konsulko.com>
Instead of downloading coreboot binaries from a Google drive location,
use the ones we have built ourselves.
Signed-off-by: Tom Rini <trini@konsulko.com>
The primary motivation for having a sandbox without LTO build in CI is
to ensure that we don't have that option break. We now have the ability
to run tests of specific options being enabled/disabled, so drop the
parts of CI that build and test that configuration specifically and add
a build test instead. We still test that "NO_LTO=1" rather than editing
the config file works via the ftrace tests.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
At this point we have all of the defconfigs maintained again, so
re-enable the check to prevent further regressions.
Signed-off-by: Tom Rini <trini@konsulko.com>