The Sahara implementation was written without understanding of the
special meaning of image id #13. As the implementation grew support for
multiple images the special casing of "single image" was introduced, and
this spread to the calling bodies.
Prior to the introduction of multi-programmer platforms this didn't
matter, the logic was fairly simple and usage was straight forward.
But when a single programmer image is provided on a multi-programmer
target "single_image" is true and hence the image id is ignored on the
first read, the one provided file is loaded. The typical outcome is that
the following SAHARA_END_OF_IMAGE_CMD fails with a message stating
"non-successful end-of-image result".
Few users draws the conclusion that this is because they didn't provide
the appropriate programmers.
But 13 is the image id for the programmer, so it should be fine to drop
the special logic. This results in a (somewhat) more helpful error
message telling the user that an invalid image is being requested.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Lugging around the filename of the to-be-loaded Sahara image(s) prevents
us from (in a later patch) load the programmer payload from an archive.
So move the loading of the specified programmer image(s) to parse time
and hold each one in memory instead.
While doing this, move the "mappings" array (i.e. the list of Sahara
images) to the stack instead, as it was already being passed as a
parameter to the relevant function(s).
sahara_run() is also extended to provide debug information about which
images are being presented to the device.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Usage of __unused macro before the variable name leads
to triggering checkpatch sanity check:
CHECK: spaces preferred around that '*' (ctx:WxV)
Fix this by moving the macro to the end of a function param
declaration, like it's done in the Linux kernel code.
Fixes: a79a572f18 ("Address unused parameter warnings")
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Use __unused attribute to suppress compile warnings for callback
implementations, where some parameters aren't used. For example:
warning: unused parameter ‘qdl’ [-Wunused-parameter]
./firehose.c:257:80: warning: unused parameter ‘rawmode’ [-Wunused-parameter]
257 | static int firehose_configure_response_parser(xmlNode *node...
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
qdl already provides usage information by -h/--help command line
options. So port this usage information for ks and ramdump tool.
Signed-off-by: Roger Shimizu <rosh@debian.org>
During QRB2210 provisioning, a USB write failure has been
observed early in the Firehose phase (first block write).
This issue has been traced to a timeout during the USB
bulk transfer of the Zero-Length Packet (ZLP).
In some conditions, the ZLP transfer may take longer than
the current timeout, up to approximately 1.7 seconds.
The issue specifically occurs after a prior large eMMC write
operation (e.g., during a previous QDL session). It could then
be related to internal eMMC I/O operations or timing delays
affecting the USB ack.
To resolve this issue, we introduce a timeout parameter to the
qdl_write function, consistent with the existing qdl_read, and
we increase the timeout to 10 seconds for Firehose raw binary
write operations to avoid 'false-positive' timeout.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Address all obvious coding style issues caught by checkpatch.pl tool.
sha2.c and sha2.h were kept as there are.
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Make build compatible with Windows using MSYS2 MINGW64 compiler. Add a small compatibility file for functions that don't exist in MINGW64.
Signed-off-by: Julien Vanier <jvanier@gmail.com>
The typical ramdump covers the entire DDR, which on modern devices can
be huge. But sometimes one is only interested in one or more specific
segments.
Parse the optional, comma-separated, argument to qdl-ramdump, and use
this to skip not requested segments.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Most devices in non-production mode will upon a fatal software fault
enter a ramdump mode, where Sahara can be used to extract the full
content of DDR (and a few other regions), for post-mortem debugging.
Introduce support for this part of the protocol.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
The introduction of kickstart support made the assumption that the EDL
will request image #0, but this is not the case. Return to the old
behavior of ignoring the image number.
The change also made the assumption that the status in done can be
trusted, but e.g. MSM8916 returns done status of 0 upon successful
fetch, so ignore this value as well in the "single payload" case.
ks (short for kickstart) is a utility which uses sahara to load images
from the host to a device. This is intended for "flashless boot"
devices like the Qualcomm Cloud AI 100 which rely on obtaining the
runtime firmware from the host instead of storing it on device.
While ks uses sahara, like qdl, it is different enough that a separate
utility is justified. ks does not need USB support, instead opting for
simple open()/read()/write() operations. ks does not need firehose.
The set of program arguments that ks needs is vastly different than the
set that qdl supports.
This initial implementation of ks defines two arguments. Both are
required, but the image specifier argument can be specified more than
one.
A sample invocation -
ks -p /dev/mhi0_QAIC_SAHARA -s 1:/opt/qti-aic/firmware/fw1.bin -s 2:/opt/qti-aic/firmware/fw2.bin
In this example, ks is instructed to use the /dev/mhi0_QAIC_SAHARA
device node file as the "port" which the device is using for the sahara
protocol. /opt/qti-aic/firmware/fw1.bin is mapped to id 1, and
/opt/qti-aic/firmware/fw2.bin is mapped to id 2. If the device requests
image id 1, ks will attempt to open and read
/opt/qti-aic/firmware/fw1.bin to send to the device. Note that
/opt/qti-aic/firmware/fw1.bin does not need to exist on the filesystem.
If ks cannot access the file (perhaps because it does not exist), then
the device will determine the next action. This is useful for setting
up a single command in a udev rule that can handle multiple
configurations, such as an optional DDR training process.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
