Open
Conversation
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>
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_FLASH: 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_FLASH 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>
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
1 participant
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