Like gem5py which uses the same main source file, this program will run
arbitrary python scripts. Unlike the other program, it will include
support for the m5 module. That will make it capable of generating
SimObject param, enum, etc c++ files.
Change-Id: I15fd7545f6b1ea6559cbe27cef30c778867ebe70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I can't conclusively verify that this issue has been fixed because I
can't find any information about it on the internet. It's "SCons bug
2006" and "gem5 bug 308" but neither project still uses whatever bug
tracking mechanism those numbers correspond to. The change was mentioned
in the gem5 code base at least as early as 2008, and so hopefully has
been fixed in the last 13 years. I did a clean build without this
workaround, and things seem to work.
Change-Id: I155f0e72cb720fb5d35d8098375a45a69ea02263
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49419
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By separating out this utility class, we make it possible to build
embedded python modules into other binarys without dragging along lots
of other, unrelated gem5 dependencies.
Also, move the class from sim/init.hh (which is a largely unrelated
name) to python/embedded.hh which much more directly describes what that
file contains.
Change-Id: Ia83439144893ad8401a5d51003e2686d9c9b2d7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49418
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Put that code into a singleton class in src/proto, so that it gets
called during initialization and teardown of gem5 without cluttering up
gem5Main. This also removes the need to use #ifdefs to guard for
actualling having protobuf support.
Change-Id: I93b5d994eee478a9c159a3f3d02b3e996af02a3e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49416
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use pybind11 to avoid having to use the python C API directly, which is
simpler, easier to read, and less error prone. Also, use its
PYBIND11_EMBEDDED_MODULE macro to set up the _m5 module instead of a
callback which has to be proactively called from main().
Change-Id: I9c8bcebea934844d16a1fdd88f66a5e66ef0486f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49413
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
m5MainCommands had been a way to override the python code which would
get the python side of gem5 started, used by some "unit" tests which
were really tests of all of gem5 but focus on a particular area. Those
tests have either been converted into real unit tests or eliminated,
and so that mechanism is no longer needed.
This change eliminates that mechanism, and also uses pybind11 to
significantly simplify the code that calls m5.main().
Change-Id: I553ae17074cd5389708f1b7313630a13a6946d76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49412
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the importer module was built into gem5 as a compressed
bytecode blob like all the other code, and it had to be singled out and
installed manually so that it could help bring in all the other modules.
That adds some amount of complexity since it has to be identified and
treated as a special case.
Instead, this change builds it into gem5 using pybind11's
PYBIND11_EMBEDDED_MODULE macro, and a string that gets evaluated into
the new module's __dict__. This means the importer module is
automatically available just by building in that .cc, and it can just be
imported to start using it.
Theoretically all the embedded python could be handled this way, but
that would mean building it into gem5 as raw strings which wouldn't even
be compiled into byte code until run time. That would take more space in
the binary, and also delay catching simple errors.
Change-Id: Ic600bf6bce41a53289a2833484a655dd5a226e03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49410
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This serves two purposes. First, it's a way to declare the base
SimObject class and params using the SimObject() SCons mechanism, while
the actual class still lives at m5/SimObject.py.
Second, it alleviates a very old inconsistency where *most* SimObjects
are imported using the m5.objects.Foo path, except SimObject itself
which lives under m5.SimObject. With this change, it will live under
both, more or less.
It may be possible to remove the inconsistency entirely in the future
and move m5.SimObject entirely to m5.objects.SimObject and only declare
it with SCons's SimObject(), but that won't quite work during this
transitional period, and it wouldn't give users a chance to move over to
the new name.
Change-Id: Ic714bacfaef73d1116ab7ff716cf19b7ce4b67e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49408
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the "path" argument is empty, use the file name of the node
referred to by the fd file descriptor. This matches the behavior of
"at" system calls when the TGT_AT_EMPTY_PATH flag is set. The system
calls themselves are responsible for checking for that flag, and
returning an error if an empty "path" is not allowed.
Change-Id: Ib48d91ff983b3edb6f65e83686b90d79d74f3471
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53683
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This added both the LupioPIC and LupioTMR to the LupVBoard. While
both the PLIC and CLINT are left in the board for the bootloader
to recognize, they aren't used within the system. In addition, the
LupV Platform was changed in order to use the LupioPIC to handle
interrupts instead of the PLIC.
Change-Id: I57005903a7ec1136b42433ef5022ccb995abb9d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53037
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This LupV Board was created in order to connect all of the LupIO
devices, and allow us to run a full RISC-V system with them. As
the LupIO devices continue to be added, they will be integrated
into this board, and replace the current IO components.
The LupIO devices are a collection of processor
agnostic and easily implemented virtual devices. Details about the
specifications of all eight LupIO devices can be found here:
https://gitlab.com/luplab/lupio/lupio-specs
Information about how to build a RISCV full system with the LupIO-RTC
can be found here:
https://github.com/darchr/lupio-gem5/blob/lupio/README.md
Change-Id: I7d3186d3778d40b38027f245290432dbf4279dea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53028
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
