This class used to drive from SimObject so that it could be derived
from to get both the interface and SimObject while still using single
inheritance.
With this change, EtherObject is now just an interface class with only
one pure virtual function which can be inherited alongside SimObject.
This makes it more flexible so that it can be used in places where you
might want a different inheritance hierarchy, for instance to inherit
from MemObject.
Change-Id: I0f07664d104eed012cf4ce6e30c416ada19505a7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17028
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
These types are IntReg, FloatReg, FloatRegBits, and MiscReg. There are
some remaining types, specifically the vector registers and the CCReg.
I'm less familiar with these new types of registers, and so will look
at getting rid of them at some later time.
Change-Id: Ide8f76b15c531286f61427330053b44074b8ac9b
Reviewed-on: https://gem5-review.googlesource.com/c/13624
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The PL011 spec specifies a DMACR register at offset 0x48, which isn't
implemented in the model. Currently any attempt to access the register
results in a panic.
This change swaps the panic for a warning only when software writes into
DMACR to disable DMA, keeping the panic otherwise.
Change-Id: I04586b52df8d5d174536276fd7ae19e77ff4681a
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15279
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Implementation registers for the GICv2 model currently hold values
referring to a GIC-400 implementation. This patch is making them
parametrizable so that it is possible to instantiate a GIC-400 model.
The patch is also modifying Realview platform to use new GIC-400 model
in lieau of GICv2.
Change-Id: I446db8c796ee3c2708af91e9139f0a6e7947321b
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/15277
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Generally speaking, the endianness of the data devices provide or
accept is dependent on the device and not the ISA the system
executes. This change makes the devices in dev pick an endianness
rather than using the guest's.
For the ISA bus and the UART, accesses are byte sized and so endianness
doesn't matter. The ISA and PCI busses and the devices which use them
are defined to be little endian.
Change-Id: Ib0aa70f192e1d6f3b886d9f3ad41ae03bddb583f
Reviewed-on: https://gem5-review.googlesource.com/c/13462
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The only part of these devices which are incompatible with other ISAs,
with the possible exception of endianness transformation, is that
the dist_iface implementation refers to ThreadContext methods and
that class is heavily tied to the guest ISA. Only those few lines are
excluded in a NULL_ISA build.
Change-Id: Ic6d643fdbb792d0a996a37d75e027c5ce0ecd460
Reviewed-on: https://gem5-review.googlesource.com/c/13469
Reviewed-by: Gabor Dozsa <gabor.dozsa@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
There are some minor ISA dependencies in the PCI device models,
specifically that they use the set<> accessors on the packet objects.
This actually compiles fine because the NULL ISA claims to be little
endian, but really these accessors should be changed to use little
endian all the time since that's what PCI is defined to use, not
the guest endianness.
The other types of accessors, specifically the ones that default to
what the guest wants, should be excluded when building NULL_ISA, and,
pending other dependencies, the NULL_ISA should no longer have an
endianness associated with it.
Change-Id: I0739122dbf67d109e7959553a1eff0239b090ca4
Reviewed-on: https://gem5-review.googlesource.com/c/13468
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
GIC architecture specification says that writing EOIR with
a not active irq it is an unpredictable behavior.
So, just warn when it happens for a PPI case, like it is
already done in SPI case.
Change-Id: Icb1b8f5690d5e87b15c3b0fe2ca0d37fdd4085ee
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13556
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This is an old platform, and we haven't had official Linux kernel configs
for it in a while, so we've decided to deprecate it.
Furthermore, trying to use it fails with:
object 'RealViewEB' has no attribute 'pci_host'
and the last commit in the class happened two years ago, which indicates
that no one has been using it.
Change-Id: Icc674b00b152eb3246e05141dbaf2624cc720f21
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12471
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Read/WriteCpu methods in the GICv2 are accessing the GICC_CTRL register
as if writing any non-zero value to the register will enable IRQ
signaling to the CPU. Instead, only the 2 least significant bits
control group0/group1 enablement. This patch is renaming GICC_CTRL
underlying data buffer from cpuEnabled to cpuControl and it is making it
an array of uint32_t instead of bool. cpuEnabled now becomes a method
and checks if GICC_CTRL.EnableGrp0 or GICC_CTRL.EnableGrp0 are set.
Change-Id: I40f0b3c52c40abd482a856f032bf3686f96ef641
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12945
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
From GCC 8.1 on GCC issues a warning when using memset et al on structs and
classes. With the way gem5 builds, this actually prevents successful
builds.
Instead of using a pointer with SCSIReply as type, we cast to a void
pointer to avoid the message. On the way we wrap the memset call into a
method of SCSIReply called reset for better code readability.
Signed-off-by: Maurice Becker <madnaurice@googlemail.com>
Change-Id: I3ed3fd9714be5d253aba01ca00b1863e1ae5cb68
Reviewed-on: https://gem5-review.googlesource.com/12685
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
UART_RSR shows errors with the transmission and UART_ECR can clear
those (according to PL011 Technical Reference Manual Revision r1p4). As
these transmission errors never occur, they are implemented as RAZ/WI.
Both registers exist at the same offset 0x004. RSR is read-only, ECR is
write-only.
Signed-off-by: Maurice Becker <madnaurice@googlemail.com>
Change-Id: Ia9d13c90c65feccf3ecec36a782170755b1e1c02
Reviewed-on: https://gem5-review.googlesource.com/12686
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
fs.py in baremetal mode currently fails for the VExpress_GEM5_V1 platform
due to inconsistent UART naming with error message:
AttributeError: object 'VExpress_GEM5_V1' has no attribute 'uart'
Consistently name keep all UARTs in the Arm platforms in a vector named
'uart' or as a single device named 'uart'. Update the configuration
scripts to reflect the fact that 'uart' can be a vector.
Change-Id: I20b8dbac794d6a9be19b6ce8c335a097872132fb
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12473
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The Pl390 model has evolved and acquired a lot of the features from GICv2,
which means that the name is no longer appropriate. Rename it to GICv2
since this is more representative of the supported features.
GICv2 is backwards compatible with the older Pl390, so we decided to
simply rename the class to represent both GICv2 and older interfaces such
as the instead of creating a new separate one.
Change-Id: I1c05fba8b3cb5841c66480e9f05b8c873eba3229
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12492
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Remove default dist_addr and cpu_addr register addresses since those are
purely platform specific.
Parametrize the cpu_size parameter. RealViewPBX has the Gic CPU and
distributor base too close for the newer CPU size of 0x2000, leading to
overlap.
This was introduced in I90a9f669a46a37d79c6cc542087cf91f2044f104 and makes
using RealViewPBX fail with:
fatal: system.membus has two ports responding within range
[0x1f000100 : 0x1f0020ff]:
system.realview.gic.pio
system.realview.gic.pio
Change-Id: Ic6c0e6b3d4705ff369eb739d54a1173a47819b7d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12491
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
In the previous implementation, the function EtherTap::recvReal will only
read one packet when received some ``interrupt'' (explicitly, when async_IO
set to true). When someone tries to send a large message to the simulated
device, the message will be divided to several packets due to packet
fragmentation. In this situation recvReal will only read one packet and
left the other packets in the buffer. This significantly increases the
networking latency. So before reading from socket, I change the socket into
non-blocking mode and keep reading from it until there's no packet left.
Change-Id: Ieb94a8532cd3994862b6f3eb9474caf7ccf617da
Reviewed-on: https://gem5-review.googlesource.com/12338
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
With this patch the python ArmInterruptPin SimObject matches to the
C++ ArmInterruptPinGen. The latter is in charge of generating
the ArmInterruptPin (which is not a SimObject anymore).
This is meant to ease the generation of ArmInterruptPins: by
not being SimObjects we are not forced to instantiate them
in the configuration script; we can generate them dynamically
instead throughout simulation.
Change-Id: I917d73a26168447221f5993c8ae975ee3771e3bf
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12401
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
