Files
qdl/contents.h
T
Bjorn Andersson ed2d6e0a85 qdl: Introduce support for flashing contents.xml
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>
2026-05-14 16:39:30 -05:00

22 lines
536 B
C

/* SPDX-License-Identifier: BSD-3-Clause */
/*
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
#ifndef __CONTENTS_H__
#define __CONTENTS_H__
#include <stdbool.h>
#include <stddef.h>
#include "list.h"
struct sahara_image;
struct pathbuf;
struct contents_filter;
int contents_load(struct list_head *ops, const char *filename, char *specifier,
struct sahara_image *images, const char *incdir);
int contents_resolve_path(struct contents_filter *filter, const char *filename, struct pathbuf *path);
#endif