To allows better versioning control between releases add `dev1` to the
current version. This allows other under development tools such as
Workload Automation to ensure that a sufficiently up to date version of
devlib is installed on the system.
Add BaylibreAcmeInstrument, a new instrument providing support for the
Baylibre ACME board as a wrapper for the IIO interface. This class
provides better access to the ACME hardware (e.g. the ability to control
the sampling frequency) and to the retrieved samples than what the other
instrument, AcmeCapeInstrument, provides. Furthermore, it removes an
unnecessary and limiting dependency by interfacing directly with the IIO
drivers instead of relying on an intermediate script ("iio-capture") potentially
introducing unexpected bugs. Finally, it allows handling multiple probes
(the ACME can have up to 8) through an easy-to-use single instance of this
class instead of having to have an instance of AcmeCapeInstrument per channel
potentially (untested) leading to race conditions between the underlying
scripts for accessing the hardware.
This commit does not overwrite AcmeCapeInstrument as
BaylibreAcmeInstrument does not provide interface compatibility with
that class. Anyhow, we believe that anything that can be achieved with
AcmeCapeInstrument can be done with BaylibreAcmeInstrument (the
reciprocal is not true) so that BaylibreAcmeInstrument might eventually
replace AcmeCapeInstrument.
Add BaylibreAcmeInstrument documentation detailing the class interface
and the ACME instrument itself and discussing the way it works and its
potential limitations.
Exceptions such as TargetError can sometimes be raised because of a
network issue, which is useful to distinguish from errors caused by a
missing feature for automated testing environments.
The following exceptions are introduced:
* DevlibStableError: raised when a non-transient error is encountered
* TargetStableError
* DevlibTransientError: raised when a transient error is encountered,
including timeouts.
* TargetTransientError
When there is an ambiguity on the type of exception to use, it can be
assumed that the configuration is correct, and therefore it is a
transient error, unless the function is specifically designed to probe a
property of the system. In that case, ambiguity is allowed to be lifted
by assuming a non-transient error, since we expect it to raise an
exception when that property is not met. Such ambiguous case can appear
when checking Android has booted, since we cannot know if this is a
timeout/connection issue, or an actual issue with the Android build or
configuration. Another case are the execute() methods, which can be
expected to fail on purpose. A new parameter will_succeed=False is
added, to automatically turn non transient errors into transient ones if
the caller is 100% sure that the command cannot fail unless there is an
environment issue that is outside of the scope controlled by the user.
devlib now never raises TargetError directly, but one of
TargetStableError or TargetTransientError. External code can therefore
rely on all (indirect) instances TargetError to be in either category.
Most existing uses of TargetError are replaced by TargetStableError.
In commit fec0868 setup.py was updated to ensure that commit id is
included within the package version however this was not updated to
reflect the change.
Implement PEP396 which specifies that a package should advertise its
version via __version__ attribute.
As devlib is often used as a development version directly from source,
also add a __full_version__ attribute which appends the current commit
ID to the version.
Use the __full_version__ inside setup.py
We add a TraceCollector which logs the traffic on a serial port. This
can then be used to debug why a board crashes, or to extract extra
information from the device whilst it is running a workload.
Add new energy instrument that is based on arm-probe tool to manage AEP
Main advantages of this tool are:
- uses a config file for describing channels and shunt resistors value
- manages power topology description in the config file. This topology
is then used when computing power figures
- can create virtual power channel and aggregate channels
- support multiple AEP
- support auto-zero of AEP's channel
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Adds initial support for ChromeOs Targets.
If the device does not support running android apps the target will
behave like a `LinuxTarget` however if android is supported, the chromeos
target opens 2 connections, one via shh to the linux target, as normal,
and one via adb to the android container. By default all calls will be
made to the linux target and if not present, will attempt to use the
android container instead. The android container is also exposed via a
`android_container` attribute so can be accessed directly.
In order to detect whether the target supports running android apps the
existance of '/opt/google/containers/android/' will be queried upon
connection to the linux target.
DerivedMeasurments processors now return DerviedMetrics rather than
measurments. The notion of an InstrumentChannel doesn't really make
sense in the context of DerivedMeasurments, which are not directly
measured on the target. Since Measurement's require a channel, a simpler
DerviedMetric is added that only requires a name and a type.
Adds `DerivedMeasurements` which are designed to perform post processing on
a provided MeasurementCsv.
Currently only a `DerivedEnergyMeasurements` class has been added which
has 2 purposes:
- Calculate energy from power results if not present using recorded timestamps,
falling back to a provided sample rate
- Calculate cumulative energy and average power from a specified MeasurementCSV
file.
This commit adds a gem5 simulation platform. The platform is responsible for starting the gem5 simulation.
Changes to be committed:
modified: devlib/__init__.py
modified: devlib/platform/__init__.py
new file: devlib/platform/gem5.py
This is the first in a series of commits to allow for the use of gem5 as a target in devlib.
The interaction with the gem5 simulation is done by the Gem5Connection, a type of TelnetConnection.
There are two types of Gem5Connections (Linux and Android) as they differ slightly in the implementation
of some methods. Other types of connections have only been changed to make them uniform (e.g. arguments for init method)
Changes to be committed:
modified: devlib/__init__.py
modified: devlib/host.py
modified: devlib/utils/android.py
modified: devlib/utils/ssh.py
Perviously, a parameter passed into SshConnection controlled whether the
connection was established over SSH or Telnet. Now, there is a separate
class for Telnet connections.
Now that connection classes can be passed as arguments on Target
instatiation, they are part of the user-facing API and are marked as
such by exporting them in the main __init__.py
