Each board can define its own conditions on which the controller should
boot into DFU mode rather than normal application mode. Let's move the
"UART loopback jumper" to QMOD specific part. For SIMtrace we have an
actual button and can use that in a future patch.
The logic to detect if the respective module is already initialized
or not was broken. When performing initialization, we of course need
to set initialized=1.
the */usb_strings.txt files always assumed that the first line is the
manufacturer string, followed by the product string in the second line.
However, the enum strDescNum had it the other way around. Let's fix it
by adjusting the enum to reality.
Fixes: SYS#3591
USB addresses change every time the device re-enumerates, while the path
reflects the physical topology of USB connections and stays persistent
unless the usb cabling is changed. Let's allow the user to specify the
path instead of the address to uniquely identify a given slot.
It seems that sometimes we get even an LIBUSB_ERROR_IO and failing on
errors breaks the application, while ignoring it works. Not sure why
that really is, but for now it increases reliability.
as soon as simtrace2-remotesim is started, we issue the command to
instruct the use of the remote SIM card and ask the modem to reset
itself (to start using the new remote sim).
msg->l2h should always point at the first byte of the header after the
generic simtrace header. For some reason this doesn't work if used
globally, but it is required for the MSGC_MODEM messages to be
interpreted correctly.
In current implementations, we have one interface (with it's own
separate set of USB end-points) per slot. However, the USB protocol
already includes a slot-number in the header to be able to remove that
restriction in future versions.
Also, if the USB protocol is used remotely over a network, then we could
multiplex differnt slots from different USB interfaces into one stream
on the network side.
In order to prepare the data structures in the host program, let's
introduce that logical split there, too. Might seem a bit like
overkill, but I don't want to rewrite all code later...
We want to be able to use some code irrespective of the application
(emulation, tracing, ...), so let's split the transport struct out of
the cardem_instance.
The current protocol was card-emulation specific. The new protocol is
generic/flexible enough to accommodate both tracing and card emulation,
as well as modem control and other future extensions.
We now generalize the USB communiction and abandon the 'req_ctx'
structure inherited from openpcd. Instead we use the libosmocore 'msgb'
structure to handle incoming and outgoing USB tranfers. We also use
linuxlist-based msgb-queues for each endpoint.
