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>
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>
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>
(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 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>
According to the ArmArm:
"When the value of the ENABLE bit is 1, ISTATUS indicates whether the
timer condition is met. ISTATUS takes no account of the value of the
IMASK bit. If the value of ISTATUS is 1 and the value of IMASK is 0 then
the timer interrupt is asserted."
Since ISTATUS is simply flagging that timer conditions are met, an
interrupt mask (via the <timer>_CTL_EL<x>.IMASK) shouldn't reset the
field to 0.
Clearing the ISTATUS bit leads to the following problem
as an example:
1) virtual timer (EL1) issuing a physical interrupt to the GIC
2) hypervisor handling the physical interrupt; setting the
CNTV_CTL_EL0.IMASK to 1 before issuing the virtual interrupt
to the VM
3) The VM receives the virtual interrupt but it gets confused
since CNTV_CTL_EL0.ISTATUS is 0 (due to point 2)
What happens when we disable the timer?
"When the value of the ENABLE bit is 0, the ISTATUS field is UNKNOWN."
So we are allowed to not clear the ISTATUS bit if the timer gets
disabled
Change-Id: I8eb32459a3ef6829c1910cf63815e102e2705566
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Adrian Herrera <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31775
Reviewed-by: Hsuan Hsu <kugwa2000@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
At Iff9ad68d64e67b3df51682b7e4e272e5f355bcd6 a check was added to prevent
segfaults when unserializing the GenericTimer in case the new number of
thread contexts was smaller than the old one pre-checkpoint.
However, GenericTimer objects are only created dynamically as needed after
timer miscreg accesses. Therefore, if we take the checkpoint before
touching those registers, e.g. from a simple baremetal example, then the
checkpoint saves zero timers, and upon restore the assert would fail
because we have one thread context and not zero:
> fatal: The simulated system has been initialized with 1 CPUs, but the
Generic Timer checkpoint expects 0 CPUs. Consider restoring the checkpoint
specifying 0 CPUs.
This commit solves that by ensuring only that the new thread context count
larger than, but not necessarily equal to the number of cores.
Change-Id: I8bcb05a6faecd4b4845f7fd4d71df95041bf6c99
JIRA: https://gem5.atlassian.net/browse/GEM5-703
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31894
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
