Add Script to generate or update FvUpdate.xml file with Firmware entries #25

quicthogaru · 2025-09-22T10:50:21Z

The current FvUpdate.xml was created as part of a proof of concept to demonstrate EFI capsule functionality.
For real HW, this file is much more detailed and can be difficult / error prone to create.
There are already partition files in the https://github.com/qualcomm-linux/qcom-ptool repo for most supported Qualcomm Linux HW and various storage types (emmc and UFS).

Let's introduce a script which parses one of those partitions.conf files as a way of generating an initial FvUpdate.xml which can then be customized by the user as needed. The script takes either:

a file path to a local partition file
parameters specifying the type of HW and storage type in order to choose the reference partition.conf from the online qcom-ptool repo

NOTE: Once the new FvUpdate.xml file is generated, please update the operation to be performed on each firmware entry. By default the operation type will be set to IGNORE.

ricardosalveti · 2025-09-22T23:12:06Z

Can you add a commit message body explaining why the changes?

ricardosalveti · 2025-09-22T23:13:35Z

@igoropaniuk @mike-scott ^

mike-scott · 2025-09-23T05:23:25Z

@quicthogaru Thank you for working on this!

ODM/OEMs may customize the reference partition.conf files for various reasons and/or point to a fielded device's partition.conf as the partitions may be fuse locked prior to being deployed.

There are customers who are preparing to ship production devices on QLI 1.4/1.5/1.6 (which supports EFI capsule updates) but the configurations for those versions of QLI are different than in the reference repo:
Example: https://github.com/qualcomm-linux/meta-qcom-hwe/blob/scarthgap/recipes-devtools/partition-utils/qcom-partition-confs/ufs/qcm6490-partitions.conf

We've also seen at least 1 ODM add a custom partition in LUN4 to hold serial # / MAC information and for this reason they have overridden the default partition.conf in the QLI build. And depending on where this is located, it could affect offsets for partitions behind it if they don't follow the a/b location rules.

Currently, there is no way to point to a customized file vs. the online reference file in the UpdateFvXml.py script.

Perhaps we could have a choice between running:
python3 UpdateFvXml.py -S <StorageType> -T <Target>
or
python3 UpdateFvXml.py -F <Local partition.conf file>

Thank you for this consideration.

mike-scott · 2025-09-23T05:44:51Z

@quicthogaru regarding Ricardo's comment asking a commit description. I always like to think of the description as a note to someone who has no knowledge of the project. They would need the context of the patch explained in detail.

Using this logic, my description for your commit would look something like this:

The current FvUpdate.xml was created as part of a proof of concept to demonstrate EFI capsule functionality.  For real HW, this file is much more detailed and can be difficult / error prone to create.  There are already partition files in the https://github.com/qualcomm-linux/qcom-ptool repo for most supported Qualcomm Linux HW and various storage types (emmc and UFS).

Let's introduce a script which parses one of those `partition.conf` files as a way of generating an initial `FvUpdate.xml` which can then be customized by the user as needed.  The script takes either:
-  a file path to a local partition file
-  parameters specifying the type of HW and storage type in order to choose the reference partition.conf from the online qcom-ptool repo

NOTE: Once the new FvUpdate.xml file is generated, please update the operation to be performed on each firmware entry.  By default the operation type will be set to IGNORE.

uefi_capsule_generation/README.md

mike-scott · 2025-09-23T05:55:30Z

uefi_capsule_generation/UpdateFvXml.py

+
+def main():
+    parser = argparse.ArgumentParser(description="Generate FvUpdate.xml from partitions.conf")
+    parser.add_argument("-S", "--StorageType", choices=["UFS", "EMMC"], required=True, help="Specify storage type: UFS or EMMC")


Kind of off-topic, but are we missing some EMMC partition.conf files in the qcom-ptool repo? In theory, those would only have LUN 0 and 1.

Example for QLI 1.5: https://github.com/qualcomm-linux/meta-qcom-hwe/blob/scarthgap/recipes-devtools/partition-utils/qcom-partition-confs/emmc/qcm6490-partitions.conf

RB3 Gen2 dir in the ptool repo:
https://github.com/qualcomm-linux/qcom-ptool/tree/main/platforms/qcs6490-rb3gen2

Yes, the qcom-ptool is missing an EMMC-specific partitions.conf.
Since GUIDs are the same for both boot EMMC and UFS, the tool uses the same identifiers.
Based on the -S argument, the tool generates FvUpdate.xml using:

Logical partition names for EMMC

Partition names/GUIDs from UFS partitions.conf

We just merged support for having both emmc and ufs partitions.conf files, and it is currently only available for qcs615-adp-air, but we should had for others soon.

e.g. https://github.com/qualcomm-linux/qcom-ptool/tree/main/platforms/qcs615-adp-air

Thanks for the info @ricardosalveti .
We can update the script once it is available for all targets.

JFYI, Updated the script with the below usage.

Usage: UpdateFvXml.py [-h] (-T TARGET & -S {UFS,EMMC}) | [-F PARTITIONS_CONF]

python3 UpdateFvXml.py -S -T

or

python3 UpdateFvXml.py -F

As currently we don't have emmc directories for all targets, going to use ufs partitions in case of -T & -S.
For -F, we directly fetch the storage type from provided conf file.

mike-scott

I didn't do an in detail review yet, as I'm hoping we can add a parameter which points to a local partition.conf file, however, I found a typo and make a comment on the storage selection parameter.

The current FvUpdate.xml was created as part of a proof of concept to demonstrate EFI capsule functionality. For real HW, this file is much more detailed and can be difficult / error prone to create. There are already partition files in the https://github.com/qualcomm-linux/qcom-ptool repo for most supported Qualcomm Linux HW and various storage types (emmc and UFS). Let's introduce a script which parses one of those `partitions.conf` files as a way of generating an initial `FvUpdate.xml` which can then be customized by the user as needed. The script takes either: - a file path to a local partition file - parameters specifying the type of HW and storage type in order to choose the reference partition.conf from the online qcom-ptool repo NOTE: Once the new FvUpdate.xml file is generated, please update the operation to be performed on each firmware entry. By default the operation type will be set to IGNORE. Signed-off-by: Venkat Thogaru <[email protected]>

ricardosalveti · 2025-09-29T17:11:06Z

Changes LGTM, not tested.

igoropaniuk

Added comments

igoropaniuk · 2025-10-22T11:17:54Z

uefi_capsule_generation/README.md

+   ***Once the FvUpdate.xml file is generated, please update the Operation to be performed on the each Firmware entry***<p>
+   ***By default the Operation type will be set to IGNORE***<p>

+


these two blank lines are not needed

igoropaniuk · 2025-10-22T11:22:05Z

uefi_capsule_generation/README.md

      -   QCS8300 ESRT GUID: 8BF4424F-E842-409C-80BE-1418E91EF343<p>
      -   QCS615 ESRT GUID: 9FD379D2-670E-4BB3-86A1-40497E6E17B0<p>

+


please drop these two lines

igoropaniuk · 2025-10-22T11:26:23Z

uefi_capsule_generation/UpdateFvXml.py

+
+def write_xml(doc, output_file="FvUpdate.xml"):
+    with open(output_file, "w", encoding="utf-8") as f:
+        f.write('<?xml version="1.0" encoding="utf-8"?>\n')


the whole block can be just replaced with:

xml_str = doc.toprettyxml(indent=" ", encoding="utf-8") f.write(xml_str)

igoropaniuk · 2025-10-22T11:34:23Z

uefi_capsule_generation/README.md


+3. **Generate/Update FvUpdate.xml with Firmware entries:**
+
+      This script will generate FvUdpate.xml file, with Firmware Entries,


Suggested change

This script will generate FvUdpate.xml file, with Firmware Entries,

This script will generate the `FvUpdate.xml` file with firmware entries.

igoropaniuk · 2025-10-22T12:06:34Z

uefi_capsule_generation/UpdateFvXml.py

+    partition_info = {}
+    if storage_type == "EMMC" and args.F :
+        pattern = re.compile(
+            r"--partition\s+--name=([\w\-]+)\s+--size=\d+KB\s+--type-guid=([\w\-]+)(?:\s+--type=emmc)?(?:\s+--filename=([\w\.\-]+))?",


It's just a matter of preference, but why not use just one regex for both eMMC/UFS (to avoid code duplication and possible confusion), where LUN and filename are optional and the type might be ufs/emmc (I haven't tested, just a sketch to show an idea). For example, the regex might be :

pattern = re.compile( r"--partition\s+" r"(?:--lun=(?P<lun>\d+)\s+)?" r"--name=(?P<name>[\w\-]+)\s+" r"--size=\d+KB\s+" r"--type-guid=(?P<guid>[\w\-]+)" r"(?:\s+--type=(?P<type>ufs|emmc))?" r"(?:\s+--filename=(?P<filename>[\w.\-]+))?", re.IGNORECASE, )

and then we just process a dict containing all the named subgroups of the match, enforcing the per-mode (EMMC vs UFS) constraints:

gd = m.groupdict() lun = gd.get("lun") name = gd["name"] guid = gd["guid"] want_lun = (storage_type == "UFS") or (storage_type == "EMMC" and not args.F) if want_lun: # Storage type UFS if lun not in ['1', '4']: continue else: # Storage type eMMC if lun is not None: continue entry = {"guid": guid, "filename": filename} if want_lun: entry["lun"] = lun partition_info[name] = entry

igoropaniuk · 2025-10-22T12:16:39Z

uefi_capsule_generation/UpdateFvXml.py

+        repo_url = "https://github.com/qualcomm-linux/qcom-ptool.git"
+        repo_dir = "qcom-ptool"
+        safe_clone(repo_url, repo_dir)
+        if args.T == "QCS6490":


I believe this list will be extended with additional platforms in the future, so it's better to have it defined separately at the beginning of the script (so it's easier to find where it's):

SUPPORTED_PLATFORMS = { "QCS6490": "qcs6490-rb3gen2", "QCS9100": "qcs9100-ride-sx", "QCS8300": "qcs8300-ride-sx", "QCS615": "qcs615-adp-air", }

and here we can just loop of the dict items or even have a simple function wrapper:

def get_target_name(soc_name): for platform, target in SUPPORTED_PLATFORMS.items(): if soc_name == platform: return target target = get_target_name(args.T)

igoropaniuk · 2025-10-22T12:16:56Z

uefi_capsule_generation/UpdateFvXml.py

+    elif args.T :
+        if not args.StorageType:
+            print("Error: You must provide -S/--StorageType when using -T/--target.")
+            sys.exit(1)


Can we move these two lines to the top of the script and make them all CAPS (just to follow PEP 8):

REPO_URL = "https://github.com/qualcomm-linux/qcom-ptool.git" REPO_DIR = "qcom-ptool"

mike-scott reviewed Sep 23, 2025

View reviewed changes

uefi_capsule_generation/README.md Outdated Show resolved Hide resolved

mike-scott reviewed Sep 23, 2025

View reviewed changes

mike-scott suggested changes Sep 23, 2025

View reviewed changes

quicthogaru force-pushed the main branch 4 times, most recently from ba3d8d3 to f145bda Compare September 26, 2025 07:06

quicthogaru force-pushed the main branch from f145bda to f2b3f10 Compare September 26, 2025 07:10

igoropaniuk reviewed Oct 22, 2025

View reviewed changes

		*Once the FvUpdate.xml file is generated, please update the Operation to be performed on the each Firmware entry*<p>
		*By default the Operation type will be set to IGNORE*<p>

		- QCS8300 ESRT GUID: 8BF4424F-E842-409C-80BE-1418E91EF343<p>
		- QCS615 ESRT GUID: 9FD379D2-670E-4BB3-86A1-40497E6E17B0<p>


		3. Generate/Update FvUpdate.xml with Firmware entries:

		This script will generate FvUdpate.xml file, with Firmware Entries,

	This script will generate FvUdpate.xml file, with Firmware Entries,
	This script will generate the `FvUpdate.xml` file with firmware entries.

Uh oh!

Add Script to generate or update FvUpdate.xml file with Firmware entries #25

Are you sure you want to change the base?

Add Script to generate or update FvUpdate.xml file with Firmware entries #25

Uh oh!

Conversation

quicthogaru commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ricardosalveti commented Sep 22, 2025

Uh oh!

ricardosalveti commented Sep 22, 2025

Uh oh!

mike-scott commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mike-scott commented Sep 23, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mike-scott left a comment

Choose a reason for hiding this comment

Uh oh!

ricardosalveti commented Sep 29, 2025

Uh oh!

igoropaniuk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

quicthogaru commented Sep 22, 2025 •

edited

Loading

mike-scott commented Sep 23, 2025 •

edited

Loading