The twister integration on this board is problematic:
+ It assumes that it will be building on the device's linux
installation, which is often a somewhat slow Apollo Lake board (Up
Squared) with extremely limited storage space (mine has only 5G left
on the internal eMMC after Zephyr installation and can't fit a full
twister build tree).
+ Reading the trace output before the firmware load will emit output
from a previous test run. Twister isn't consistent about the order
in which the --west-flash and --device-serial-pty scripts are
started, which means that tests show spurious failures when the
order changes or if the device started with a test in its trace
buffer.
This is an elaboration on the scripting I've been using. It's a
single script that works as both the west-flash and device-serial-pty
handlers (or as an all-in-one standalone if you pass it the path to
the zephyr.elf file instead of running it under twister). It reaches
the device host over ssh and runs the tools with sudo, minimizing
administration overhead (the device does need a checked-out Zephyr
tree and a built diag_driver kernel module though).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Zephyr testcases(not SOF case) not use kernel DSP driver to load image
on ADSP board, thus do not need signing with xman. So add a input
'--no-manifest' to specify signing without xman in image. If use DSP
driver load image, we should not specify this.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When load firmware by script, the buffer size and data size are not
same, so specify size when copy data to buffer.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Change the command that signing with rimage by flash script after
commitID:b553166a has been merged, that patch add a new option -D for
specify configuration, so update the command of this script.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
The default behavior of the log reader is to dump the full device trace
buffer. But that can contain output from a previous run and the state
parser in twister can get confused. Add a "--no-history" argument that
emits only new log data, which corresponds more closely to the way a
hardware UART would work.
(Code change is just two lines, everything else is comments & docs)
Fixes#30979
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Documentation update with information on how to run twiter integration
testing on this board. Also elaborate the discussion of permissions
setup.
(Longer term, it would be better to include a udev example of how to
set permissions on those files rather than doing it manually, and to
include fuller instructions on how to build the needed SOF driver
instead of just priving a link to a github tree.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add script signing and flashing up_squared_adsp board. Can be used:
$ west flash \
<zephyr>/boards/xtensa/up_squared_adsp/tools/flash.sh
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The existing implementation of the adsplog.py script worked fine for
individual runs (e.g. when running specific code) but had no support
for detecting system reset events and thus could not be used for
monitoring applications like test automation. It also could not
handle the case where a rapid log burst would overflow the buffer
before being noticed at the client. Also, the protocol here was also
rife with opportunities for race conditions. Fix all that up via what
is mostly a rewrite of the script. The protocol itself hasn't
changed, just the handling.
Also includes some changes to the trace_out.c code on the device side.
These are required to get ordering correct to make race conditions
tractably handleable on the reader side.
Some of the specific cases that are managed:
* There is a 0.4s backoff when a reset is detected. Continuing to
poll the buffer has been observed to hang the device (I'm fairly
sure this is actually a hardware bug, reads aren't visible to the
DSP software).
* The "no magic number" case needs to be reserved for detecting system
reset.
* Slot data must be read BETWEEN two reads of the ID value to detect
the case where the slot gets clobbered while being read.
* The "currently being filled" slot needs to always have an ID value
that does not appear in sequence from the prior slot.
* We need to check the full history in the buffer at each poll to
detect resets, which opens up a race between the read of the "next
slot" (which is absent) and the full history retrieval (when it can
now be present!). Detect that.
* A null termination bug in the current output slot got fixed.
Broadly: this was a huge bear to make work. It sounds like this
should be a simple protocol, but it's not in practice.
Also: clean up the error reporting in the script so it can handle new
PCI IDs being added, and reports permissions failures on the required
sysfs file as a human-readable error.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
