Igor Opaniuk
fa60a80e42
The README had grown into one long page where the basic flashing workflow was buried between VIP, multi-programmer, ramdump, kickstart, WSL2 and raw sector guides. Keep only the generic material in the README and move each specialised workflow into its own file under docs/, linked from a new "Documentation" index. The moved text is unchanged apart from heading levels and two cross-references. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
1.6 KiB
Sahara kickstart for flashless-boot devices (qdl ks)
The qdl ks ("kickstart") subcommand uses the Sahara protocol to load
images from the host to the device. It targets flashless boot devices
such as the Qualcomm Cloud AI 100, which fetch their runtime firmware
from the host on every boot rather than storing it on-device.
Unlike normal flashing, kickstart stops once Sahara is done: no Firehose programmer is uploaded and nothing is written to storage.
One argument is required: -s id:path registers an image mapping. It
may be specified more than once, one mapping per Sahara image id the
device may request.
By default the device is found through the same backends the other
subcommands use, so --backend and --serial select it just as they do
when flashing:
qdl ks -s 13:prog_firehose_ddr.elf
Devices that a kernel driver exposes as a node instead - such as the MHI
Sahara endpoints - are addressed with -p, which is driven with plain
open/read/write operations rather than through a backend:
qdl ks -p /dev/mhi0_QAIC_SAHARA \
-s 1:/opt/qti-aic/firmware/fw1.bin \
-s 2:/opt/qti-aic/firmware/fw2.bin
Because -p names the transport outright, it cannot be combined with
--serial or --backend.
The mapped files do not need to exist at invocation time. If qdl ks
cannot open a requested file, the device decides the next action. This
makes it possible to wire qdl ks into a single udev rule that covers
multiple device configurations (for example, an optional DDR training
image that is only present on some setups).