Age | Commit message (Collapse) | Author |
|
The gem5's current PCI host functionality is very ad hoc. The current
implementations require PCI devices to be hooked up to the
configuration space via a separate configuration port. Devices query
the platform to get their config-space address range. Un-mapped parts
of the config space are intercepted using the XBar's default port
mechanism and a magic catch-all device (PciConfigAll).
This changeset redesigns the PCI host functionality to improve code
reuse and make config-space and interrupt mapping more
transparent. Existing platform code has been updated to use the new
PCI host and configured to stay backwards compatible (i.e., no
guest-side visible changes). The current implementation does not
expose any new functionality, but it can easily be extended with
features such as automatic interrupt mapping.
PCI devices now register themselves with a PCI host controller. The
host controller interface is defined in the abstract base class
PciHost. Registration is done by PciHost::registerDevice() which takes
the device, its bus position (bus/dev/func tuple), and its interrupt
pin (INTA-INTC) as a parameter. The registration interface returns a
PciHost::DeviceInterface that the PCI device can use to query memory
mappings and signal interrupts.
The host device manages the entire PCI configuration space. Accesses
to devices decoded into the devices bus position and then forwarded to
the correct device.
Basic PCI host functionality is implemented in the GenericPciHost base
class. Most platforms can use this class as a basic PCI controller. It
provides the following functionality:
* Configurable configuration space decoding. The number of bits
dedicated to a device is a prameter, making it possible to support
both CAM, ECAM, and legacy mappings.
* Basic interrupt mapping using the interruptLine value from a
device's configuration space. This behavior is the same as in the
old implementation. More advanced controllers can override the
interrupt mapping method to dynamically assign host interrupts to
PCI devices.
* Simple (base + addr) remapping from the PCI bus's address space to
physical addresses for PIO, memory, and DMA.
|
|
Timing generator for a pixel-based display. The timing generator is
intended for display processors driving a standard rasterized
display. The simplest possible display processor needs to derive from
this class and override the nextPixel() method to feed the display
with pixel data.
Pixels are ordered relative to the top left corner of the
display. Scan lines appear in the following order:
* Vertical Sync (starting at line 0)
* Vertical back porch
* Visible lines
* Vertical front porch
Pixel order within a scan line:
* Horizontal Sync
* Horizontal Back Porch
* Visible pixels
* Horizontal Front Porch
All events in the timing generator are automatically suspended on a
drain() request and restarted on drainResume(). This is conceptually
equivalent to clock gating when the pixel clock while the system is
draining. By gating the pixel clock, we prevent display controllers
from disturbing a memory system that is about to drain.
|
|
Multi gem5 is an extension to gem5 to enable parallel simulation of a
distributed system (e.g. simulation of a pool of machines
connected by Ethernet links). A multi gem5 run consists of seperate gem5
processes running in parallel (potentially on different hosts/slots on
a cluster). Each gem5 process executes the simulation of a component of the
simulated distributed system (e.g. a multi-core board with an Ethernet NIC).
The patch implements the "distributed" Ethernet link device
(dev/src/multi_etherlink.[hh.cc]). This device will send/receive
(simulated) Ethernet packets to/from peer gem5 processes. The interface
to talk to the peer gem5 processes is defined in dev/src/multi_iface.hh and
in tcp_iface.hh.
There is also a central message server process (util/multi/tcp_server.[hh,cc])
which acts like an Ethernet switch and transfers messages among the gem5 peers.
A multi gem5 simulations can be kicked off by the util/multi/gem5-multi.sh
wrapper script.
Checkpoints are supported by multi-gem5. The checkpoint must be
initiated by a single gem5 process. E.g., the gem5 process with rank 0
can take a checkpoint from the bootscript just before it invokes
'mpirun' to launch an MPI test. The message server process will notify
all the other peer gem5 processes and make them take a checkpoint, too
(after completing a global synchronisation to ensure that there are no
inflight messages among gem5).
|
|
This patch adds an I2C bus and base device. I2C is used to connect a
variety of sensors, and this patch serves as a starting point to
enable a range of I2C devices.
|
|
This patch enbles use of the basic PIO devices as part of the NULL
build. Although it might seem counter intuitive to have a PIO device
without being able to execute a driver, this change enables us to
break a device class hierarchy into an ISA-agnostic part, and an
ISA-specific part, without requiring multiple-inheritance. The
ISA-agnostic base class is a PIO device, but does not make use of the
port.
|
|
This patch makes it possible to once again build gem5 without any
ISA. The main purpose is to enable work around the interconnect and
memory system without having to build any CPU models or device models.
The regress script is updated to include the NULL ISA target. Currently
no regressions make use of it, but all the testers could (and perhaps
should) transition to it.
--HG--
rename : build_opts/NOISA => build_opts/NULL
rename : src/arch/noisa/SConsopts => src/arch/null/SConsopts
rename : src/arch/noisa/cpu_dummy.hh => src/arch/null/cpu_dummy.hh
rename : src/cpu/intr_control.cc => src/cpu/intr_control_noisa.cc
|
|
This patch moves the DMA device to its own set of files, splitting it
from the IO device. There are no behavioural changes associated with
this patch.
The patch also grabs the opportunity to do some very minor tidying up,
including some white space removal and pruning some redundant
parameters.
Besides the immediate benefits of the separation-of-concerns, this
patch also makes upcoming changes more streamlined as it split the
devices that are only slaves and the DMA device that also acts as a
master.
--HG--
rename : src/dev/io_device.cc => src/dev/dma_device.cc
rename : src/dev/io_device.hh => src/dev/dma_device.hh
|
|
|
|
|
|
|
|
|
|
|
|
|
|
of those statistics to the e1000 model.
|
|
--HG--
rename : src/dev/SimConsole.py => src/dev/Terminal.py
rename : src/dev/simconsole.cc => src/dev/terminal.cc
rename : src/dev/simconsole.hh => src/dev/terminal.hh
|
|
|
|
--HG--
extra : convert_revision : 1e7f5185654ed0845678c2169c702d3b977159ed
|
|
file with them all.
--HG--
extra : convert_revision : 427f6bd8f050861ace3bc0d354a1afa5fc8319e6
|
|
creation and initialization now happens in python. Parameter objects
are generated and initialized by python. The .ini file is now solely for
debugging purposes and is not used in construction of the objects in any
way.
--HG--
extra : convert_revision : 7e722873e417cb3d696f2e34c35ff488b7bff4ed
|
|
the SConscript files so that only the objects that are
actually available in a given build are compiled in.
Remove a bunch of files that aren't used anymore.
--HG--
rename : src/python/m5/objects/AlphaTLB.py => src/arch/alpha/AlphaTLB.py
rename : src/python/m5/objects/SparcTLB.py => src/arch/sparc/SparcTLB.py
rename : src/python/m5/objects/BaseCPU.py => src/cpu/BaseCPU.py
rename : src/python/m5/objects/FuncUnit.py => src/cpu/FuncUnit.py
rename : src/python/m5/objects/IntrControl.py => src/cpu/IntrControl.py
rename : src/python/m5/objects/MemTest.py => src/cpu/memtest/MemTest.py
rename : src/python/m5/objects/FUPool.py => src/cpu/o3/FUPool.py
rename : src/python/m5/objects/FuncUnitConfig.py => src/cpu/o3/FuncUnitConfig.py
rename : src/python/m5/objects/O3CPU.py => src/cpu/o3/O3CPU.py
rename : src/python/m5/objects/OzoneCPU.py => src/cpu/ozone/OzoneCPU.py
rename : src/python/m5/objects/SimpleOzoneCPU.py => src/cpu/ozone/SimpleOzoneCPU.py
rename : src/python/m5/objects/BadDevice.py => src/dev/BadDevice.py
rename : src/python/m5/objects/Device.py => src/dev/Device.py
rename : src/python/m5/objects/DiskImage.py => src/dev/DiskImage.py
rename : src/python/m5/objects/Ethernet.py => src/dev/Ethernet.py
rename : src/python/m5/objects/Ide.py => src/dev/Ide.py
rename : src/python/m5/objects/Pci.py => src/dev/Pci.py
rename : src/python/m5/objects/Platform.py => src/dev/Platform.py
rename : src/python/m5/objects/SimConsole.py => src/dev/SimConsole.py
rename : src/python/m5/objects/SimpleDisk.py => src/dev/SimpleDisk.py
rename : src/python/m5/objects/Uart.py => src/dev/Uart.py
rename : src/python/m5/objects/AlphaConsole.py => src/dev/alpha/AlphaConsole.py
rename : src/python/m5/objects/Tsunami.py => src/dev/alpha/Tsunami.py
rename : src/python/m5/objects/T1000.py => src/dev/sparc/T1000.py
rename : src/python/m5/objects/Bridge.py => src/mem/Bridge.py
rename : src/python/m5/objects/Bus.py => src/mem/Bus.py
rename : src/python/m5/objects/MemObject.py => src/mem/MemObject.py
rename : src/python/m5/objects/PhysicalMemory.py => src/mem/PhysicalMemory.py
rename : src/python/m5/objects/BaseCache.py => src/mem/cache/BaseCache.py
rename : src/python/m5/objects/CoherenceProtocol.py => src/mem/cache/coherence/CoherenceProtocol.py
rename : src/python/m5/objects/Repl.py => src/mem/cache/tags/Repl.py
rename : src/python/m5/objects/Process.py => src/sim/Process.py
rename : src/python/m5/objects/Root.py => src/sim/Root.py
rename : src/python/m5/objects/System.py => src/sim/System.py
extra : convert_revision : 173f8764bafa8ef899198438fa5573874e407321
|
|
support enough functionality make the driver think
the device is there, and in good working order.
src/dev/SConscript:
add intel gbe to the dev SCons file
src/dev/i8254xGBe.cc:
src/dev/i8254xGBe.hh:
src/dev/i8254xGBe_defs.hh:
use new manner of registers and implement all device registers that are touched through boot and ifup
--HG--
extra : convert_revision : b1a1767f0fd31cd371e432cb48ac9a2e9f9291b5
|
|
automatic. The point is that now a subdirectory can be added
to the build process just by creating a SConscript file in it.
The process has two passes. On the first pass, all subdirs
of the root of the tree are searched for SConsopts files.
These files contain any command line options that ought to be
added for a particular subdirectory. On the second pass,
all subdirs of the src directory are searched for SConscript
files. These files describe how to build any given subdirectory.
I have added a Source() function. Any file (relative to the
directory in which the SConscript resides) passed to that
function is added to the build. Clean up everything to take
advantage of Source().
function is added to the list of files to be built.
--HG--
extra : convert_revision : 103f6b490d2eb224436688c89cdc015211c4fd30
|
|
--HG--
extra : convert_revision : e88aaaa43843c1283f29cef0886e057412705899
|
|
"generic" devices are dependent on some of those files. That will either need to change, or most likely those devices will have to be considered architecture dependent.
--HG--
rename : src/dev/tsunami.cc => src/dev/alpha/tsunami.cc
rename : src/dev/tsunami.hh => src/dev/alpha/tsunami.hh
rename : src/dev/tsunami_cchip.cc => src/dev/alpha/tsunami_cchip.cc
rename : src/dev/tsunami_cchip.hh => src/dev/alpha/tsunami_cchip.hh
rename : src/dev/tsunami_io.cc => src/dev/alpha/tsunami_io.cc
rename : src/dev/tsunami_io.hh => src/dev/alpha/tsunami_io.hh
rename : src/dev/tsunami_pchip.cc => src/dev/alpha/tsunami_pchip.cc
rename : src/dev/tsunami_pchip.hh => src/dev/alpha/tsunami_pchip.hh
rename : src/dev/tsunamireg.h => src/dev/alpha/tsunamireg.h
extra : convert_revision : ffbb6fd93341d2623a6932bf096019b8976da694
|
|
Alpha and SPARC and put SConscripts in them.
--HG--
rename : src/base/kgdb.h => src/arch/alpha/kgdb.h
rename : src/dev/alpha_access.h => src/dev/alpha/access.h
rename : src/dev/alpha_console.cc => src/dev/alpha/console.cc
rename : src/dev/alpha_console.hh => src/dev/alpha/console.hh
extra : convert_revision : a7dd466308cb83edc40528689aacb72413089cdf
|