First, thanks to Simon Glass and also Linaro, we now have access to a
few fast arm64 host machines in our Gitlab instance, to use as CI
runners. This series finishes the work that I pushed earlier and Simon
had started that enables arm64 hosts to be used for most things now.
The first notable change, especially if you use this on your own Gitlab
instance is that "DEFAULT_TAG" is now unused and we instead have:
- DEFAULT_ALL_TAG:
- DEFAULT_ARM64_TAG:
- DEFAULT_AMD64_TAG:
- DEFAULT_FAST_AMD64_TAG:
This lets us say that some jobs can be run on all runners, because they
are small enough that anything we'd connect to CI is fast enough and it
also does not depend on the underlying host architecture. Next we have
tags for any arm64 host, or any amd64 host. Finally, we have a tag for
fast amd64 hosts. What these last three are for is that we have a few
jobs that need to run on amd64 hosts and so we have to restrict them
there, but we also have now reworked the world build jobs to build
(almost) everything in a single job and on the fast amd64 machines this
is still as quick as the old way was, in practice.
To reach this point, we say that the Xtensa jobs can only run on amd64
hosts. Our targets only work with the binary-only toolchain and so this
is a reasonable limit and we exclude them from the world build jobs. We
also need to deal with ensuring the right toolchain is used regardless
what the host architecture is and that we don't use the host toolchain
by accident. Finally, because some of these changes needed to be worked
out in the linter, fix some of the general warnings that notes as well.
(cherry picked from commit 5947cd76ac)
Dropped tag changes:
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add tests that check that SPL can generate a standard passage on ARM and
that U-Boot proper can accept it successfully.
Series-change: 4
- Finish the commit message
Series-to: u-boot
Series-cc: ilias, heinrich, trini
Series-cc: François Ozog <francois.ozog@linaro.org>
Series-cc: Bill Mills <bill.mills@linaro.org>
Series-cc: Raymond Mao <raymond.mao@linaro.org>
Series-version: 5
Series-process-log: sort, uniq
Series-links: 3:453293
Cover-letter:
passage: Define a standard for firmware data flow
This series adds a standard way of passing information between different
firmware phases. This already exists in U-Boot at a very basic level, in
the form of a bloblist containing an spl_handoff structure, but the intent
here is to define something useful across projects.
The need for this is growing as firmware fragments into multiple binaries
each with its own purpose. Without any run-time connection, we must rely
on build-time settings which are brittle and painful to keep in sync.
This feature is named 'standard passage' since the name is more unique
than many others that could be chosen, it is a passage in the sense that
information is flowing from one place to another and it is standard,
because that is what we want to create.
The implementation is mostly a pointer to a bloblist in a register, with
an extra register to point to a devicetree, for more complex data. This
should cover all cases (small memory footprint as well as complex data
flow) and be easy enough to implement on all architectures.
The emphasis is on enabling open communcation between binaries, not
enabling passage of secret, undocumented data, although this is possible
in a private environment.
To try this out:
$ ./scripts/build-qemu -a arm -rsx
This will build and run QEMU for arm64 and you should see the standdard
passage working:
Core: 49 devices, 13 uclasses, devicetree: passage
This series is available at u-boot-dm/pass-working
END
Cover-changes: 2
- Rebase to master (dropping bloblist patches already applied)
Series-changes: 3
- Add tests for azure
- Add test for aarch64
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: I321f53b875ffb594a569796509e64830b9f3fe09
Now that the hooks are present, make use of them directly rather than
cloning the separate repo.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
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>
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>
Reviewed-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>
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.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
This add some basic functions to create images, and a test for said
functions. This is not intended to be a test of the image parsing
functions, but rather a framework for creating minimal images for testing
load methods. That said, it does do an OK job at finding bugs in the image
parsing directly.
Since we have two methods for loading/parsing FIT images, add LOAD_FIT_FULL
as a separate CI run.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that sandbox64 can run and pass the regular test.py suite, add it
here as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently, most sandbox runs take a long time (due to running so many
tests) while QEMu based test.py runs are fairly short. Split the
pipeline here so that we get more consistent average run times.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Both to aide in debugging of any test.py issues as well as to make it
easier to split the current matrix in two, have a new job that creates
and publishes the current wrapper script we use for test.py jobs.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- We have added more TODO/etc comments since this task was created and
never focused on removing them.
- The output of sloccount isn't preserved or looked at, and if desired
should be in the release stats pages instead somehow.
- The results of cppcheck aren't investigated and require modeling work
to be useful to start with.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These jobs are to confirm specific build targets, on a Linux host. We
can safely combine these two build tests, with a make mrproper in
between.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we have 3600 minutes per build job, condense and rework things
such that our overall time largely doesn't change, but we can also
largely avoid having to re-tweak this job to avoid timeouts. Given that
we have 10 threads, we also move a few of the specific sandbox test
builds to a prior stage.
Note that while sandbox builds with address sanitization enabled (ASAN)
not all tests pass, so we limit ourselves to just checking that the
version test passes for now.
Link: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This platform is behind on migrations (it is the sole user of the oldest
legacy version of the USB gadget stack and is long overdue for
migration) and with Pali no longer being a maintainer, we remove this
platform.
Signed-off-by: Tom Rini <trini@konsulko.com>
When running the trace test on the sandbox platform, the current size
of 16MiB is no longer large enough for capturing the entire trace
history, and results in truncation. Use a size of 32MiB for the trace
buffer on the sandbox platform while running the trace test.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
