For linux msm/contents xml flashing#225
Merged
andersson merged 8 commits intoMay 14, 2026
Merged
Conversation
Contributor
Author
|
The first 5 patches here are the cleanups and improvements to the relative path already present in #223. |
quic-bjorande
force-pushed
the
for-linux-msm/contents-xml-flashing
branch
3 times, most recently
from
d75bc49 to
8e50bbb
Compare
igoropaniuk
reviewed
May 12, 2026
This was referenced May 12, 2026
quic-bjorande
force-pushed
the
for-linux-msm/contents-xml-flashing
branch
from
8e50bbb to
8c69d4d
Compare
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>
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>
The patch introducing the flash support updated the README, but didn't update the usage printout. Fix this. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
There is a growing number of path concatenation cases, each built on some memory allocation scheme and some variant of sprintf. Introduce a pathbuf type and a few primitive operations to reset the pathbuf, clone a pathbuf, push a path/filename to the pathbuf, get the path, and truncate the path by dirname(). Also provide a convenient qdl_path_exist() operation to test if the pathbuf refers to an existing file. 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>
Introduce two initial set of test cases for the newly introduced contents.xml handling. One is used to validate the storage and flavor selector logic, and the other more broadly the loading of contents.xml files. Extract the common operation of creating a temporary directory to a new file that is shared across tests. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
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 single-file format of the flashmap zip lends itself very well for distributing builds, but the tools for generating one isn't broadly available. Implement a new "create-zip" operation in QDL, which parses a build from a contents.xml, generates a flashmap.json and packages all the files into a flashmap zip file. The internal structure is flattened and file names are adjusted to avoid conflicts. Sparse files are written to the file by storing the relevant chunks in their decoded form, rather than storing the sparse file (or full unsparsed file). From an implementation point of view this is easier, as we don't keep the sparsed program entry around, but it has the two benefits of us not storing DONT_CARE entries, and it avoids the need for seeking as we flash the zip file. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
quic-bjorande
force-pushed
the
for-linux-msm/contents-xml-flashing
branch
from
8c69d4d to
fb3b622
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While QDL has been used primarily in use cases where all binaries are collected in a single directory (a so-called "flat build"), Qualcomm builds are typically found with build artifacts scattered across image-specific paths, with a central directory in the form of the "contents.xml" file.
Among other things, this file describes where tools can find programmers, program, and patch files, it describes the mapping to the image-specific paths, etc.
Add support to the newly introduced "qdl flash" to be pointed at a contents.xml file and flash the build.
Then introduce the new "qdl create-zip" subcommand, which instead of flashing the build constructs a self-contained "flashmap zip" file, which can be distributed and passed directly to "qdl flash".