Hi Igor, On Wed, Nov 04, 2026 at 13:15, Tom Rini <[email protected]> wrote:
> 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. Thanks for the details. This is very helpful. >> >> Questions: >> 1. Is a Firehose server acceptable next to ums/fastboot/rockusb? > > Yes. I agree with Tom here. This is a welcome addition. We already have vendor specific U-Boot commands for flashing (rockusb/thordown). > >> 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. I agree, I'd prefer a subset as well. It will be easier to review and it won't be yet another project we need to sync from another location every release. > > -- > Tom
