Skip to content

Snagfactory: add sparse conversion, configurable USB timeout and UFS target support - #101

Merged
rgantois merged 3 commits into
bootlin:mainfrom
BakyarajM:qcom-feature-series
Oct 16, 2026
Merged

rgantois merged 3 commits into
bootlin:mainfrom
BakyarajM:qcom-feature-series

Conversation

@BakyarajM

@BakyarajM BakyarajM commented Sep 3, 2026 •

Copy link
Copy Markdown
Contributor

This PR introduces three enhancements to Snagfactory/Snagflash:

  1. Automatic sparse conversion for large images

    • Automatically converts raw images to Android sparse format when required.
    • Enables flashing images larger than the target Fastboot download limit.
    • Eliminates the need for users to manually convert images using external tools before flashing.
  2. Configurable USB re-enumeration timeout

    • Adds an optional usb-wait-timeout global configuration parameter.
    • Allows users to customize how long Snagfactory waits for the Fastboot USB device to reappear after U-Boot download.
    • Improves robustness on platforms with longer boot and USB re-enumeration times.
  3. UFS target-device support

    • Adds support for ufs<num> as a valid target-device value.
    • Treats UFS similarly to eMMC for device validation and erase block handling.
    • Rejects UFS usage for tasks "gpt", "flash", "mtd-parts" and "emmc-hwpart", which are not supported for UFS as of now and provides a clear error message directing users to use the run task with equivalent U-Boot scsi commands.

Signed-off-by: Bakyaraj Moorthy bmoorthy@qti.qualcomm.com

@rgantois rgantois left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Bakyaraj, thanks a lot for your contribution, this is a really well written patch set! :)

I has two comments, everything else looks good to me!

Comment thread docs/snagflash.md Resolved
The solution is to use the ``CHUNK_TYPE_DONTCARE``, which will skip some blocks of the output
partition in the beginning of the 2+ images.

Each split fragment is a fully valid, self-contained sparse file:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph doesn't seem related to the commit?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that this paragraph isn't strictly about the change introduced in this commit (automatic raw-to-sparse conversion). It documents a pre-existing property of the sparse-splitting logic (the prefix/suffix CHUNK_TYPE_DONTCARE padding and total_blks behavior) that was already implemented before this patch, but wasn't previously documented.

I added it here because the new "Splitting raw (non-sparse) files" section builds directly on top of this fragment-splitting behavior (it reuses the same prefix/suffix DONTCARE padding and size-accounting logic), so having it spelled out just above gives readers the full picture of how a fragment is structured before explaining how raw files reuse that same mechanism.

we can:

  • keep it as is (since it fills a documentation gap directly relevant to understanding the new raw-splitting section), or
  • move it into a separate follow-up commit/PR that documents the existing sparse-splitting behavior on its own, keeping this commit focused strictly on the raw-image conversion feature.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with keeping this in the current commit, however please add a small paragraph in the commit log to describe this change.

@BakyarajM BakyarajM Oct 15, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed. Modified the commit message.

Snagflash already supports flashing Android sparse images.
However, users currently need to convert raw images to sparse
format using an external tool before flashing when the image size
exceeds the target's Fastboot download limit (e.g. U-Boot's max
download size).

To simplify the workflow, automatically convert raw images to
Android sparse format during flashing and stream them as multiple
sparse chunks. This allows large images to be flashed successfully
without requiring the full image to fit within the target's download
buffer and eliminates the need for an external sparse conversion
step.

This introduces a new "flash_image" command which handles both raw
and sparse files transparently. "flash_sparse" is kept as an alias
of "flash_image" for backward compatibility.

docs/developers/android-sparse-file.md is also updated to document
the existing (previously undocumented) sparse-fragment splitting
behavior that the new raw-splitting logic builds on.

Signed-off-by: Bakyaraj Moorthy <bmoorthy@qti.qualcomm.com>
After snagrecover downloads U-Boot, snagflash immediately attempts to
reconnect over Fastboot. The existing get_usb() retry loop only waits
~9 seconds before giving up, which may be not enough time for previous
stage bootloader to exit, handover control to U-Boot, U-Boot to boot
and re-enumerate the Fastboot USB gadget.

Add an optional "usb-wait-timeout" global parameter to the Snagfactory
configuration file, specifying the number of seconds to wait for the
board's Fastboot USB device to reappear. This value is forwarded to
snagflash's fastboot() entry point and converted into a corresponding
number of get_usb() retries, overriding the default when set.

Signed-off-by: Bakyaraj Moorthy <bmoorthy@qti.qualcomm.com>
UFS is LBA-addressable like eMMC, so accept 'ufs' as
a target-device value and skip the eraseblk-size requirement for
it, same as for 'mmc<num>'.

However, U-Boot addresses UFS storage through the "scsi",
rather than the "mmc"-specific commands generated by the "gpt",
"flash", "mtd-parts" and "emmc-hwpart" tasks. Reject 'ufs'
targets for these tasks with a clear configuration error pointing
users to the "run" task, which can issue the equivalent raw commands
directly (e.g. "oem_run:gpt write scsi <dev> ...").

Signed-off-by: Bakyaraj Moorthy <bmoorthy@qti.qualcomm.com>
@BakyarajM
BakyarajM force-pushed the qcom-feature-series branch from 905c149 to 3fc9b0a Compare October 15, 2026 11:51
@BakyarajM
BakyarajM requested a review from rgantois October 15, 2026 11:52
@rgantois

Copy link
Copy Markdown
Collaborator

Thanks a lot!

@rgantois
rgantois merged commit 9a0b34d into bootlin:main Oct 16, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants