The 'components_library' name was always a placeholder. A more accurate
name would be the 'gem5 library'. This is analogous to standard
libraries shipped as part of programming languages. Over time this will
begin to incorporate more commonly used code at the Python configuration
script level. Most of the former 'components_library' is now in
'gem5.components'.
Change-Id: I5927db7004c43b29c39e7767da3f779627081618
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49691
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some debate on how best to distribute the components
library. This change builds the components library into the gem5 binary.
The components library will now function similar to the `m5` library.
There is no need for awkward imports or obtaining the library from some
third-party source.
Additional incorporated in this patch:
* Added `__init__.py` to the Python modules.
* Fixed a typo in the `abstract_ruby_cache_hierarchy.py` filename.
* Ensured that imports within the library are relative.
Issue-on: https://gem5.atlassian.net/browse/GEM5-1023
Change-Id: I3988c8710cda8dcf7b21109a2cf5c3f1608cc71a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49690
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously these scripts were in `configs/example/components-library`
though they are now used purely for testing purposes and have therefore
been moved to `tests/gem5/configs/example/components-library`.
There should be example scripts for usage of the components library, but
these scripts are no longer suitable since being made more flexible for
the purposes of testing.
Change-Id: I7c4d5bb86fe94898f006220dd962841344b1868e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49558
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The Learning gem5 part 3 tests require the building of the X86_MSI
binary. These are the only tests that require this protocol. Building
this is not worth it to just run these tests. They've therefore been
moved to be run nightly rather than as a pre-submit/kokoro test.
Change-Id: If0cdd9c30a160a01cef5fcda8a5433ab2d6ac882
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50027
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change makes three improvements:
1. It uses the gem5 components library
`config/example/components-library/boot_exit_disk_run.py` example. This
test therefore doubles-up as a test for this example and the gem5
components library, as well as full-system x86 booting of Linux.
2. It includes 'very-long' tests to be run weekly. These are a full
cross-product of x86 boot tests and will help identify gem5 failures
more quickly.
3. Quick tests are added to boot the linux OS to a certain tick.
Change-Id: Ie52c267f3382e37912b8ae41dc92b1ee8d06f9f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49325
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
As unittest.TextTestRunner().run(suite) doesn't exit the script,
it won't set the exit code, even when some tests are failing.
This means testlib is always interpreting those unittests as passing
even when there are failures.
With this patch we are propagating the error to our CI system (testlib)
Change-Id: I63b7622661a19a9b40243d13b7391e510c2007d4
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48969
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This script previously existed entirely within our Jenkins instance.
However, in the interests of transparancy, and allowing users to run the
Nightly tests on their own machines, this script should be added to the
repo. This also allows the community to change the nightly tests without
contacting the Jenkins' administrators.
Change-Id: I6cc3d7597776dbdeb9efb31766d579a2be733d68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46520
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is patch is in regard to issues discussed here:
https://www.mail-archive.com/gem5-dev@gem5.org/msg39122.html
The aim of this patch is to set a potential fix, and to give more
valuable debugging information.
It is not known why Kokoro sometimes fails, but it may be due to the
Docker service not starting fully prior to execution of the tests
within a Docker container. As such a 2 second sleep has been added
between starting the Docker service and running the tests.
The pulling of the docker images has been separated out to run at the
start of testing. This should help us determine whether the issue lays
with the pulling of an image or the running of a container.
The bash debug flag `-x` has been set so the expansion of each line can
be determined upon the event of a failure.
This patch will be reverted if it is found to not solve the issue.
Change-Id: I0d2dd8a080f64296e55f4b6de9a036d94d19c8ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45999
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This adds 64-bit statically linked big and little endian
binaries for the hello test program.
It should be noted that all possible combinations of ABI
version and endianness are possible for 64-bit binaries.
However, standard toolchains always use ELF ABI v1 for
big endian and ELF ABI v2 for little endian binaries.
Change-Id: I2dca7eaa2b04a7b68b117ada799d4c3bb69368be
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40951
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Commit a440108cc ("tests: Add Makefiles for hello")
introduced Makefiles for building the hello test binary
for ARM and x86 using dockcross. Since dockcross also
provides an image with a 64-bit little endian toolchain
for Power, this adds a Makefile for building the hello
binary.
As of this moment, 64-bit little endian (ppc64le) is the
prevalent variant supported by most distributions. Hence,
we are currently limited to only building the binary for
this variant.
Change-Id: Ic20322ca33c69634d9f17d30b29e522cc35742fb
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40949
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Previously the pyunit tests needed run in the gem5 root, this change
allows them to run as part of the quick TestLib tests (thereby having
them run as part of the presubmit checks). This runs all the TestLib
tests as a single test using the NULL gem5 binary.
`tests/run_pyunit.py` has been updated to only parse files with the
`pyunit` prefix in their filname. As such `pyunit/util/test_convert.py`
has been renamed `pyunit/util/pyunit_convert_check.py`. The word `test`
has been removed entirely as to not clash with the testlib tests as run
by `tests/main.py`.
Example usage:
```
./main.py run --uid SuiteUID:tests/pyunit/test_run.py:pyunit-tests-NULL-x86_64-opt
```
Discussed briefly in email thread:
https://www.mail-archive.com/gem5-dev@gem5.org/msg38563.html
Change-Id: Id566d44fcb5d8c599eb1a90bca56793158a201e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44625
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
dev/ has unit tests, but they are not run when
using the NULL ISA. The currently existing tests
are not ISA-specific, so the tests were set to
be run at an ARM environment.
As of now this is enough, but when ISA-specific
tests from ISAs other than ARM are added one will
need to change to cover them too.
Change-Id: I18df0141d415286325463afa759459b04ac8a92f
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44367
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
We have seen cases where the primary CPU was not able to bootstrap the
secondary CPUs in multicore tests (dual). The Linux booting process
"quietly" gives up (no panic) and it completes the booting without
bringing up the seondary CPU(s). This makes the dual test useless as it
is supposed to test SMP setups.
By adding a MatchFileRegex verifier, we make sure we are able to catch
these cases, correctly raising an error if not all CPUs are available.
We do this by inspecting the kernel log for the following print:
"CPU1: Booted secondary processor"
There are probably more resilient alternatives to a regex based check,
but those require a less minimal rootfs (the current
m5_exit.squashfs.arm64 FS has a single /sbin/init binary executing a
simple m5 exit operation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I37e0882967443449d5fedfe3963bd25528a030f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44446
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This vestigial device provides a thin layer of indirection between
devices and the CPUs in a system. It's basically a collection of helper
functions, but since it's a SimObject it needs to be instantiated in
python and added to configurations.
Change-Id: I029d2314ae0bb890678e1e68dafcdab4bfe49beb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43347
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
