When distributing builds the user/developer is forced to determine which
programmer, program, patch files should be passed to QDL, to which
storage device each set should be programmed. This isn't user friendly
and it's prone of various forms of mistakes.
A solution to this problem can be found in the build artifacts of a
Qualcomm Windows-releases where a "flashmap" file describes the very
aspects we're looking for.
Implement support for parsing this json blob, populate the Sahara images
list based on the "programmer" information, parse the "program" and
"patch" files for each memory type and populate the firehose operations
queue with "configure", "program", and "patch" operations.
Introduce a new "flash" subcommand to trigger this new implementation:
qdl flash flashmap.json
In certain cases the user might want to only flash the subset of images
pertaining to a particular storage media - such as recovering their
spinor content. The user can through a suffix operation select which
storage media to flash, e.g.:
qdl flash flashmap.json::spinor,ufs
The json parser is derived from the implementation previously in use in
the pd-mapper userspace service, to avoid adding additional library
dependencies.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Continue the effort of unifying the firehose operations under a single
queue, by moving "patch" operations to the shared, client-provided,
list.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
For some reason qdl was written with open-coded linked list operations
throughout the implementation, resulting in ugly boiler plate code
sprinkled over the code base.
Integrate the linked list abstraction used in a few other of our
open-source projects to clean up the code.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Address all obvious coding style issues caught by checkpatch.pl tool.
sha2.c and sha2.h were kept as there are.
Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
Continuing the journey to make QDL not leak any memory on a successful
run, introduce operations to free the program and patch objects on
exit.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Assumed to be a remnant of early development lead to a recent transition
of "start_sector" from being represented as a string to an integer. But
it turns out that "start_sector" might be an expression, e.g. to write
something at the end of the disk.
So transition back to carry "start_sector" as a string.
Fixes: b6e0ea31d7 ("program: Make start_sector unsigned in")
Reported-by: Julien Robin
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
On some newer platforms the device ignore the configure request to
disable ZLP, causing the Firehose program request to stall, when the
device is waiting for a ZLP to end a transfer.
Mitigate this by circumventing the qcserial driver and drive the USB
traffic directly using USBFS. The tool will attempt to detach qcserial
from the device, in case it's already attached, so no changes are needed
in the kernel or system configuration.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Failures to apply program or patch operations are silently ignored,
forcing the user to inspect the logs to conclude if the flashing
succeded. Instead make the operations halt execution.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>