+u-boot-qcom list On 04/11/2026 16:57, Igor Opaniuk wrote: > Hi all, > > I'd like to run an idea past the U-Boot community before writing any code. > It touches the USB gadget layer, block devices and a protocol U-Boot > has never spoken, and I'm sure your feedback can save us from wrong > turns early on. > > Some background first. Every Qualcomm SoC has an Emergency Download > (EDL) mode in its boot ROM (PBL). It is entered when no valid > bootloader is found, or on request (button, test point, reboot > reason). In EDL the SoC enumerates on USB as 05c6:9008 and speaks > Sahara, a simple protocol for uploading an image into On-Chip RAM. The host > uses Sahara to upload a "programmer", a SoC-specific > Qualcomm binary (prog_firehose_*.elf) that sets up DDR and storage > and then serves Firehose. Firehose is the actual flashing protocol: > the host sends small XML commands (<configure>, <program>, <read>, > <erase>, <patch>, ...) over USB bulk, the device answers with > <response value="ACK|NAK"/> and <log/>, and sector data goes in raw > binary between them. This is how Qualcomm boards are flashed in the > factory and unbricked in the field with qdl [1]. > > We are moving Qualcomm boards to an open boot stack: after the stock > XBL, TF-A (BL2/BL31), OP-TEE and U-Boot replace the proprietary TZ > and UEFI stages. The Arduino UNO Q (QRB2210) PoC boots this way, > and the platform support is going upstream in each project. With > U-Boot in the boot chain anyway, we'd like to reuse it as the > programmer image too, instead of shipping a separate closed one. The > code that boots the board would then also flash it. > > Hence this RFC, before I write the code: would a Firehose server in > U-Boot (a "firehose" command) be welcome > U-Boot community, so that the existing host tools can flash a board with > U-Boot as the programmer? > > Why not fastboot: Firehose works on raw storage, not on named > partitions. It addresses any physical partition or UFS LUN by sector, > creates the GPT from scratch (rawprogram/patch XML, sized to the > device), provisions UFS, reads back and verifies with SHA-256, and > selects the boot partition. Qualcomm's build and factory flows already > produce these XML files, so a board flashes the same way from EDL or > from U-Boot. > > Two ways in: > 1. Recovery, as snagrecover does it: the PBL loads a DDR-init-only XBL > over Sahara, that XBL loads U-Boot, and U-Boot runs the Firehose "server". > 2. From an installed U-Boot, like ums: > => firehose 0 > and then on the host machine: > $ qdl --storage emmc <devprg image> rawprogram0.xml patch0.xml > > The first version covers configure/program/read/erase/patch/ > getsha256digest/power over the blk API, with eMMC hardware partitions > as physical partitions. UFS provisioning would come later. > > Main concern is XML. Firehose only needs one element per document, > with attributes and no nesting: > <?xml version="1.0" ?><data><program A="v" ... /></data> > I'd write a small in-place parser for exactly this subset (about 150 > lines, input capped at 4 KiB, sandbox tests with malformed input) > instead of importing a library. > > Questions: > 1. Is a Firehose server acceptable next to ums/fastboot/rockusb? > 2. Is a subset parser like this OK, or would you prefer a generic > one in lib/?
Sounds great, dfu/uuu are also similar in goal. Having U-Boot images we can boot through EDL in any form is a huge step. A firehose command sounds like the right approach. Please be aware that patch descriptions, cover letters, etc should be written by hand, LLM prose is noisy and hard to parse, it often leaks irrelevant context. > > > Thank you for your comments > > Best regards, > Igor > > [1] https://github.com/linux-msm/qdl -- // Casey (she/her)
