For linux msm/flashing support#91
Open
andersson wants to merge 8 commits into
Open
Conversation
andersson
force-pushed
the
for-linux-msm/flashing-support
branch
from
d3188a2 to
1322ab3
Compare
Moving between the Linux kernel's list.h and this one is confusing, as list_add() prepends in one case and appends in the other. Rename the function to clarify the API. Introduce an operation for those cases where a prepend is desired. Also introduce a list_len() operation, which can be useful to save clients from open-coding this. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
In order to implement flash support, as well as aid in maintenance situations, support for requesting the board to be powered on into EDL/flashing mode is useful. So far the payload of the MSG_POWER_ON message has been ignored by the server, so we can tread the absence of payload as "NORMAL" power on request and introduce the power_on_mode enumeration to define the values in this (optional) byte. A new key definition is also added to the protocol, representing the holding down the EDL "key", but not exposed on the client side yet. The device logic is wired up such that the power-on sequence will now request the drivers to hold the EDL key while powering on, if the power-on mode is "EDL". Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
When the EDL key is held during power up, the device will enter EDL mode, making the board ready for firmware flashing. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
quic-bjorande
force-pushed
the
for-linux-msm/flashing-support
branch
from
1322ab3 to
fd9c1e6
Compare
superna9999
reviewed
May 12, 2026
| execvp("qdl", (char **)argv); | ||
| err(127, "failed to spawn qdl"); | ||
| } | ||
| wait(NULL); |
There was a problem hiding this comment.
I think we need to bump the timeout timer somewhere around here,, as qdl flashing may take a very long time
Collaborator
Author
There was a problem hiding this comment.
Good point, although the timeout is client side - and the question is how much time one should implicitly allocate for this operation.
There was a problem hiding this comment.
Maybe we could utilize cdba's ux_progress and wait max(default_timeout, user_timeout) between each response?
Contributor
There was a problem hiding this comment.
Right, the flash process does provide log output which results in a stream of updates for which we could nudge the inactivity timeout. It's arriving on stderr though, for which we today don't nudge the timeout. In the event that the flash process is silent (like in cdba-axiom), this could become a problem - but perhaps worth looking at separately.
The other case where we do have a problem is the upload of large images, both MSG_FASTBOOT_DOWNLOAD and MSG_EDL_DOWNLOAD will produce a stream of packets only on "stdin", which also doesn't nudge the inactivity timeout.
It seems conceptually reasonable to me to nudge the inactivity timeout in both these cases; they are both signs of activity.
quic-bjorande
force-pushed
the
for-linux-msm/flashing-support
branch
from
fd9c1e6 to
9243675
Compare
The client can now request the device to enter EDL mode and the server's device and driver model can power up the board to this state. Introduce four new messages to the cdba protocol: - EDL_PRESENT: used by the server to signal the presence of the EDL device - EDL_DOWNLOAD: used by the client to transfer a binary blob to the server, mimicing the fastboot protocol - EDL_WRITE: used by the client to indicate the target for the downloaded binary blob. The server may start flashing the image if supported. - EDL_RESET: used by the client to request that the flash operations are finalized and the board restarts. Introduce a new "EDL" module that will look for EDL USB devices and if found signal the client about its presence. Implement EDL_DOWNLOAD by streaming the incoming blob into a temporary file, let EDL_WRITE tag the image with information about where it should be written. Then as we're relying on QDL, invoke the external tool as part of the EDL_RESET, "flushing out" the pending operations. Support for matching EDL device by serial number is left as a todo item. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
For some unknown reason, when I wrote this I choose to build the outgoing messages in an event-based manner, queuing the operation that will produce the message, rather than just queuing the message directly. Let's simplify this by just queueing the actual messages directly and change the main loop to simply drain the queue. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
The boot payload can be massive (GBs) so queueing it upfront will consume a lot of RAM, unnecessarily. Allow the transmit queue to carry references to a file descriptor instead of the actual payload. As the queue is consumed each chunk is read from the file and transmitted. As we use zero-length messages to represent EOF, let's use that as our signal for closing the file descriptor as well. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
With the server supporting alternative power-on mechanisms, EDL notifications and flashing support, the client interface can now be implemented. Allow a series of "write <target> <image>" arguments on the command line register images and their target. Request the server to power on the device into the newly supported EDL state, then as the EDL notification arrives push the images and request them to be flashed by the server. It is assumed that the flashing operations is only desired on the first discovery of a device in EDL mode at this time, as test-scenarios across reboot typically doesn't involve resetting storage content. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
quic-bjorande
force-pushed
the
for-linux-msm/flashing-support
branch
from
9243675 to
1691c3a
Compare
The inactivity timeout is only bumped on incoming messages on stdout. But during upload of images (MSG_FASTBOOT_DOWNLOAD or MSG_EDL_DOWNLOAD) there is no traffic on stdout. Likewise MSG_EDL_WRITE would trigger the write of an image to the storage media, which will emit updated on stderr. Both of these additional pipes represents activity, so let's bump the timeout there as well. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
quic-kdybcio
approved these changes
May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Being able to flash images across cdba enables new use cases, such as bootstrapping development boards directly in a cdba lab. Some features are still missing, like serial number matching - and it would be very useful to have a progress bar when transferring gigabytes of data, but these can be added incrementally.
The end result is the ability to run:
cdba -b board -h host write 0 fastboot.img boot.img