The recently added free() calls in load_erase_tag() pass
program->start_sector directly to free(), but the field is declared
as const char * in struct firehose_op. GCC emits a
-Wdiscarded-qualifiers warning for both call sites.
Cast through (void *) to match the pattern already used at the other
free sites for the same field (program.c, patch.c, firehose.c).
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Requesting an erase of 0 sectors does not make logical sense, so in the
upcoming change this is made to represent an erase of the whole selected
physical partition - which is done by omitting num_sector and
start_sector from the <erase> sent to the programmer.
To avoid unexpected erasure of the full physical partition due to a
invalid <erase> tags in rawprogram.xml files, reject such entries during
parsing.
It's conceivable that it should be possible to express that request in
the rawprogram.xml, but until the semantics for that has been clarified,
reject requests with a zero-length erase.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
When the parsing any of the erase-tag attributes fails, the start_sector
might be leaked. Free the memory in the error path.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The typical usage of QDL so far has been for the user to manually
specify a programmer, as well as one or more program and patch XML
files, a so called "flat build". Some targets are built around multiple
storage medias (e.g. spinor + nvme), and some targets have a plethora of
sahara programmer files.
This puts a burden on the user to invoke qdl with the right combination
of storage selector, programmer(s), program and patch XML files. It also
adds an extra step to the build, in form of flattening the Qualcomm
builds.
The Qualcomm builds are described by a toplevel contents.xml file, which
describes to the various tools (e.g. the flattening tool) what
programmer, rawprogram, and patch files to use, and it provides mapping
of each referred file into the build directory structure.
The format also allow multiple "flavors" of flashable content to be
described, across multiple storage types.
Introduce support for parsing contents.xml files to allow the user to
flash non-flattened builds, across one or more storage devices and
filtered by select flavors.
The "qdl flash" operation is overloaded, to create a coherent user
experience. The filter/specifier interpretation is extended to allow
each, comma-separated, entry to describe storage types and flavors.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Today, the typical input to QDL is a flat build, with all binaries in
the same directory as the rawprogram and patch XML files. Despite this,
the path of the program XML was never considered to be a natural place
to search for binaries, forcing the user to use the include directive
(-i) to tell QDL so search for files alongside the XML.
Extend the path resolution logic to also search alongside the program
XML file. Let the include directory take precedence if it's provided,
and the requested file is found there.
This does alter the case where the user refers to a XML file in another
directory, but for some reason have the referred to files in the current
directory. In such cases the user need to start explicitly specify the
current directory as include path.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
During the flash phase Firehose operations with the "zip" member set
will only consider files within the zip archive, which results in more
reliable user experience.
But during the parsing of the program XML we still attempts translation
based on include dir, which might result in invalid lookups within the
zip.
Skip path resolution for payload within zip files to avoid this.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
In order to allow referenced files to be located based on the rawprogram
XML path, and later by references described in a contents XML file, the
mechanism for resolving the filename will need to grow.
Extract this mechanism into its own function to facilitate this. An
out-of-memory check is added, but in other regards no functional change.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
In the event that the parsing of the <program> tag, refererenced files
are missing, or a referred to sparse file fail to parse, the freeing of
the op is either incomplete or missing, resulting in a memory leak.
Correct the error handling to make sure we're not leaking these objects.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The flashmap and related files form a package, suitable for distribution
and one-step installation, but having to unzip the archive in order to
flash/install its content is not convenient for the user.
Extend the qdl_file helper code to also provide access to files within a
zip file, then extend the flashmap code to attempt to decode the package
file as such.
Pass the optional zip object around to the various places where we might
read files from the package.
With this we can now "flash" the installer.zip directly:
qdl flash installer.zip
The selective flashing mechanism is carried into the zip handling,
allowing the user to flash specific memories only, such as:
qdl flash installer.zip::spinor
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
When distributing builds the user/developer is forced to determine which
programmer, program, patch files should be passed to QDL, to which
storage device each set should be programmed. This isn't user friendly
and it's prone of various forms of mistakes.
A solution to this problem can be found in the build artifacts of a
Qualcomm Windows-releases where a "flashmap" file describes the very
aspects we're looking for.
Implement support for parsing this json blob, populate the Sahara images
list based on the "programmer" information, parse the "program" and
"patch" files for each memory type and populate the firehose operations
queue with "configure", "program", and "patch" operations.
Introduce a new "flash" subcommand to trigger this new implementation:
qdl flash flashmap.json
In certain cases the user might want to only flash the subset of images
pertaining to a particular storage media - such as recovering their
spinor content. The user can through a suffix operation select which
storage media to flash, e.g.:
qdl flash flashmap.json::spinor,ufs
The json parser is derived from the implementation previously in use in
the pd-mapper userspace service, to avoid adding additional library
dependencies.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Today there are a few different places through the code where files are
opened for reading, either in a oneshot fashion or for streaming (e.g.
during programming).
In order to allow these operations to read files packaged into
compressed zip files, and to avoid duplication of the load operation,
introduce the "qdl_file" file reading abstraction for these use cases.
It's not yet known how VIP is handled in these archives and to reduce
the impact of the change this time, the scope is limited to reading the
files used during normal flashing - this can obviously be considered for
extension later.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The "read" and "program" operations may have deferred GPT lookup when
partitions are read or written by name. The fat structure allow us to
take a single pass over the operations list and resolve those deferred
entries, so replace the two implementations with a single one.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
A global list for each Firehose operation type, such as the program (and
erase) actions prevents us from building up work queues that are a mix
of different operations.
One use case where this need appears is in the flashing of images across
multiple storage media, where <configure>, <program>, and <patch>
operations needs to be executed for each memory type in order.
Replace the access of the global "program" list with a list passed from
the client context. Move the loop over the actions to firehose.c in
order to allow this to be extended to the other type of firehose
operations as well.
The "program" struct serves as the embryo for the "firehose operations"
tagged struct. In doing this the "is_erase" can be removed, as the type
of the object will handle this.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
It's not obvious that list_add() appends elements to the list, and
upcoming patches needs a few new list operations.
Improve the implementation by renaming list_add() to list_append() and
introduce list_prepend() for cases where we need to inject entries in
the beginning of the queue.
Conditionally defined container_of() to allow using list.h without
including qdl.h.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Failure to allocate erase command results in an error about program
commands and program commands allocations doesn't provide an error
message.
Improve this, and use ux_err() and a return instead, as the return value
is handled by the callee.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
This adds erase_cmd_add that mirrors program_cmd_add with all the necessary bits to surface an erase CLI command like the read and write commands.
q
Signed-off-by: Jacob Creedon <jcreedon@gmail.com>
program_load_sparse() advances start_sector on each chunk by replacing
program->start_sector with a new strdup(). The previous string was
never freed, leaking one allocation per sparse chunk processed.
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
For some reason qdl was written with open-coded linked list operations
throughout the implementation, resulting in ugly boiler plate code
sprinkled over the code base.
Integrate the linked list abstraction used in a few other of our
open-source projects to clean up the code.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The nested loop and the parsing of the sparse files during application
isn't very clean, and results in parse errors coming late in the
process.
It also results in two different lists of program elements, and the
sparse entries are currently not cleaned up after application.
Instead update the program parser, such that when a sparse entry is
found the sparse image is parsed and the chunks are added to the program
list.
The filename member of the original program entry is dropped, to prevent
programming the region, while still tracking it. This could allow us to
later implement an "erase before flash" of the program segments.
This results in a much cleaner application of the program entries, and
any errors are detected up front.
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>
While already powerful, it's quite often one wants to read and write
some specific GPT partition, and manually resolving the sectors and
plugging these into either a XML file or the command line is tedious and
error prone.
Allow partition names in the address specifier of the "read" and "write"
command line actions, and when these are used read the GPTs across all
physical partitions to resolve the physical partition, start sector and
sector count for the operation.
This allow us to do things like:
qdl prog_firehose.elf write abl_a abl2esp.elf write abl_b abl2esp.elf
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>
The sparse image format is defined in little endian, not in network
order, so we should not invoke ntohs()/ntohl() when reading them.
Further, the various constants are defined in host order, so we
shouldn't ntohs()/ntohl() them either.
This also implies that the code only works for little endian host
systems today.
Drop all the ntohs()/ntohl() conversions for now, to clean out the
incorrect conversions. The task to convert from little to host is left
as an exercise for the future.
While rewriting sparse_chunk_header_parse() the large if statement is
swapped for a select, to improve readability with a single successful
exit at the end and scattered exit returns throughout.
Fixes: 02c008adfd ("add support sparse attribute")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The unsparsed chunk size is expressed in units of blk_sz. For RAW chunks
this is then limited to (just under) 32-bits due to the total_sz
(sparsed chunk size), but FILL and DONT_CARE can be much bigger.
But doing the size calculation on the 32-bit integers overflows and any
upper bits are lost, and the unsparsed result is wrong. So, switch this
to 64-bit instead.
It's unclear what happens if we pass a larger num_sectors to the
programmer, so this limitation is left, and checked for.
Fixes: 02c008adfd ("add support sparse attribute")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Igor Opaniuk
Bjorn Andersson
Jacob Creedon