CNTFRQ_EL0 should be initialised to a uniform value in all cores present
in the system. Previously, this was only done if EL3 was present,
however architecture states CNTFRQ_EL0 may be written from the highest
EL implemented.
This patch moves this initilization outside of the EL3-only one.
Change-Id: Ibaa197de53d531ba898e5137ba4f46a8c9554699
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24683
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
First, remove a deprecated flag that gcc no longer recognizes.
Second, disable suffix based implicit makefile rules. These, in
combination with the %.o: boot.S rule, were tricking make into deleting
it's own makefile. How, you might ask?
make wants to update its makefile, since that's a thing it does
automatically. This is useful if you, for instance, have computed
header dependencies.
make decides it can make a file called "makefile" from a file called
"makefile.o" by doing a linking step.
make decides it can make makefile.o from boot.S from the %.o: boot.S
rule, which it does.
It then attempts to link makefile.o into makefile, but that fails
because it lacks a "main" function since it's using a built in rule
which doesn't know not to expect main. The makefile is clobbered in the
process.
make then deletes makefile.o because it was an implicit target,
eliminating all the evidence.
Change-Id: Ib0dfc333dc554caf5772dd8468dba6ba821f98ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24329
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@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>
Making vexpress_gem5_vX.dtsi depend on vexpress_gem5_vX_base.dtsi
does nothing, since vexpress_gem5_vX.dtsi is never built (much in
the same way as there is no point in making a C header depend on
another).
Fix that by making all the .dts depend on both .dtsi's.
Change-Id: I9131e0b1b2e521bb09d14721dec38bf6a2d98583
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Ruben Ayrapetyan <ruben.ayrapetyan@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/16143
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
With the introduction of the new DPU model, we need different
variations of the VExpress_GEM5_V1 platform. This splits the platform
dtsi file into a separate file for the base platform and the
HDLCD-based platform. This matches the hierarchy in RealView.py.
Change-Id: Id02380122655b5d3aa3548a703fdef178bba17d9
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/11035
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The DTB for the VExpress_GEM5_V1 was incorrectly flagging timer
interrupts as being edge triggered. Describe the interrupt as being
level triggered to match Juno and FVP.
Change-Id: I9ce4b8959e7cc28d8b208727119ff20e581311f8
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Gabor Dozsa <gabor.dozsa@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/10024
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The aarch64 boot loader was distributed using a BSD license that was
using non-standard formatting. Updated the license to match gem5's
canonical license format and removed the separete LICENSE.txt file.
Change-Id: I660b73ca5ddd922763a2b72051c73d539248ebcf
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5728
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
An ARM big.LITTLE system consists of two cpu clusters: the big
CPUs are typically complex out-of-order cores and the little
CPUs are simpler in-order ones. The fs_bigLITTLE.py script
can run a full system simulation with various number of big
and little cores and cache hierarchy. The commit also includes
two example device tree files for booting Linux on the
bigLITTLE system.
Change-Id: I6396fb3b2d8f27049ccae49d8666d643b66c088b
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The dts files in system/arm/dt currently assume that an (unreleased)
gem5-specific virtual encoder is used as a remote endpoint for the
HDLCD. This driver won't be released as a more general virtual encoder
is about to be posted on the Linux DRI devel list and this encoder has
now been merged with gem5's kernel tree. This changeset updates gem5's
dts files to use that encoder.
Change-Id: Ic1a1be728efd31603752fdfba005b6dbdea42e7e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Rene De Jong <rene.dejong@arm.com>
Ship aarch32 and aarch64 device trees with gem5. We currently ship
device trees as a part of the gem5 Linux kernel repository. This makes
tracking hard since device trees are supposed to be platform dependent
rather than kernel dependent (Linux considers device trees to be a
stable kernel ABI). It also makes code sharing between aarch32 and
aarch64 impossible.
This changeset implements a set of device trees for the new
VExpress_GEM5_V1 platform. The platform is described in a shared file
that is separate from the memory/CPU description. Due to differences
in how secondary CPUs are initialized, aarch32 and aarch64 use
different base files describing CPU nodes and the machine's
compatibility property.
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
The simple_bootloader checks for CPU0 in a manner incompatible with systems
actually using affinity levels -- just looking at MPIDR[7:0]. However, in
future we may wish to use real affinity levels and this method will be in danger
of matching several CPUs with affinity0 = 0.
Match affinity2 == affinity1 == affinity0 == 0 instead.
