On Wed, Nov 04, 2026 at 04:57:03PM +0100, 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?
Yes. > 2. Is a subset parser like this OK, or would you prefer a generic > one in lib/? I think a subset is likely safer to validate than a generic one, so that's the better direction. -- Tom
signature.asc
Description: PGP signature
