summaryrefslogtreecommitdiff
path: root/util/cpt_upgraders
AgeCommit message (Collapse)Author
2017-04-03arm, dev: refactor GIC Pl390 GICD_ITARGETSRn handlingCurtis Dunham
The aforementioned registers (Interrupt Processor Targets Registers) are banked per-CPU, but are read-only. This patch eliminates the per-CPU storage of these values that are simply computed. Change-Id: I52cafc2f58e87dd54239a71326c01f4923544689 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2442 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Weiping Liao <weipingliao@google.com>
2016-12-19dist, dev: fix etherswitch upgrade scriptCurtis Dunham
The aforementioned upgrader in [1] assumes every option in [system] has a delimiting '.', and also seems to do its rewriting work a bit too unconditionally. Most checkpoints in the wild don't have this device, in which case this script should be a safe no-op. [1] 2aa4d7b dist, dev: Fixed the packet ordering in etherswitch Change-Id: Icfd0350985109df1628eb9ab864cda42c54060a8 Reviewed-by: Gabor Dozsa <gabor.dozsa@arm.com>
2016-12-19arm: update AArch{64,32} register mappingsCurtis Dunham
Change-Id: Idaaaeb3f7b1a0bdbf18d8e2d46686c78bb411317 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-08-02arm: bank GIC registers per CPUCurtis Dunham
Updated according to GICv2 documentation. Change-Id: I5d926d1abf665eecc43ff0f7d6e561e1ee1c390a Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
2016-06-08dist, dev: Fixed the packet ordering in etherswitchMohammad Alian
This patch fixes the order that packets gets pushed into the output fifo of etherswitch. If two packets arrive at the same tick to the etherswitch, we sort and push them based on their source port id. In dist-gem5 simulations, if there is no ordering inforced while two packets arrive at the same tick, it can lead to non-deterministic simulations Committed by Jason Lowe-Power <power.jg@gmail.com>
2015-09-18dev, arm: Add gem5 extensions to support more than 8 coresKarthik Sangaiah
Previous ARM-based simulations were limited to 8 cores due to limitations in GICv2 and earlier. This changeset adds a set of gem5-specific extensions that enable support for up to 256 cores. When the gem5 extensions are enabled, the GIC uses CPU IDs instead of a CPU bitmask in the GIC's register interface. To OS can enable the extensions by setting bit 0x200 in ICDICTR. This changeset is based on previous work by Matt Evans.
2015-09-30isa,cpu: Add support for FS SMT InterruptsMitch Hayenga
Adds per-thread interrupt controllers and thread/context logic so that interrupts properly get routed in SMT systems.
2015-09-11dev, arm: Rewrite the HDLCD controllerAndreas Sandberg
Rewrite the HDLCD controller to use the new DMA engine and pixel pump. This fixes several bugs in the current implementation: * Broken/missing interrupt support (VSync, underrun, DMA end) * Fragile resolution changes (changing resolutions used to cause assertion errors). * Support for resolutions with a width that isn't divisible by 32. * The pixel clock can now be set dynamically. This breaks checkpoint compatibility. Checkpoints can be upgraded with the checkpoint conversion script. However, upgraded checkpoints won't contain the state of the current frame. That means that HDLCD controllers restoring from a converted checkpoint immediately start drawing a new frame (i.e, expect timing differences).
2015-09-02sim: tag-based checkpoint versioningCurtis Dunham
This commit addresses gem5 checkpoints' linear versioning bottleneck. Since development is distributed across many private trees, there exists a sort of 'race' for checkpoint version numbers: internally a checkpoint version may be used but then resynchronizing with the external tree causes a conflict on that version. This change replaces the linear version number with a set of unique strings called tags. Now the only conflicts that can arise are of tag names, where collisions are much easier to avoid. The checkpoint upgrader (util/cpt_upgrader.py) upgrades the version representation, as one would expect. Each tag version implements its upgrader code in a python file in the util/cpt_upgraders directory rather than adding a function to the upgrader script itself. The version tags are stored in the 'Globals' section rather than 'root' (as the version was previously) because 'Globals' gets unserialized first and can provide a warning before any other unserialization errors can occur.