Fix TargetInfo.from_pod(). As part of creating the POD, some of devlib's
classes such as Cpuinfo, get serialized. Since they are from devlib,
they do not implement WA's serialization interface, and are instead
serialized by extracting their internal structures. They are then not
deserialized properly, since their __init__'s expect text rather than
parsed structures.
This implements deserialization functions for these classes which
initialize them properly from TargetInfo POD.
- Use get_config_point_map() to ensure aliases are parsed from
configuraiton.
- Only set the default for a name only if it matches the corresponding
param's name (i.e. don't set for alises).
Some targets need more than 5 seconds to re-connect to a wifi network
after disabling airplane mode. To fix that, poll for network up to 20
seconds and show a warning if unreachable.
The generic "frequency" runtime parameter was only being set when there
are common frequences between avialable cores. It should always be set,
even if there are no frequencies in common, as it still valid to use it
with special values "min" and "max", in which case it should resolve
correctly to the appropriate frequencies.
This enables you to do things like:
global:
runtime_parameters:
airplane_mode: true # This improves repeatability of energy measurements
workloads:
- name: foo
- name: bar
- name: geekbench
runtime_parameters:
airplane_mode: false # Geekbench requires network, and we don't care
# about energy for that workload anyway
- Make sure TargetManager.finalize() actually gets called at the end
of the run.
- Overrule the "diconnect" parameter behavior for gem5 and make sure it
always disconnects. This necessary for stats to be generated properly.
Gem5Platform requires a host output directory as one if it's
instantiation parameters. This is not something we want to expose a
configuration parameter to the user, as for WA, the standard output
directory ought to be used.
Up to this point, WA's target instatiation process assumed that all
parameters came from the user, and there was no way for WA itself to set
them. This commit adds extra_platform_parms argument to
instantiate_target, to remedi this.
extra_platform_parms is then used to set the host output directory for
gem5 appropriately.
(linux|android)_gem5 devices were being described as having gem5
platforms but standard linux/android connections. This commit fixes this
by making sure that the gem5 connection is used.
Runtime param names from config were matched against names available on
for the target using an overly-loose regex that resulted in the wrong
config point being returned.
Use caseless_string matching instead.
Connection settings were not being properly extracted from device_config
and not used. Meaning it was impossible to e.g. specify the adb device
to use for a run.
This ensures that connection settings are extracted, validated, and used
properly.
Before performing feature discovery on a device, all cores are attempted to be
onlined, however due to power management on some phones, cores can be immediately
hotplugged out again therefore causing the command to file. This commit now just
logs a message to warn that the online process failed and the information obtained
from a device may be incomplete.
Previously if one of the runtime parameters failed to initialize it would cause
the the entire setup process to fail. Now if an error is encountered e.g. a core
went offline when trying to read its information, that particular parameter will
be disabled along with it's supported parameters. This means that only if a user
attempts to use the RT parameter will execution be stopped however it will raise
a potentially misleading unsupported parameter error.
assistant_params are now handled consistently with the other kinds of
params in TargetDescription, and they are now part of the default config
generated.
Previously if a parameter was not specified via config it would not
be used during initialisation even if the parameter had a default
value. Now any parameters with default values are populated as necessary.
- Workload's update_result stage has now been broken up into two parts:
extract_results and update_output. This is to allow the assistant to
pull output from the target in between the two stages.
- Updated assistant implementations for Linux and Android targets from
the exisiting code.
- Extended target descriptor code to handle assistants and their
parameters as well.
- Updated the target manager to actually make use of the assistants.
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
