persist environment variables set via mtda-cli setenv to disk

some systems may use a dedicated UART for booting and/or for controlling them
support another instance of the console logger configured with its own variant and driver settings
provide monitor APIs to access its ring buffer and send arbitrary commands

it's not a great idea to share our pastebin API key. make it a config option and let users provide their own

record when the target is powered on
provide an API to return uptime in seconds
modify the CLI to print system uptime

Host           : build (0.6)                              
Remote         : mtda-nanopi (0.6)                              
Prefix key:    : ctrl-b
Session        : Peck
Target         : OFF (up 1h 23m)  
Storage on     : TARGET 
Storage writes : 2864 MiB

leave your proposal here
we will count likes in a little while to select our project logo

MTDA stands for Multi-Tenant Device Access

ERROR: mtda-git-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; unset _PYTHON_SYSCONFIGDATA_NAME; export GIT_PROXY_COMMAND="oe-git-proxy"; export NO_PROXY="*"; export PATH="/work/isar/scripts:/work/isar/bitbake/bin:/usr/sbin:/usr/bin:/sbin:/bin"; export HOME="/tmp/tmpf80dw0ux"; LANG=C git -c core.fsyncobjectfiles=0 clone --bare --mirror https://github.com/MentorEmbedded/mtda.git /work/build/downloads/git/github.com.MentorEmbedded.mtda.git --progress failed with exit code 128, output:
Cloning into bare repository '/work/build/downloads/git/github.com.MentorEmbedded.mtda.git'...
fatal: could not read Username for 'https://github.com': No such device or address

ERROR: mtda-git-r0 do_fetch: Fetcher failure for URL: 'git://github.com/MentorEmbedded/mtda.git;protocol=https;branch=master'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /work/build/tmp/work/debian-buster-armhf/mtda/git-r0/temp/log.do_fetch.243
ERROR: Task (/repo/meta-isar/recipes-python/mtda/mtda_git.bb:do_fetch) failed with exit code '1'

Provide a mechanism to stream video from UVC cameras or HDMI capture dongles

#42 implements a mechanism to switch between the console and the monitor output.
we may also want to support input to the monitor

make state changes (e.g. target on) persistent and provide option to restore then when the service is restarted

Following the documentation on building and starting mtda with QEMU I could not find a link/getting started about how to start the dispatcher utilizing the sample config?

having target_info() print both the local and remote version may help us diagnose communication issues that may arise from RPC API changes

The storage write command could compress image chunks on-the-fly to speed-up remote writes

Use https://github.com/siemens/meta-iot2050 to build MTDA images for this IOT box from Siemens

when mtda-cli dies from an unhandled exception, terminal settings aren't restored

the daemon should announce itself to the local network
this may be later used by the cli/ui to list nearby agents

see https://github.com/jstasiak/python-zeroconf/blob/master/examples/registration.py ?

Can mtda support the FriendlyArm NanoPi R1?

Rational:

It would be benificial for us to instrument the test device as well with the network environment (dhcp / fixed IP / gateway / proxy ...). This will allow us to call some device APIs from the test dispatcher as well without the need to have a parallel configuration of switches and routers.

As well more than one USB port would be helpful to avoid USB HUBs.

Looking for WiFi devices a local Hot Spot will be a help.

The nanopi R1 seems to fit well. It is thought as minirouter and comes with nice housing options.

https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=248

I have noticed that this layer fails to build using ISAR_CROSS_COMPILE = "1" (which is often enabled globally in downstream layers which may depend on this layer). It seems that mostly Python packages are affected by this, e.g.

• curve25519-donna
• hap-python

(this list is most likely incomplete)

It would be nice if this layer could be built when cross-compilation is enabled globally. There are two viable approaches:

1. Fix the problematic recipes (e.g. by depending on python-whatever:native).
2. Disable cross-compilation for recipes which cannot be fixed easily.

check if we can use the BmapBdevCopy from the bmaptools package to write images to the shared storage device
according to the documentation, the image object only needs to support read() and seek()

add f1()..f12() methods so we can virtually press F1..F12

mtda-cli should have an option to prints its version number

Amend meta-isar/recipes-core/images/mtda-image.inc to set shell to /bin/bash

As part of our upstreaming process, we need to identify maintainers of the project and list them in a MAINTAINERS file to be placed in the source tree

Some test suites require having a Wi-Fi access point to exercise their 802.11 stack. We could plug a USB Wi-Fi dongle to our NanoPI and provide APIs (most likely simple wrappers around NetworkManager calls) and configure it as an Access Point.

most of the documentation is now in doc and available online at https://mtda.readthedocs.io/en/latest/
rewrite the README.md file to only contain key information

From #76:

File "/home/siemens/local_repos/mtda/mtda/keyboard/qemu.py", line 34, in probe
     result = self.qemu.variant == "qemu"
AttributeError: 'NoneType' object has no attribute 'variant'

Reported by @bhargavdas

after adding fury.io/mtda to source list and then while installing mtda getting dependency errors,
mainly for python3-zstandard

python3-zstandard : Depends: python3 (>= 3.9~) but 3.8.2-0ubuntu2 is to be installed

Had a debug session with Gunther earlier today and we have found that mtda-usb-functions was started before /dev/sda was detected by the kernel. This caused the service to fail and his DUT could not detect our shared storage.

@bikrambhola and @chombourger would like to work with @jan-kiszka to make this repo public with the hope that it will be useful to others. we are however unsure about the process to follow for projects to be added to github.com/siemens/

mtda-cli help does not return. the process appears to be stuck on a lock

in #75, @jan-kiszka suggested we provided better documentation around the usbf storage driver
check what exists (if anything) and augment as needed

usbf is emulating a USB mass storage device, but it is configured as SD-card multiplexer - that is rather confusing /wrt naming. Maybe rename sdmux to "storage"? That would be more logical.

Also note that usbf looks underdocumented.

initial support for HomeKit was introduced with 5a56166
we however need a mechanism for our HomeKit driver to be notified on state changes and report the new status to the HomeKit network

MTDA may be controlled from the interactive console by using a key combination of a prefix key, Ctrl-a by default, followed by a command key. People using a terminal multiplexer such as screen may find our default prefix key conflicting with the multiplexer. Provide a configuration option to change the default key prefix to any letter (e.g. Ctrl-m

An downstream ISAR project needs to use the following yml configuration for extending from the mtda ISAR layer.

header:
  version: 10
  includes:
    - repo: this
      file: kas/mtda-qemu-amd64.yml
repos:
  hardware-test-dispatcher:

  this:
    url: https://github.com/siemens/mtda.git
    refspec: master

I would recommend to rename this to mtda in kas/mtda-nanopi-neo and kas/mtda-qemu-amd64.

SDWire (https://wiki.tizen.org/SDWire) is a much better alternative to SDMux. Get some of these gadgets built and include its control software in our Isar image

the storage.qemu driver will create a backing file for the shared storage when it does not exist. it will however fail to do so if the parent directory does not exist

The mtda-cli script handles both running mtda as daemon as well as a client. Since there isn't much in common between these two modes, it may be desirable to separate them out (at the source level and package level)

use zeroconf to resolve MTDA_REMOTE before trying the specified hostname/ip

implement a new sdmux/ class to support programming of the target boot device using the DFU protocol implemented in e.g. u-boot

when a session is released, it may be good to notify other users via a broadcast message