As pointed out here [1], the expected M5OP_ADDR for arm64 arch
is 0x10010000. This change reflects that.
[1] https://github.com/gem5/gem5/pull/725
Change-Id: I7e72f5ea20d4aacf3115a485ba7cd664d33d037e
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
A set of cpt_upgraders was patching old checkpoints regardless
of the ISA in use. Thanks to the previous patch, we can now
retrieve the ISA of the CPU from the isa section.
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Ia110068c06453796cefac028ee13f21667e5371a
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
The original version of `list_changes.py` assumed no more than one
`Change-Id` tag per commit. However, since transitioning to GitHub, the
repository now contains some merge commits containing multiple
`Change-Id`s.
This patch updates `list_changes.py` to support commits with any number
of `Change-Id` tags.
We were having some difficulty on a server running this
`apt-apt-repository` command due to suspected firewall issues. On
further inspection is appear to be superfluous as git can be obtained
easily through `apt-get` without adding this repository.
This removes the gfx803 and gfx801 targets for building applications as
GCN3 will be removed from gem5. It also removes the copy/paste bug from
the HACC docker which is clobbering the HCC targets and removing gfx902.
Change-Id: I9a0d7fda437e797baf0f743a0a450948b9260b07
Co-authored-by: Harshil Patel <hpppatel@ucdavis.edu>
Related to issue #703 , this PR removes GCN3 related files and updates
source code, documentation, and tests to switch over to Vega is that was
not done already. Highlights are:
- Remove all src/arch/amdgpu/gcn3 files and update Kconfigs.
- Remove references to GCN3 and replace with Vega where applicable.
- Update the build targets in the gcn-gpu Docker. This will need to be
rebuilt but not urgently.
- Remove the GCN3 tag in testlib. Most tests seem to be using Vega
already, so that commit is small.
- This script copies all resources from a mongodb database locally The
script creates a resources.json and downloads all the resources. It also
updates the resources.json to point to these local downloads instead of
the cloud bucket.
Change-Id: I15480c4ba82bbf245425205c9c1ab7c0f3501cc3
DRAMSys requires cmake 3.24 or greater. By default neither Ubuntu 22.04
or 20.04 delevery this by APT.
In both cases wget is required. In 20.04 OpenSSL is required.
Then ext/dramsys README file has been updated to state this requirement.
DRAMSys requires cmake 3.24 or greater. By default neither Ubuntu 22.04
or 20.04 delevery this by APT.
In both cases wget is required. In 20.04 OpenSSL is required.
Change-Id: I51a7f8a8a46e8cf1908a120adb9289aa3907ccda
'cmake' is required to build DRAMSysm.
This is an optional dependency for compiling DRAMSys. It is therefore
not required. It is included in the "all-dependencies" Docker images
as they may be needed if DRAMSys is desired.
Change-Id: I1a3e1a6fa2da4d0116d423e9267d4d3095000d4e
This dockerfile is used to *build* applications (e.g., from
gem5-resources) which can be run using full system mode in a GPU build.
The next releases disk image will use ROCm 5.4.2, therefore bump the
version from 4.2 to that version.
Again this is used to *build* input applications only and is not needed
to run or compile gem5 with GPUFS. For example:
$ docker build -t rocm54-build .
/some/gem5-resources/src/gpu/lulesh$ docker run --rm -u $UID:$GID -v \
${PWD}:${PWD} -w ${PWD} rocm54-build make
Change-Id: If169c8d433afb3044f9b88e883ff3bb2f4bc70d2
The decode_inst_dep_trace.py opens the trace file in read mode, and
subsequently reads the magic number from the trace file. Once the number
is read, it is compared against the string 'gem5' without decoding it
first. This causes the comparison to fail.
The fix addresses this by calling the decode() routine on the output of
the read() call. Please find the details in the associated issue #543
Unfortunately Actions uses docker contaienrs to create files on the
system with root permissions. The 'vagrant' user which we login to run
the Actions Runner, can't remove these files. However, 'vagrant' is part
of the sudo group and can therefore use sudo to remove these files.
I don't like this, but it works.
At this moment, VLEN and ELEN RVV parameters are set as constants that
need to be modified at compile time if you want to experiment with
different values. With this patch, I want to set a first point to
discuss how to configure these parameters dynamically.
Also, I have modified some data types that were provoking wrong
behaviour in particular instructions when using a large enough VLEN
value in the considered range inside the specification.
This PR aims to enhance our Docker image build and registry management
by implementing multi-platform support and migrating from the Google
Docker registry to the GitHub Container Registry. Issue:
[#336](https://github.com/gem5/gem5/issues/336)
This patch:
1. Adds setup scripting to "provision_root.sh" to setup and enable KVM,
for the 'vagrant' user, for VMs which are capable of this.
2. Runs a check on each VM to see if KVM can be run sucessfully within a
docker container. If so, the GitHub Actions runner is given a 'kvm'
label. It is unknown at this time if GitHub Runners can utlized KVM
but it is open to their processes.
Change-Id: Idfcbb7bfa3e5b7cc47d29aea50fb1ebcafdb7acc
Without `--all` `docker prune --force --volumes` will remove everything
exception non-dangling images. For an image to be considered dangling it
must be untagged and/or not used by a container at that time. As most of
the images we download are tagged (e.g., `:latest`) then most of our
images are never removed without the inclusion of `--all` which will
remove any image not currently used by a container.
Images were starting to accumulate on runners. This will ensure they do
not and are cleaned after each job run.
Change-Id: I6d8441a11d22fdcf827e9c44422dbcf02cf600e0
THe `lvextend` command extends the logical volume. However, the
`resize2fs` command is needed to extend the filesystem to fill the
logical volume.
Prior to this patch the filesystem ran out of space despite there being
enough room in the volume. This was just wasted free space.
PR https://github.com/gem5/gem5/pull/396 updates the gem5 SST bridge to
use StandardMem in SST. This change updates the nightly tests to use SST
13.0.0 instead of SST 11.1.0. It also updates the dockerfile.
Change-Id: I5c109c40379d2f09601a1c9f19c51dd716c6582e
---------
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Co-authored-by: Bobby R. Bruce <bbruce@ucdavis.edu>
