The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *union [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>union X ... {
by:
<indent level>union X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^union [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^union ([A-Za-z].*) \{$/union \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ union [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ union ([A-Za-z].*) \{$/ union \1\n \{/g'
and so on.
Change-Id: I066854eb27a8acd2cc2dfa41596bb1b1f66c71b1
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43328
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, 2 and 3 levels of indentation (and a single
occurrence of 2 and 3 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *struct [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>struct X ... {
by:
<indent level>struct X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^struct ([A-Za-z].*) \{$/struct \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ struct [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ struct ([A-Za-z].*) \{$/ struct \1\n \{/g'
and so on.
Change-Id: I362ef58c86912dabdd272c7debb8d25d587cd455
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39017
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation, using:
grep -nrE --exclude-dir=systemc \
"^ *class [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>class X ... {
by:
<indent level>class X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc
"^class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^class ([A-Za-z].*) \{$/class \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ class [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ class ([A-Za-z].*) \{$/ class \1\n \{/g'
and so on.
Change-Id: I17615ce16a333d69867b27c7bae0f4fdafd8b2eb
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39015
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than print the errno, print the result of strerror so the user
doesn't have to look up what each error code does. Don't duplicate
descriptors needlessly which have been returned by pipe(). Use panic_if
instead of if () panic. Check each call to a standard library function
instead of calling multiple and then only knowing that one of them
failed (but not which one). Close the far side of our pipes for both
the gem5 process, and the process that will become diod. Remove some
stray #undef-s which undefine macros that were never defined. Don't
try to force the descriptors going to diod to be particular numbers.
Slightly reduce nesting in the if which checks the results of fork.
Drop unnecessary \n-s in calls to panic, inform, etc. Minor spacing
related style fixes. Use nullptr instead of NULL.
Change-Id: I48d93778a1e139ef624876a0b316486aac774d7f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43083
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The WalkCache stats are wrongly using the legacy framework.
With this patch we are registering those to the hierarchical structure.
As we need to pass the Stats::Group parent at construction time,
we are replacing 2d arrays with Vector2d for count stats and using a flat
vector of pointers for the Formula stats
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I8992bc262a376e4e81a4d608c11dff6902e0a01d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42984
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added takeover methods for PMA Checker and RiscvTLB to ensure
that checkpoint restoration works. Also added logic in PLIC
to prevent posting interrupts to a CPU that has yet to complete
the current interrupt. PLIC's behaviour when a CPU claims another
interrupt before completion is also changed. Now PLIC will return
the uncompleted interrupt ID instead of return 0. This behaviour
is not documented in the specs but is designed this way to avoid
issues from CPU side (especially MinorCPU).
Change-Id: I68eaaf56d2c4d76cc1e0a1e2160f5abe184c2cd5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41933
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
This function causes problems with gcc 5 which incorrectly complains
about the call to warn_if inside a constexpr function. That should only
be an error if a call to a non-constexpr is unavoidable, and even then
the compiler isn't required to emit a diagnostic.
Rather than drop the warning, or add ifdefs to deal with these defective
versions of gcc, this change eliminates the power() function entirely.
Most inputs to this function would overflow anyway, which is reportedly
why no integer version of an exponentiation function is defined in the
standard library, and all uses of this function can easily and more
efficiently be replaced by simple left and right shifts.
Finally, by eliminating the power() function, we also remove the
dependence on base/logging.hh.
Change-Id: I4d014163883d12db46da4ee752696c8225534ee8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42504
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like in the nomali library, this bug is in some code making a bitmask
where what bits are enabled depends on some conditions. It used ?: to
evaluate the conditions and | to aggregate the bits, but didn't use any
()s, so the | happened first, then the ?:s. This would generate an
incorrect bitmask.
Change-Id: Iabcc8a9fd38cde5de3c0627a3b143407247c0c0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40955
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
This patch implements the RISC-V HiFive Platform
(based on the SiFive HiFive series). The HiFive
platform requires a PLIC and CLINT device (based on
current HiFive boards).
The optional uart_int_id field redirects Console interrupts
to the PLIC interrupt controller.
PlicDevice is a wrapper around BasicPioDevice that
requires an interrupt ID. Interrupts are expected to
be raised via platform->postPciInterrupt(id).
VirtIOMMIO is a slight modification from the ARM
implementation such that interrupts are posted through
PLIC
PlicDevice is a wrapper around BasicPioDevice that
requires an interrupt ID. Interrupts are expected to
be raised via platform->postPciInterrupt(id).
VirtIOMMIO is a slight modification from the ARM
implementation such that interrupts are posted through
PLIC.
Uart8250 was modified slightly for easier Python
setup.
Change-Id: I4bbdb5f903b52a41d1b7e0ccc44877c46cd30d56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40599
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This patch implements the CLINT device model based
on the SiFive U54MC datasheet. CLINT is modelled to
receive its clock signal via an interrupt pin. A
generic RTC (non-MMIO) is also implemented to provide
this signal at arbitrary frequencies.
isa.cc is also modified to provide a correct implementation
of the rdtime instruction. It will read from the miscreg
file (which is updated by CLINT every time mtime is
incremented).
Change-Id: I6f5393f3a8fdbd059f25df51d3d74bcb28da09f1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40597
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The patch is using the newly defined PARAMS macro to replace
custom params() getters in derived class.
The patch is also removing redundant _params:
Instead of creating yet another _params field, SimObject descendants
should use params() to expose the real type of SimObject::_params they
already have.
Change-Id: I43394cebb9661fe747bdbb332236f0f0181b3dba
Signed-off-by: Alexander Klimov <Alexander.Klimov@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39900
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The mismatches were from places where Params structs had been declared
as classes instead of structs, and ruby's MachineID struct.
A comment describing why the warning had been disabled said that it was
because of libstdc++ version 4.8. As far as I can tell, that version is
old enough to be outside the window we support, and so that should no
longer be a problem. It looks like the oldest version of gcc we
support, 5.0, corresponds with approximately libstdc++ version 6.0.21.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning
Change-Id: I75ad92f3723a1883bd47e3919c5572a353344047
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Event creation and management support from emulated drivers is required
to support interruptible signals in HSA and this support was not
available. This changeset adds the event creation and management support
in the emulated driver. With this patch, each interruptible signal
created by the HSA runtime is associated with a signal event. The HSA
runtime can then put a thread waiting on a signal condition to sleep
asking the driver to monitor the event associated with that signal. If
the signal is modified by the GPU, the dispatcher notifies the driver
about signal value change. If the modifier is a CPU thread, the thread
will have to make HSA API calls to modify the signal and these API calls
will notify the driver about signal value change. Once the driver is
notified about a change in the signal value, the driver checks to see if
any thread is sleeping on that signal and wake up the sleeping thread
associated with that event. The driver has also implemented the time_out
wakeup that can wake up the thread after a certain time period has
expired. This is also true for barrier packets.
Each signal has an event address in a kernel managed and allocated
event page that can be used as a mailbox pointer to notify an event.
However, this feature used by non-CPU agents to communicate with the
driver is not implemented by this changeset because the non-CPU HSA
agents in our model can directly communicate with driver in our
implementation. Having said that, adding that feature should be trivial
because the event address and event pages are correctly setup by this
changeset and just adding the event page's virtual address to our PIO
doorbell interface in the page tables and registering that pio address
to the driver should be sufficient. Managing mailbox pointer for an
event is based on event ID and using this event ID as an index into
event page, this changeset already provides a unique mailbox pointer for
each event.
Change-Id: Ic62794076ddd47526b1f952fdb4c1bad632bdd2e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38335
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The thermal models currently work on temperatures in Celsius stored in
plain doubles. Switch to using Temperature instead and internal
processing in Kelvin. There should be no impact on the result since
all thermal processes work on temperature deltas.
Change-Id: I22d0261ae102f30d86051f24a2d88b067b321c91
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39455
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
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>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39575
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes for to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I6ab03934af850494d95a37dcda5c2000794b4d3a
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39578
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When in non-caching mode, performance metrics are not meaningful, and
we're just interested in functional level behavior. Going through the
DMA FIFO in the HDLCD controller is very inefficient, and prevents
reading a batch of pixels from memory all in one go.
Change-Id: I3fb6d4d06730b5a94b5399f01aa02186baa5c9b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38721
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>
