Some platforms are not GICv4 compatible, therefore we need to make sure
the stride between redistributors is configurable:
2 frames of 64KiB for GICv3 => a stride of 128KiB
4 frames of 64KiB for GICv4 => a stride of 256KiB
We detect this at runtime by reading the GICD_PIDR2.ArchRev bitfield
This is 3 for GICv3 and 4 for GICv4.
Note: other software projects [1] rely on a different check, mainly
reading the GICR_TYPER.VLPIS bit
We diverge from this behaviour as VLPIS are not implemented and we do
not want to incorrectly report this to the probing software.
We should move to VLPIS once they get implemented
[1]: https://github.com/torvalds/linux/blob/\
107c948d1d3e61d10aee9d0f7c3d81bbee9842af/\
drivers/irqchip/irq-gic-v3.c#L864
Change-Id: I7cc554f48cc6a347c03ed80cf2ea320f618a59c2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59394
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Current way of initializing GICv3 in the gem5 bootloader doesn't
work when there is a PE labelled with non-zero Aff1, Aff2 or Aff3
in the MPIDR_EL1 register
(For example in a multi-cluster configuration).
This is because the bootloader is considering Aff0 only
mrs x0, mpidr_el1
// extract the primary CPU.
ldr x1, =0xff00ffffff
and x2, x0, #0xff // use Aff0 as cpuid for now...
With this patch we are solving the issue, by considering
every affinity number. Now the primary cpu is the cpu with
Aff3..Aff0 = 0.
The bootloader was also using Aff0 (stored in x2, see above)
to let every CPU index their own redistributor memory mapped frames.
In this model every secondary CPU was in charge of initializing
their own redistributor registers.
This can't be used anymore as we have a tuple of affinity
numbers now rather than a single flat index.
We are addressing the issue by letting the primary cpu initialize
every redistributor in the system. This is done by iterating
over consecutive frames and by reading GICR_TYPER.Last, which
is set to 1 if the current frame is the last one.
Change-Id: I2bcad286c2282bf1c47618e5391bf1c2e2b27013
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59393
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This is addressing an issue raised in the mailing list [1]
where setting up a PCI mem bar for an ethernet device
resulted into an overlap of memory ranges:
fatal: system.iobus has two ports responding within range
[0x80000000:0x80020000]:
system.realview.ethernet.pio
system.iobridge.cpu_side_port
The reason for this is the following:
The PCI mem range in the DTB is using 0x40000000 (3rd word) as a
starting address in the PCI domain, which is linked to 0x40000000 in the
host domain.
<0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
However the current mapping scheme works with simple fixed translation
So address 0x40000000 in the PCI domain will be mapped to 0x40000000 +
0x40000000 = 0x80000000, which is where DRAM starts
This is aligning with DTB autogeneration, which is setting up a
PCI mem range starting at PCI address = 0 [2]
[1]: https://www.mail-archive.com/gem5-users@gem5.org/msg18941.html
[2]: https://github.com/gem5/gem5/blob/v20.1.0.0/src/dev/arm/RealView.py#L161
Change-Id: I4538511453cfd5143fb4613a080780dc86b2244c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39915
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This is a major change in our platform configuration.
At the moment the VExpress_GEM5_V1 and VExpress_GEM5_V2 platforms
both instantiate an HDLcd device. As the presence of the device
can slow down host performances when the software stack is
aware of its presence, we have historically been providing
an entry in the hdlcd DTB node to "hide" the entry from the
DTB parser:
status = "disable";
This default entry in the hdlcd node will in fact prevent the driver
from bringing up the device. Unfortunately this is useful for
experienced users only which are aware of this knob.
In order to make things more transparent, and to avoid any confusion
(e.g. having the hdlcd present in the config.ini, but not being able to
program it in Linux) we are deprecating this solution; we are removing
the HDLcd from the aforementioned platforms.
Users not interested on simulating a display controller won't
notice the difference.
Users interested on including it, will now have to switch to a new
VExpress_GEM5_Vx_HLCD platform
which will enabled the HDLcd without any further tweaking required
JIRA: https://gem5.atlassian.net/browse/GEM5-866
Change-Id: I4b1920efe764080115a57f52d8a3df2e6e2386a0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38796
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
armv7, armv8, armv8_big_little DTS files are reusing the same
encoder node; moreover those should really be cpu specific files.
For these reasons, and to make it possible to craft a final DTS
without defining a display phandle, we move the shared code into
a display DTS include file
Change-Id: I4f756807292e492a743bb9ab9ec511011125a436
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38795
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before the commit, the bootloader had a hardcoded entry point that it
would jump to.
However, the Linux kernel arm64 v5.8 forced us to change the kernel
entry point because the required memory alignment has changed at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=v5.8&id=cfa7ede20f133cc81cef01dc3a516dda3a9721ee
Therefore the only way to have a single bootloader that boots both
pre-v5.8 and post-v5.8 kernels is to pass that information from gem5
to the bootloader, which we do in this patch via registers.
This approach was already used by the 32-bit bootloader, which passed
that value via r3, and we try to use the same register x3 in 64-bit.
Since we are now passing this information, the this patch also removes
the hardcoding of DTB and cpu-release-addr, and also passes those
values via registers.
We store the cpu-release-addr in x5 as that value appears to have a
function similar to flags_addr, which is used only in 32-bit arm and
gets stored in r5.
This commit renames atags_addr to dtb_addr, since both are mutually
exclusive, and serve a similar purpose, DTB being the newer recommended
approach.
Similarly, flags_addr is renamed to cpu_release_addr, and it is moved
from ArmSystem into ArmFsWorkload, since it is not an intrinsic system
property, and should be together with dtb_addr instead.
Before this commit, flags_addr was being set from FSConfig.py and
configs/example/arm/devices.py to self.realview.realview_io.pio_addr
+ 0x30. This commit moves that logic into RealView.py instead, and
sets the flags address 8 bytes before the start of the DTB address.
JIRA: https://gem5.atlassian.net/browse/GEM5-787
Change-Id: If70bea9690be04b84e6040e256a9b03e46710e10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35076
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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.
