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 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>
This patch is pulling the on-chip memory outside of the on_chip_devices
list.
The external interface will be more or less the same: configuration
scripts will still use the attachOnChipIO method; a new kw argument has
been added in order to store mem_ports.
We want to provide to on-chip memory the same mechanism used when
collecting on-chip dma ports. This is needed when using Ruby, since
we need to pass a non None mem_ports to prevent the bootmem to be
wired to the bus.
Change-Id: Ifc519c3072dc5de1530772c70c80dc2094e2c54c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22000
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is carving out a portion of VExpress_GEM5 memory for the
bootloader. Prior to this patch this was only happening
conditionally/dynamically via the setupBootLoader call. With this patch
the region is always present and the setupBootLoader doesn't instantiate
memory, it is only setting up some bootloader parameters.
Change-Id: Iaa5cdf471b14e8faa37353a25631bf7c6fc64afc
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21604
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The current default base address for GICv3 ITS stated in RealView is
0x2c120000. The redistributors base address is 0x2c010000; each
instantiated core has an associated redistributor with memory region
size 0x40000 (with GICv4 extension, enabled by default). With 8 cores,
the redistributor range spans to 0x2c210000, creating a conflict with
the ITS address space.
This patch changes the ITS base address to 0x2e010000 which guarantees
no overlapping with the redistributor.
Change-Id: I7dc1af9e69ac037f85ae96f0985554f1fb8372a0
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20608
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The PCI host has an interrupt-map property which only works for a fixed
setup of parent/child interrupt/address cells, which currently overlaps
with GICv2.
We want to make this flexible, so that the interrupt-map doesn't break
if we change the interrupt/address-cells value, and the patch is aiming
in that direction. This is also needed for GICv3 DTB autogeneration,
since it is using different values than GICv2.
Change-Id: If1c661ddcbc0c277c9d6b0e44a0fd3fe2427618c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20052
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch introduces the GICv3 ITS module, which is in charge of
translating MSIs into physical (GICv3) and virtual (GICv4) LPIs. The
patch is only GICv3 compliant, which means that there is no direct
virtual LPI injection (this also means V* commands are unimplemented)
Other missing features are:
* No 2level ITS tables (only flat table supported)
* Command errors: when there is an error in the ITS, it is
IMPLEMENTATION DEFINED on how the ITS behaves. There are three possible
scenarios (see GICv3 TRM) and this implementation only supports one of
these (which is, aborting the command and jumping to the next one).
Furter patches could make it possible to select different reactions
* Invalidation commands (INV, INVALL) are only doing the memory table
walks, assuming the current Gicv3Redistributor is not caching any
configuration table entry.
Change-Id: If4ae9267ac1de7b20a04986a2af3ca3109743211
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18601
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is needed since there is a problem in the memory layout of
VExpress_GEM5_V2 as it is: having 256KB pages is creating overlapping
regions when reserving space for 256 PEs.
GICv3 redistributors: 0x2c010000 - 0x30010000
PCI regions: 0x30000000 - 0x40000000
We fix this by cutting down the number of supported PEs to 128
Change-Id: I6e87f66a6150a441ccba298662b4548a4972dc40
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18392
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The importer in Python 3 doesn't like the way we import SimObjects
from the global namespace. Convert the existing SimObject declarations
to import from m5.objects. As a side-effect, this makes these files
consistent with configuration files.
Change-Id: I11153502b430822130722839e1fa767b82a027aa
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15981
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
