The revamp of the GenericTimer was not taking into account:
* The name of the variable will be printed on the checkpoint to label the
data. It is not possible to use different variable names when
serializing/unserializing, and it is not possible to use the same
temporary variable to serialize/unserialize different values.
* the serializeSection is creating a new sub section in the
checkpoint. Doing the following:
void
GenericTimerFrame::serialize(CheckpointOut &cp) const
{
physTimer.serializeSection(cp, "phys_timer");
virtTimer.serializeSection(cp, "virt_timer");
SERIALIZE_SCALAR(accessBits);
}
will serialize the accessBits under the virt_timer subsection
rather than the parent generic_timer_frame.
JIRA: https://gem5.atlassian.net/projects/GEM5/issues/GEM5-426
Change-Id: I7676309965a33156789d2ef13e966c7a4ad88a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27708
Tested-by: kokoro <noreply+kokoro@google.com>
These are currently specific to aarch64, but will be expanded to cover
all other versions of the utility as well.
The intention of these new files is to centralize the build mechanism
for the different versions of the utility so that they have consistent
features, mechanisms, and targets, and so that new features will
automatically be shared by all versions without having to be implemented
in each.
This also sets up a separate build directory which will keep the source
tree clean, and will (with some more development) make it possible to
build multiple versions of the m5 utility at the same time without them
running into each other.
Change-Id: I10018eef6beb4af30a8d3bbab8b82cabd2b3f22c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27213
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Faults in the TLB ought to cause a page walk. Force that by removing
the fixup in X86 TLB.
This fixes rare race conditions where a timing page walk is
intercepted by a TLB miss which fixes up the fault resulting in
double calls to allocateMem in Process class.
Change-Id: Iaef4d636cd2997144d8bc5012cd7c2a0a97102e5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27507
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This change includes:
1) Verify available command bandwidth
2) Add support for multi-cycle commands
3) Add new timing parameters
4) Add ability to interleave bursts
5) Add LPDDR5 configurations
The DRAM controller historically does not verify contention on the
command bus and if there is adaquate command bandwidth to issue a
new command. As memory technologies evolve, multiple cycles are becoming
a requirement for some commands. Depending on the burst length, this
can stress the command bandwidth. A check was added to verify command
issue does not exceed a maximum value within a defined window. The
default window is a burst, with the maximum value defined based on the
burst length and media clocking characteristics. When the command bandwidth
is exceeded, commands will be shifted to subsequent burst windows.
Added support for multi-cycle commands, specifically Activate, which
requires a larger address width as capacities grow. Additionally,
added support for multi-cycle Read / Write bursts for low power
DRAM cases in which additional CLK synchronization may be required
to run at higher speeds.
To support emerging memories, added the following new timing parameters.
1) tPPD -- Precharge-to-Precharge delay
2) tAAD -- Max delay between Activate-1 and Activate-2 commands
I/O data rates are continuing to increase for DRAM but the core frequency
is still fairly stagnant for many technologies. As we increase the burst
length, either the core prefetch needs to increase (for a seamless burst)
or the burst will be transferred with gaps on the data bus. To support
the latter case, added the ability to interleave 2 bursts across bank
groups.
Using the changes above, added an initial set of LPDDR5 configurations.
Change-Id: I1b14fed221350e6e403f7cbf089fe6c7f033c181
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26236
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A new VExpress_GEM5_Foundation platform has been added in order to match
the FVP Armv8-A Foundation Platform described in:
Armv8-A Foundation Platform - User Guide - Version 11.8
The VExpress_GEM5_V1/V2 are already loosely based on the Foundation
platform, however there are some differences in the PCI regions (V1/V2)
and the GICv3 regions (V2).
We hence introduce the VExpress_GEM5_Foundation to match closely the
FVP Foundation Platform
Change-Id: I1604c64ce566308d888c3a630019494b9fae7acf
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27388
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
When accessing m5_mem and building PIC code, we need to get the address
of m5_mem out of the global offset table, and then load the value from
there. If we try to load from m5_mem directly, the assembled code has a
relocation type the linker can't handle when building a shared object.
Change-Id: Ieb19c3d17c37ef810559ee24b68886b18ddcc869
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27212
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Calls to queueMemoryRead and queueMemoryWrite do not consider the size
of the queue between ruby directories and DRAMCtrl which causes infinite
buffering in the queued port between the two. This adds a MessageBuffer
in between which uses enqueues in SLICC and is therefore size checked
before any SLICC transaction pushing to the buffer can occur, removing
the infinite buffering between the two.
Change-Id: Iedb9070844e4f6c8532a9c914d126105ec98d0bc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27427
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bradford Beckmann <brad.beckmann@amd.com>
The DictImporter's __del__ method calls unload, and that imports
sys.modules so that it can remove the modules that the DictImporter had
set up as the importer goes away.
Unfortunately, the importer only goes away when python is shutting down,
and at that time some aspects of the system, namely sys.meta_path, have
been cleaned up. When unload tries to import sys, that causes an
exception which scons/python reports but which doesn't do anything bad
otherwise.
In all of the examples of this older style of import object online, none
had a __del__ method, and none worried about cleaning up sys.modules
when they went away. In light of that, I've removed the __del__ method
entirely.
Another reason I think it's safe to remove __del__ is that the importer
was not actually being deleted even when it was removed from
sys.meta_path, and all the modules it had loaded where removed from
sys.modules. I think that was because the SimObject classes that it had
set up still had references (they are used later in the SConscript), and
those would, either directly or indirectly, refer back to the modules
and the importer. Those remaining references kept the importer alive,
preventing __del__ from being called before all those other objects were
cleaned up.
I think in python 2, the order things were cleaned up just so happened
to avoid trying to import sys when it was no longer possible, but in
python 3 that changed and resulted in this exception being thrown.
I've tried building gem5 with scons running under python 2 and python 3,
and with this change there is no error at shutdown. Both also produce a
gem5 binary which can run hello world without problems.
Change-Id: Ib1f5c7403df57fc420cec7ec0fef20a164a06991
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27247
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The header for the m5op entry points had moved. Also the names of the
entry points had been normalized to have a consistent structure. Neither
of those changes were ported to this file, making it no longer compile.
Change-Id: I890c0486bd19fe2692cce92983290e854dc87afa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27211
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Now that the annotation pseudo ops are removed, the subfunction is
always zero. It is no longer decoded within gem5 either. The format of
the pseudo op func/subfunc mechanism is unchanged for compatibility, but
the subfunc field will always be zero now.
Change-Id: I2167571577b6557d06aa26d8aecaca78797f5f59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27205
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
I switch between waiting and non-waiting scenario many times per day.
The BaseCPU.wait_for_remote_gdb attribute, introduced in c2baaab0ed,
makes it much less painful by saving many recompiles.
The present commit tries to go a bit further: the se.py script is
under version control, and changing it interferes with smooth git
workflow.
Change-Id: Ie65ffc44b11d78d5e7878f81f2fcdafa143c20a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27287
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This proxy was only used by the ARM semihosting interface which can now
use a tweaked regular TranslatingPortProxy or SETranslatingPortProxy
instead of this special purpose class.
This sort of class would still be necessary if you wanted to use
physical addresses and not virtual addresses, but presently there is no
such use. This code can be retrieved from history if it's needed in the
future.
Change-Id: Ie47a8b4bb173cba1a06bd3ca60391081987936b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26625
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
This is to match the FVP Foundation platform.
Priviledged software could query the SYS_ID register in the V2m
Motherboard controller to extract platform information:
https://
static.docs.arm.com/100961/1110/armv8_a_fp_ug_100961_1110_00_en.pdf
In particular:
* SYS_ID[31:28] (REV) = Revision Number
** Value = 0x3 -> FVP Foundation v9.6
* SYS_ID[27:16] (HBI) = Board Number
** Value = 0x010 -> FVP Foundation platform
* SYS_ID[15:12] (BLD) = Which variant of the GIC memory is implemented
in the model
** Value = 0x1 -> (!= legacy VE memory map)
* SYS_ID[11:8] (Arch) = Architecture
** Value = 0x1 -> Architectural model (FVP)
Change-Id: Ib9395eb872cb925c029077acfdd18e48478f779b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27184
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The bug(s) which prevented LTO and partial linking from working with gcc
have been fixed in my local version (9.3), and according to one of the
original bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
A fix was committed in gcc version 8.1.
The original code left in the SConstruct describing the problem with
versions greated than 6.0 also enabled an -flinker-output option and set
it to "rel". That option doesn't show up in the gcc 8.4 documentation
even though it was added in 6.0, but in the 9.3 documentation it
describes it and says that it defaults to "rel" when the -r (partial
linking) option is used.
This *should* mean that LTO and partial linking can be used together
with no issues after version 8.1, and at most by version 9.3. If someone
finds that that isn't true, then the range of bad versions can be
expanded.
Change-Id: Ie0529d077a0042ef55e2af995d01430d1695c031
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27131
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is in the range of call numbers set aside for extensions. When
called, it will extract the function to use from the first argument
slot. Then it calls the pseudoInst dispatching function using an ABI
which drops the return value (which is handled by semihosting itself)
and which extracts arguments from the remaining slots in the param
structure.
This makes gem5 pseudo ops available on CPU models which support
semihosting but not instruction based or address based "magic"
operations, aka hypercalls. This includes the fast model CPUs.
Change-Id: Ic4817f2b1e6aad7784af77a1a494cf614d4d4c6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When building gem5, it's possible for warnings printed early in the
build to be quickly wisked away in a see of compile lines, never to be
seen again (or driven off the end of the scrollback buffer).
To avoid those messages getting lost or ignored, this change adds a
mechanism to aggregate them into a list so that they can be summarized
at the end of the build, successful or not.
Change-Id: Ie13320717698fcbcd3a8f8d1c062467e8d6d2914
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27129
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Otherwise the error and warning messages get chopped off and wrapped by
the terminal wherever they happened to end. That's ugly and hard to
read.
This mechanism attempts to wrap the text using the console width which
it attempts to determine in two ways, first with shutil which should
work in python 3.3 and above, and then with the curses python module. If
neither of those works, it just falls back to 80 columns which is not
ideal but is reasonable.
Change-Id: I961936295505f93f5f36eb6d9cebc5073b5f793b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27128
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is another fix for the AArch32-AArch64 interprocessing issue
introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
Register mapping between AArch32 and AArch64 is explicitly defined in
ARMv8 manual. This allows software to read registers right after a state
switch without writing them first, and it is indeed common for software
to save registers to memory first before using them.
In gem5's implementation of vector mode switching, however, vectors may
not be marked as ready right after a state switch. Software reads toward
vectors at this time will stall O3CPU forever. This patch fixes this by
marking all mapped vectors (or vector elements, depending on AArch32 or
AArch64) as ready right after switching vector mode.
Change-Id: I609552c543dad8da66939c0a3079d73d48e92163
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26203
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fix MOESI_hammer checkpoint hanging.
The function markRemoved() should be called before hitCallback(),
not after it. The reason is that hitCallback() checks if draining is
complete based on the value of "m_outstanding_count". And since
markRemoved() is responsible for decrementing "m_outstanding_count",
hitCallback() does not see that there are no outstanding requests.
Reported by: Timothy Hayes
Jira: https://gem5.atlassian.net/browse/GEM5-331
Change-Id: I14c34be79843b172ae994ab1792fe4ce6cf5cf6e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25683
Reviewed-by: Timothy Hayes <timothy.hayes@arm.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Maintainer: Bradford Beckmann <brad.beckmann@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
