On error, decode_programmer_archive() and decode_sahara_config() leak
both the input blob and any images partially loaded before the failure.
Fix by extending their error paths to call sahara_images_free() and
free the blob, mirroring the cleanup already done on success. Also
introduce sahara_images_free() to consolidate teardown, drop the
misleading 'const' from sahara_image.name, and release sahara_images
in qdl_flash() on all exit paths.
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Commit '44e7be00aca0 ("sahara: Drop "single image" concept")' cleaned up
the handling of programmer selection, but in the new flow failed to
propagate the successful decoding of the sahara_config.
Fixes: 44e7be00ac ("sahara: Drop "single image" concept")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Rather than mixing subcommands and the default "flash" operation, split
the flashing mechanism out into its own subcommand function to clean up
the main function.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Dumping all the DDR takes significant time and there's currently no
user-visible feedback provided to indicate that even the process has
started.
Solve this by wiring up the ux module and provide a progress bar while
dumping segments, as well as information as the segments are skipped or
dumped.
Add missing ux_init() to the ramdump setup, and make sure to clamp value
to max in the progress calculation, to avoid funky issues when progress
is made beyond the size of the chunk.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Providing qdl-ramdump as a separate executable has resulted in it not
being part of several of the distributions that include qdl. Also, users
that knows that qdl supports ramdumps are looking for it "in" qdl, not a
related tool.
Make "ramdump" a subcommand, just like "qdl list", to improve the
ergonomics of the tool.
The implementation is a (almost) verbatim copy of ramdump.c. The
existing executable is kept in order to not break those distributions
that explicitly do package said executable.
At some point we should figure out how to drop this.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
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>
When working with multiple devices and the --serial argument, the serial
numbers must be known.
Add a new command "qdl list" to list the connected devices in EDL mode
and their serial number.
Signed-off-by: lucarin91 <lucarin@protonmail.com>
[bjorn: Replaced --list with list, changed output to only print serial, some stylistic changes]
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Commit '5b768d8be070 ("qdl: Allow multiple Sahara images")' introduced
support for specifying multiple programmer images, by splitting the
requested programmer on ':'-character and use the pair as id and
filename specifiers. This obviously breaks absolute paths in Windows.
Reorder the programmer decoder such that if the specifier starts with an
id followed by a ':', then the specifier must be a comma-separated list
of id:filename (where ',' is not allowed in the filename).
In all other cases consider the whole specifier the one file to use as
programmer, programmer archive, or programmer specifier XML. This brings
back the ability to specify programmer by absolute path in Windows.
The parsing of the programmer specifier is also altered to not tokenize
on ':' but instead only find the first one and then treat the rest as
the filename. This makes it possible use absolute paths here as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
For SoCs that support multiple UFS devices, firehose allows the slot property. This adds a flag to set the slot parameter.
Signed-off-by: Jacob Creedon <jcreedon@gmail.com>
Flattened METAs contains the relevant programmer files, as well as a
special "sahara_config" XML file, which specifies the Sahara images and
their image ids.
Support populating the Sahara images array from this XML file as well,
to make it easy to flash this type of builds.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Providing a long list of Sahara image ids and their respective payload
filename is cumbersome and error prone.
Introduce support for loading a "programmer archive", a CPIO archive
containing the list of Sahara images. The Sahara image id is read from
the filename of each file in the archive, and should be provided in the
form "<id>[:<filename>]".
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Some newer targets, such as Kaanapali, is requesting multiple images
from Sahara on the path to reach Firehose mode.
Extend the handling of the "programmer" argument to allow specifying a
comma-separated, colon-separated list of "<id>:<filename>" entries, to
specify the filenames for each of the image ids to be provided.
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>
Rather than accepting an arbitrary string for "storage type", pass this
through a variety of strcmp() and then passing it verbatim to
<configure>, define the supported storage types, decode the passed
value, and clean up the various checks.
While doing so, extend the help text to document that we do support both
"nand" and "spinor" (the latter with some trouble).
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
firehose_run() is clearly sequential, except if UFS provisioning is
taken place, then it's a completely different sequence and an early
return - almost like it's two separate functions crammed into one.
Split firehose_provision() from firehose_run() and make the decision in
qdl.c instead.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Having the tool fail due to missing images before we establish the USB
connection turns out to be rather nice, so let's do the same thing with
the flash programmer.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Rather than letting the flash process get halfway through before
aborting for missing files, check that files are available while loading
the program xml files, before we start talking to the device.
In addition to a better user experience, this helps cleaning up the
upcoming change where sparse files are parsed at load time as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Rather than waiting until program and read time to resolve the include
path, adjust the filename paths while we're parsing the XML tags.
This simplifies the execution step slightly, but more importantly it
allow us to also apply the missing-files check at load time in an
upcoming commit.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
There are a number of scenarios where one just want to write a binary
file directly to some specific location on the target, such as writing a
full disk image to LUN 0. Similarily (although not as frequent) one just
want to dump a few sectors of data for inspection.
So far the recommended way to do this has been to craft a program.xml
or a read.xml file and feed to QDL, but this is annoying.
Add support for writing/reading binary data straight to/from the device
by the means of just specifying the "write" or "read" commands on the
QDL commandline, e.g.:
qdl prog_firehose.elf write 0 debian.img
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Prettify usage details and introduce explicit -h param:
Usage: qdl [options] <prog.mbn> [<program> <patch> ...]
-d, --debug Print detailed debug info
-v, --version Print the current version and exit
-n, --dry-run Dry run execution, no device reading or flashing
-f, --allow-missing Allow skipping of missing files during flashing
-s, --storage=T Set target storage type T: <emmc|nand|ufs>
-l, --finalize-provisioning Provision the target storage
-i, --include=T Set an optional folder T to search for files
-S, --serial=T Select target by serial number T (e.g. <0AA94EFD>)
-u, --out-chunk-size=T Override chunk size for transaction with T
-t, --create-digests=T Generate table of digests in the T folder
-D, --vip-table-path=T Use digest tables in the T folder for VIP
-h, --help Print this usage info
Example: qdl prog_firehose_ddr.elf rawprogram*.xml patch*.xml
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
This extends the Firehose protocol implementation to support the VIP
extension. It implements a state machine that counts the number of
packets sent, then injects the VIP table as the next RAW packet when
the Firehose programmer runs out of provided digests and needs a new table
of digests to validate the next packets. For example:
Packet 0: DigestsTableToSign.bin.mbn (53 digest + 1 digest of next table)
Packet 1: <configure>
Packet 2: <program>
Packet 3: ...
...
Packet 54: ChainedTableOfDigests0.bin (255 digests + digest of next table)
Packet 55: <program>
...
Packet 309: ChainedTableOfDigests1.bin
To enable VIP extension provide a path where previously generated VIP
tables are stored using "--vip-table-path" param:
$ qdl --vip-table-path "<vip-table-path>" prog_firehose_ddr.elf \
rawprogram*.xml patch*.xml
Signed-off-by: Igor Opaniuk <igor.opaniuk@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>
