sahara: add chipinfo command to read chip identity#280
Open
igoropaniuk wants to merge 2 commits into
Open
Conversation
The success line for a matched EDL device is emitted at open time, before any data is transferred, and it is shared by every operation that opens a device - including read-only ones like the new chipinfo query. Labelling that moment "Flashing" is inaccurate: nothing is being flashed yet, and for a pure query nothing will be. Use the operation-neutral verb "Talking to", which is accurate at connect time regardless of what follows. The crash-dump wording for the 0x900e product ID is left untouched, as it remains specific and correct. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
QDL only ever drives Sahara in its image-transfer and memory-debug modes. Sahara also defines a command mode that lets the primary bootloader be queried for the device's identity before any programmer is uploaded. Expose that as a new "chipinfo" subcommand. It enters command mode by requesting SAHARA_MODE_COMMAND in the HELLO response and echoing the device's advertised protocol version, then drives EXECUTE transactions to read the chip serial number, the HW ID (broken out into MSM_ID / OEM_ID / MODEL_ID) and the OEM PK hash. Version 3 targets no longer answer MSM_HW_ID_READ, so the same fields are recovered through READ_CHIP_ID_V3 on those devices. Command mode is left by switching back to image-transfer mode, which returns the device to its power-on HELLO state and keeps it usable for a subsequent query or flash. A Sahara reset is deliberately avoided here: on some targets it leaves the device enumerated on PID 0x9008 but no longer answering Sahara until it is power-cycled back into EDL. This is handy for identifying an attached target and, in particular, for troubleshooting secure-boot provisioning: the fused OEM PK hash and OEM ID can be read straight from the PBL without loading a programmer. Signed-off-by: Igor Opaniuk <igor.opaniuk@oss.qualcomm.com>
3454f58 to
687b242
Compare
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
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.
QDL only ever drives Sahara in its image-transfer and memory-debug
modes. Sahara also defines a command mode that lets the primary
bootloader be queried for the device's identity before any programmer
is uploaded. Expose that as a new "chipinfo" subcommand.
It enters command mode by requesting SAHARA_MODE_COMMAND in the HELLO
response and echoing the device's advertised protocol version, then
drives EXECUTE transactions to read the chip serial number, the HW ID
(broken out into MSM_ID / OEM_ID / MODEL_ID) and the OEM PK hash.
Version 3 targets no longer answer MSM_HW_ID_READ, so the same fields
are recovered through READ_CHIP_ID_V3 on those devices.
Command mode is left by switching back to image-transfer mode, which
returns the device to its power-on HELLO state and keeps it usable for
a subsequent query or flash. A Sahara reset is deliberately avoided
here: on some targets it leaves the device enumerated on PID 0x9008 but
no longer answering Sahara until it is power-cycled back into EDL.
This is handy for identifying an attached target and, in particular,
for troubleshooting secure-boot provisioning: the fused OEM PK hash and
OEM ID can be read straight from the PBL without loading a programmer.