Two python Enum parameter types had some very generic elements which
both include one named "none". When headers for both are included that
creates a conflict which breaks the build. Enums which such extremely
generic names need to be scoped so that they don't invite these sorts
of collisions.
This change converts them from Enum to ScopedEnum in python, and also
makes a few small changes to where they're used in c++ to match.
Issue-on: https://gem5.atlassian.net/browse/GEM5-447
Change-Id: Ibda6e6cfcd700a618f8c68d174f33ec1e178b9ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
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>
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 attachment (port binding) of the SMMUv3 master and control
ports is independent of the connection of device masters to it.
This behaviour is now moved from SMMUv3::connect to
RealView::attachSmmu, as it is a responsibility of the Platform
designer.
This fixes crashes when connecting multiple device masters.
Change-Id: If1e8f55d51876fe761f881e3044ffec637c21b09
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26923
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
This is a reduced model of the FVP Base platforms Power Controller.
As of now it allows the following functions from software:
- Checking for core presence
- Reporting the power state of a core / cluster
- Explicitly powering off a core on WFI
- Explicitly powering off cores in a CPU cluster on WFI
- Explicitly powering on a core through writes to PPONR register
Change-Id: Ia1d4d3ae8e4bfb2d23b2c6077396a4d8500e2e30
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26463
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GenericTimer specification includes a global component for
a universal view of time: the System Counter.
If both per-PE architected and memory-mapped timers are instantiated
in a system, they must both share the same counter. SystemCounter is
promoted to be an independent SimObject, which is now shared by
implementations.
The SystemCounter may be controlled/accessed through the memory-mapped
counter module in the system level implementation. This provides
control (CNTControlBase) and status (CNTReadBase) register frames. The
counter module is now implemented as part of GenericTimerMem.
Frequency changes occur through writes to an active CNTFID or to
CNTCR.EN as per the architecture. Low-high and high-low transitions are
delayed until suitable thresholds, where the counter value is a divisor
of the increment given the new frequency.
Due to changes in frequency, timers need to be notifies to be
rescheduled their counter limit events based on CompareValue/TimerValue.
A new SystemCounterListener interface is provided to achieve
correctness.
CNTFRQ is no longer able to modify the global frequency. PEs may
use this to modify their register view of the former, but they should
not affect the global value. These two should be consistent.
With frequency changes, counter value needs to be stored to track
contributions from different frequency epochs. This is now handled
on epoch change, counter disable and register access.
References to all GenericTimer model components are now provided as
part of the documentation.
VExpress_GEM5_Base is updated with the new model configuration.
Change-Id: I9a991836cacd84a5bc09e5d5275191fcae9ed84b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25306
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The _on_chip_memory member function is utilised at RealView level, but
it does not provide a default implementation. This assumes all platforms
extending RealView have on-chip memory. This patch provides a default
implementation for safeness.
Change-Id: Iaaa2bee7a85653ee97bfa95b50047eb350a88b58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25643
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Recent changes in the setupBootloader method didn't take into account
that the VExpress_GEM5_Base class does require "loc" to be passed
to the bootloader setup method:
setupBootLoader(self, cur_sys, loc, boot_loader=None)
However VExpress_GEM5_V2_Base was just passing cur_sys and boot_loader
so that the bootloader was being passed as loc and boot_loader was
passed as None (default parameter):
super(VExpress_GEM5_V2_Base, self).setupBootLoader(
cur_sys, boot_loader)
This patch is fixing this by removing loc from the VExpress_GEM5_Base
interface: the bootloader defaults (usinbg loc) are being set in the
derived classes (V1 and V2)
Change-Id: Ic4d4e4fd8d45a7af9207900287828119c3d7d56c
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/+/25583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This file doesn't seem to actually get referred to by anything in gem5,
and additionally MIPS FS mode has a ways to go before it can be used.
If this file is really necessary for running MIPS, it can be retrieved
from the history in the future.
Change-Id: I3a86fc928a4be1c9159f0fafb986dfb06d09bb7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25404
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This value is just a cached inverse of _freq and can be recalculated
easily once the checkpoint is restored. The actual value of _period
actually depends on the global resolution of time (ie how much time a
Tick represents), and so saving the value of _period is also not
technically correct, even though in practice that will very rarely
cause a problem.
Change-Id: I21e63ba25ac4e189417905e532981f3d80723f19
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24390
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds the reference 32KHz clock to VExpress_GEM5_Base derived
platforms. This is in preparation for supporting the SP805 Watchdog.
I/O voltage domain and platform clock domain coupling is transferred
to the __init__ method for correctness.
Change-Id: Ic743fd986793f1e43b75fa60260c9b43b2737763
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24204
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
VExpress_GEM5_Base states that its memory map is based on
CoreTile Express A15x2 A7x3, while the model used for the
Daughterboard Configuration Controller (DCC) is based on
Coretile Express A15x2.
These two daughterboard specifications differ in both on-chip
memory map and DCC clocks as of the TRMs.
This patch makes the reference consistent to Coretile Express
A15x2 and adds several non-confidential references to aid in
understanding the platform and adding new peripherals.
Change-Id: Ia55e7362bdc9ed6509f8eff4cbd7eb38e538d774
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24203
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is updating the arm regression configs so that the newer
VExpress_GEM_V1 platform is used instead of the older VExpress_EMM and
VExpress_EMM64.
A new optional kernel_mode argument has been added in order to
distinguish between realview and realview64 platforms. If not provided
the config will assume the machine is running a AArch64 kernel.
Other notable additions:
- DTB autogeneration in regressions
- Using minimal m5exit.squashfs disk image
Change-Id: Ia230565f072fe3eb7756c41876dba4657583f4df
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22687
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Architecture states the system counter has a fixed base frequency
provided in the first entry of the frequency modes table. Optionally,
other lower frequencies may be specified in consecutive entries.
This patch adds configurable frequencies to the GenericTimer model.
The default base frequency is kept as the one that was previously
hardcoded for backwards compatibility.
The table is not recommended to be updated once the system is running.
Change-Id: Icba0b340a0eb1cbb47dfe7d7e03b547af4570c60
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22425
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
