Newer targets require multiple programmers to be used, and while the
current flashmap format does specify an array of programmers it does not
allow the Sahara id to be specified.
Replace the flat array with an object, keyed on the Sahara image id to
allow specifying the arbitrary number of programmers the platform might
need.
As this change has not made it into the formal specification, the
version is forked with a "-qdl" suffix.
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>
While conceptually the same, the filtering mechanism used to determine
what parts of a contents XML file to be flashed needs to be more
sophisticated than the flashmap case - in addition to the storage types,
the contents XML also have "flavors".
There's sufficient overlap between the two concepts that it makes sense
to present them through the same user interface (qdl flash), with the
same structure of the filter/selection mechanism.
Split the flashmap filter logic into the part that separates filename
and specifier, and the actual filtering. Push the filtering details into
flashmap_load().
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Throughout the codebase we translate between the storage_type enum and
the string representation of the same, provide a common set of helpers
in util.c, instead of duplicating this table.
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>
Bjorn Andersson