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>
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>
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>
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>
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>
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>
When the sparse image parser finds a RAW chunk, it queries the current
file offset in the sparse image and store this for the programming
phase. But the offset is stored in a 32-bit unsigned int, so when the
sparse image passes 4GB the program entries start to refer to the wrong
data.
Split the fill_value and offset into dedicated fields and give them both
their specific type, to avoid any confusion related to the size of these
data types.
Fixes: 02c008adfd ("add support sparse attribute")
Signed-off-by: Bjorn Andersson <bjorn.andersson@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>
Introduce the --allow-fusing parameter, which must be explicitly set
if the "secdata" partition is programmed, as it will lead to irreversible
changes (fuses will be blown during the next boot).
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Builds with multiple copies of the primary bootloader does not make
sense, but after successfully flashing all the partitions of such build
it makes more sense to make one of them bootable, at least more than
skipping the step and saying that none was found.
Pick the first found primary bootloader and warn the user about the
situation.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Continuing the journey to make QDL not leak any memory on a successful
run, introduce operations to free the program and patch objects on
exit.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
When parsing XML files the specified binary to be flashed may not be
present. The default behaviour of QDL is to ignore missing file. This is
sometimes undesireble.
This patch changes the default behaviour. If the file to be flashed
can't be found qdl will exit with error. An optional flag --allow-missing
is introduced. It will allow to skip missing files during flashing procedure.
Default value of the flag is false.
Signed-off-by: Milosz Wasilewski <quic_mwasilew@quicinc.com>
Assumed to be a remnant of early development lead to a recent transition
of "start_sector" from being represented as a string to an integer. But
it turns out that "start_sector" might be an expression, e.g. to write
something at the end of the disk.
So transition back to carry "start_sector" as a string.
Fixes: b6e0ea31d7 ("program: Make start_sector unsigned in")
Reported-by: Julien Robin
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
NAND based devices comes with a few minor tweaks to the program tag and
an additional erase tag, split the program code and add the handling of
the erase tag.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
On some newer platforms the device ignore the configure request to
disable ZLP, causing the Firehose program request to stall, when the
device is waiting for a ZLP to end a transfer.
Mitigate this by circumventing the qcserial driver and drive the USB
traffic directly using USBFS. The tool will attempt to detach qcserial
from the device, in case it's already attached, so no changes are needed
in the kernel or system configuration.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The attributes size_in_KB, sparse and start_byte_hex
are not used and seem to be optional. Some program
xml files do not always contain them which then causes
qdl to crash. Simply removing the unused attributes
fixes this problem.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Bjorn Andersson
Jacob Creedon
Maxim Paymushkin
Igor Opaniuk
Milosz Wasilewski
Bjorn Andersson
Daniel Kutik