The existing device tree generation method would use the default
frequency as both the min and max frequency when setting up the OSC
device tree nodes. This would sort of work, except it seems that if
the kernel needed to adjust a frequency, it would fail to do so since
it would assume the new frequency was out of range.
Since the existing property is used to set the initial frequency of
those clocks, and because the default, min and max frequencies are all
mostly independent variables (other than obvious ordering restrictions),
two new properties were added, min_freq and max_freq, which are only
there to fill in the frequency range property in the device tree. If
they aren't set, then the device tree generation method falls back to
the old way of using the default frequency as both min and max.
Change-Id: Ie907bd673f8bcb149e69e45c5b486863149b8a68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
HSA packet processor will now accept and process agent packets.
Type field in packet is command type.
For now:
AgentCmd::Nop = 0
AgentCmd::Steal = 1
Steal command steals the completion signal for a running kernel.
This enables a benchmark to use hsa primitives to send an agent
packet to steal the signal, then wait on that signal.
Minimal working example to be added in gem5-resources.
Change-Id: I37f8a4b7ea1780b471559aecbf4af1050353b0b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37015
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This gets rid of the requirement to only modify one byte register at a
time, and builds some structure around individual DMA channels.
The one small feature of the i8237 that was implemented is still
implemented, but now with a method of the i8237.
Change-Id: Ibc2b2d75f2a3b860da3f28ae649c6f1a099bdf7d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36815
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A memory willing to autogenerate child nodes can do that directly in
the generateDeviceTree method. However sometimes portions of memory
(child nodes) are tagged for specific applications. Hardcoding the
child node in the parent memory class is not flexible, so we delegate
this to the application model, which is registering the generator
helper via the ParentMem interface
JIRA: https://gem5.atlassian.net/browse/GEM5-768
Change-Id: I5fa5bac0decf5399dbaa3804569998dc5e6d7bc0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34376
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
This is a scoped enum meant to be used mainly in the python world
for DTB autogeneration. By making an ArmInterruptPin self aware of
its own type, we can use it in the C++ world when modelling devices.
For example if a device spec is enforcing a specific triggering behaviour,
its gem5 implementation can query the interrupt type and panic if its
expectations are not met. In this way we are sure what the Linux kernel
sees in the DTB is in sync with how the model really behaves
Change-Id: I66ae3cfbc7b1ed94804f1f882c12eb31f70840da
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35395
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In python, the BARs had been configured using three arrays and a scalar
parameter. The arrays tracked the BAR value in the config, whether the
BAR was for a "legacy" IO range, and the size of the BAR, and the
scalar parameter was an offset for the "legacy" IO addresses to map
into the host physical address space. The nature of a BAR was implied
by its raw config space value, with each of the control bits (IO vs.
memory, 64 bit, reserved bits) encoded directly in the value.
Now, the BARs are represented by objects which have different types
depending on what type of BAR they are. There's one for IO, one for
memory, one for the upper 32 bits of a 64 bit BAR (so indices work
out), and one for legacy IO ranges. Each type has parameters which
are appropriate for it, and they're parameters are all grouped together
as a unit instead of being spread across all the previous values.
The legacy IO offset has been removed, since these addresses can be
offset like any other IO address. They can be represented naturally
in the config using their typical IO port numbers, and still be turned
into an address that gem5 will handle correctly in the back end.
Unfortunately, this exposes a problem in the config system where
a VectorParam can't be overwritten successfully one element at a time,
at least when dealing with SimObject classes. It might work with
actual SimObjects in a config, but I haven't tried it. If you were
to do that to, for instance, update the BARs for x86 so that they
used legacy IO ports for the IDE controller, it would complain that
you were trying to instantiate orphaned nodes. Replacing the whole
VectorParam with a new list of BAR objects seems to work, so that's
what's implemented in this change.
On the C++ side, BARs in the config space are treated as flat values
on reads, and are stored in the config structure associated with each
PCI device. On writes, the value is first passed to the BAR object,
and it has a chance to mask any bits which are fixed in hardware and
update its idea of what range it corresponds to in memory.
When sending AddrRanges up to the parent bus to set up routing, the
BARs generate each AddrRange if and only if their type has been
enabled in the config space command register. The BAR object which
represents the upper 32 bits of a 64 bit BAR does not claim to be
IO or memory, and so doesn't contribute a range. It communicates with
the BAR which represents the lower 32 bits, so that that BAR has the
whole base address.
Since the IO or memory BAR enable bits in the command register are now
handled by the PCI device base class, the IDE controller no longer has
to handle that manually. It does still need to keep track of whether
the bus master functionality has been enabled though, which it can
check when those registers are accessed.
There was already a mechanism for decoding addresses based on BARs
in the PCI device base class, but it was overly complicated and not
used consistently across devices. It's been consolidated, and used in
most places where it makes sense.
Finally, a few unnecessary values have been dropped from the base PCI
device's and IDE controller's checkpoint output. These were just local
copies of information already in the BARs, which in turn are already
stored along with the data in the device's config space.
Change-Id: I16d5f8cdf86d7a2d02a6b04d1f9e1b3eb1dd189d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35516
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before, for historical reasons, the PCI host device was the default
responder on the IO bus, meaning that when there was any type of
transaction which didn't have a device to go to, it would end up
looking like a PCI config transaction. It's very unlikely that this is
what it actually was, and what would happen would be arbitrary and
probably not helpful.
Also, there was no device in place to respond to accesses in x86's IO
port address space. On a real system, these accesses just return junk
and are otherwise legal. On systems where there would be physical bus
wires they would probably return whatever the last data on the bus was.
This would have been helpful when the platform was first being set up
because it would make it obvious when the OS tried to access a device
that wasn't implemented, but there were a few cases where it would
purposefully fiddle with ports with nothing on them. These had one off
backing devices in the config which would handle the accesses
harmlessly, but if the OS changed and tried to access other ports, the
configs would need to be updated.
Now, the PCI host is just another device on the bus. It claims all of
the PCI config space addresses, so any config access, even ones which
don't go with a device, will go to it, and it can respond with all 1s
like it's supposed to.
In it's place, the default responder is now a bus. On that bus is
a device which responds to the entire IO port address range with 0s.
The default on *that* bus is a device which will mark any accesses
as bad.
With this setup, accesses which don't go to a device, including a
device on the IO port address space, will go to the IO bus's default
port. There, if the access was an IO access, it will go to the device
which replies successfully with all 0s. If not, it's marked as an
error.
The device which backs the entire IO address space doesn't conflict
with the actual IO devices, since the access will only go towards it
if it's otherwise unclaimed, and the devices on the default bus don't
participate in routing on the higher level IO bus.
Change-Id: Ie02ad7165dfad3ee6f4a762e2f01f7f1b8225168
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35515
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change replaces the __attribute__ syntax with the now standard [[]]
syntax. It also reorganizes compiler.hh so that all special macros have
some explanatory text saying what they do, and each attribute which has a
standard version can use that if available and what version of c++ it's
standard in is put in a comment.
Also, the requirements as far as where you put [[]] style attributes are
a little more strict than the old school __attribute__ style. The use of
the attribute macros was updated to fit these new, more strict
requirements.
Change-Id: Iace44306a534111f1c38b9856dc9e88cd9b49d2a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35219
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This macro probably would have been defined to "return" in some cases,
to be put after a call to a function that doesn't return so that the
compiler wouldn't think control would reach the end of a non-void
function. It was only ever defined to expand to nothing, and now that
[[noreturn]] is a standard attribute, it should never be needed going
forward.
Change-Id: I37625eab72deeaede77f9347116b9fddd75febf7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35217
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
(1) ThreadContexts are registered into System in BaseCPU::init.
(2) FVPBasePwrCtrl state is resized based on registered ThreadContexts
in FVPBasePwrCtrl::init.
FVPBasePwrCtrl::init may be called before BaseCPU::init based on the
model names alphabetical order, leading to segmentation faults.
To fix this, (2) is now carried out in FVPBasePwrCtrl::startup.
Change-Id: Ica6c5b7448da556d61aee53f8777a709fcad2212
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35075
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This size was used to break up DMA transactions so that a single
transaction would not cross a page boundary. This was because on Alpha,
there was an actual page table which translated between PCI and DMA
address spaces. On all currently implemented systems, the mapping is
simply to add a scalar offset, so it's not possible for a legal region
of memory to be contiguous in one space but not in the other.
Additionally, if it *was* possible for there to be a mismatch, it was
only coincidence that Alpha used a page table which had the same sized
pages as it normally used. There is no requirement that there even would
be fixed sized pages in the first place.
To avoid this artificial dependency between the IDE controller and the
ISA, this change simply changes the chunk size for DMA accesses to 4K.
That's the page size at least on x86 and probably other architectures,
and will be a pretty close approximation of the previous behavior.
It's possible that even having this chunking in the first place is
unnecessary and functionally useless, but there are some checks which
happen between chunks, and changing how big they are would change the
frequency of those checks. For instance, the controller/disk may not
notice in the same amount of time if a DMA was cancelled somehow.
Change-Id: I1ec840d1f158c3faa31ba0184458b69bf654c252
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34178
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
VirtIO devices currently request their endianness from the System
object. Instead of explicitly querying the system for its endianness,
expose the device's endianness as a param. This param defaults to the
endianness of a parent object using the Parent proxy (in practice the
system).
Change-Id: If4f84ff61f4d064bdd015a881790f5af03de6535
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33296
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
This has been in this file since it was created in 2009. No global "using
namespace ${NAMESPACE}" should ever appear in a .hh file since then that
namespace is "used" in all files that include the .hh, even if they
aren't aware of it or even actively don't want to.
Change-Id: Idb7d7c5b959077eb4905fbb2044aa55959b8f37f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34155
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
db_offset used to be calculated through pointer arithmetic. Pointer
arithmetic increments the address by the size of the data type the
pointer is pointing at. In the previous db_offset calculation, that
was a uint32_t, which means the input was multiplied by 4, which is
sizeof(uint32_t)
This patch multiplies the input value by sizeof(uint32_t) before
assigning it to db_offset.
Change-Id: I9042560303ae6b8b1054b98e9a16a9da27843bb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32678
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
isa_traits.hh used to have much more in it, but now it only has
PageShift, PageBytes, and (for now) the guest endianness. These values
should only be retrieved from the System class generally speaking, so
only the system class should include arch/isa_traits.hh.
Some gpu compute related files need PageBytes or PageShift. Even though
those files don't advertise their ISA dependence, they are tied to x86.
In those files, they can include arch/x86/isa_traits.hh.
The only other file which legitimately needs arch/isa_traits.hh is the
decoder cache since it uses PageBytes to size an array.
Change-Id: I12686368715623e3140a68a7027c136bd52567b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33203
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
