-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for EDL mode for Qualcomm boards #87
Comments
We have discussed this several times. Frankly speaking, no. It is not clear how to protect the board from being randomly reflashed, how to prevent over-wearing the UFS by flashing it over and over, etc. EDL / QDL are a recovery procedures, while cdba targets a normally running device and a remotely-provided boot image. |
Fine with me. Thanks for clarifying. |
@lumag those are valid concerns, but it doesn't make sense to me that the tool dictates the rules - and it would be very useful to have this support in some settings (where e.g. wear leveling is feasible, or boards are partially/completely reflashed by the user in normal operation anyways) |
@andersson I think that EDL support might be implemented either as a separate host-only tool or as a special admin-only feature, being controlled by ACLs, etc. I really wouldn't like the users of my board farm to be able to reflash the boards remotely. Neither will anybody hosting the shared lab. It might make sense to allow |
Boards using Qualcomm chips can be booted to EDL (emergency download) mode for flashing the software. This can be done using for example qdl. IIUC adding EDL mode support would require quite a few changes in the state machine:
https://github.com/linux-msm/cdba/blob/master/device.c#L182
Would this be something that can be accepted to cdba?
The text was updated successfully, but these errors were encountered: