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.
use quiesceNs on other CPUs
panic rather than spin on an error
console/Makefile:
Add m5op to the build process
console/dbmentry.S:
use quiesceNs on other CPUs
console/printf.c:
panic rather than spin on an error.
console/console.c:
the go parameter to unixBoot is never used, so get rid of it.
just panic if we return from unixBoot since it's never supposed
to happen.
remove the MAX_CPUS parameter and the bootStrapImpure variable
and just allocate memory as needed. (Can in theory support many
more CPUs.)
only compile one console
console/Makefile:
Now that the location of the m5 backdoor is passed into the
console via the m5AlphaAccess variable, we only need to
compile one console, and don't need to define TLASER or TSUNAMI
console/console.c:
Don't hardcode the location of the AlphaAccess structure, but
rely on m5 to pass in the correct value.
Setup "volatile struct AlphaAccess *m5AlphaAccess" for use and
get rid of the hardcoded usage.
I steped on while doing it
console/console.c:
Allocate more HWRPB pages so we have room for 64 percpu_rpbs
Fix writing of Console Relocation Block virtual addresses so that
if they are outside of the first page, which they will be with more
than 8 processors, the correct adress is written
palcode/Makefile:
Update makefile for tsunami with 64 processors
palcode/platform_m5.S:
Add support for tsunami with 64 processors
