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>
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>
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.
