spiflash: n-byte addressing, vendor commands, ID extension byte handling#125
Open
karlp wants to merge 11 commits intosigrokproject:masterfrom
Open
spiflash: n-byte addressing, vendor commands, ID extension byte handling#125karlp wants to merge 11 commits intosigrokproject:masterfrom
karlp wants to merge 11 commits intosigrokproject:masterfrom
Conversation
Previously dropdown was random sorted each run. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
Old code assumed that RDID only ever returned 3 bytes. Depending on the vendor page assigned in JEDEC, you will actually get extension codes of 0x7f to reach the correct page. Tested with an Infineon FRAM part, "The JEDEC-assigned manufacturer ID places the Cypress (Ramtron) identifier in bank 7; therefore, there are six bytes of the continuation code 7Fh followed by the single byte C2h." Signed-off-by: Karl Palsson <karl.palsson@marel.com>
Some (many?) larger flash chips support being switched into 4 byte mode, and then using the same "regular" 3 byte addressing commands. Some parts also use "regular" addressing commands with only 2 byte addressing. Sometimes this can be set by selecting a device, or interpreting the commands as they are seen, but you cannot guarantee that a trace will include mode switch commands, so allow it to be set up front when needed. Tested with a Micron MT25QL512 and an Infineon FM25V02A. (4 byte variable and 2 byte fixed) TODO: this doesn't change the formatting of addresses at this point. TODO: some of the two bit modes aren't handled either. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
Signed-off-by: Karl Palsson <karl.palsson@marel.com>
It's not really very pretty, but it's an attempt at least. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
Less duplication, less chances for copy pasta bugs. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
Original code would try and output an annotation with es well in the past, resulting in a sliver that couldn't be zoomed in on. Instead, correctly update the end of the command as is done with other commands, and wait to output the warning until we've finished with the command entirely. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
This overhauls the data tables to make them a little bit easier to work with in the future, by using classes, instead of big string dicts. The old code was a little mixed between showing the RDID results, or showing what had been selected, so make that clear, and use warnings if things aren't as we expect. We also warn if the selected part doesn't provide IDs, but we saw one anyway. Decoding _may_ be just fine, but it may be wrong. Checked also with sigrok-dumps for parts without rdid. For "manufacturer" id, we've gone with keeping tables in the style of memtest86, using an upper byte for the page number, rather than trying to keep literals like "0x7f7f7f7f7f7fc2" or similar ala flashrom. TODO: this does _not_ overhaul the related rems/res/rdp style ID decoding, but that really needs similar treatment. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
This was in the dumps repo, so add it for decoding purposes. Signed-off-by: Karl Palsson <karl.palsson@marel.com>
We don't have a good way of passing this to specific implementations yet, but at least don't choke on it, and present it properly. Tested on the https://github.com/sigrokproject/sigrok-dumps/tree/master/spi/spiflash/adesto_at45db161e test files Signed-off-by: Karl Palsson <karl.palsson@marel.com>
While overhauling the data structure, we postponed fully checking the alternative "ID" commands. This updates them, tested against various dumps in the dumsp repo: * spi/spiflash/fidelix_fm25q32/cmd/0xab.sr * spi/spiflash/macronix_mx25l1605d/cmd/0x90.sr Signed-off-by: Karl Palsson <karl.palsson@marel.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.
The vendor specific command handling is "probably" not really very pretty, but it's a start in the right direction? Shared here for sharing... The big ugly part of it is that annotations have to be declared permanently before we know what chip is in use, so we have to pre-supply all 256 plausible command bytes with stub text, which can't be replaced later. (This mostly affects the checklist drop downs to select hiding specific annotations)
the sorting, rdid extensions, and n-byte addressing are all good to go.