David Hendricks has posted comments on this change. ( https://review.coreboot.org/28804 )
Change subject: [WIP]dediprog: Implement 4-byte-address support ......................................................................
Patch Set 1:
(2 comments)
Patch Set 1:
(2 comments)
I was able to test this and it works with one small change (see comments).
I used an SF600 with firmware 7.2.21, with W25Q256JVFM and MX25L25735FMI and wrote to 1MB ranges in the lower and upper halves of the chip.
At least something works now...
Did you test the native instructions only? e.g. you could remove the native flags / erase functions (and in another step the enter 4BA flags) for your chip to test different paths.
I think so... I tried with only FEATURE_4BA_NATIVE enabled and I also tried with only FEATURE_4BA enabled, the former should have used native instructions only, right?
Maybe we should add a chip test mode to flashrom first.
Yes, I think that would be a great idea.
Built-in chip testing has been on my TODO list for a while. I hacked up something for testing write-protection capabilities a while back for CrOS flashrom: https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+...
With all the possible Dedicrap programmers, hardware and firmware revisions we'll have a lot to test; or start to whitelist individual combi- nations :-/
May as well start with what we know works.
https://review.coreboot.org/#/c/28804/1/dediprog.c File dediprog.c:
https://review.coreboot.org/#/c/28804/1/dediprog.c@390 PS1, Line 390: use_4ba = true;
So this path seems to have failed for Ron but succeeded for David... […]
It's worth noting that Ron also hacked it to only do slow reads. I think there is an issue in that path, though, as I was unable to successfully test the fmap patch using a dediprog because the binary search algorithm would always use small reads.
I'll need to investigate that some other time though.
https://review.coreboot.org/#/c/28804/1/dediprog.c@399 PS1, Line 399: data_packet[3] = WRITE_MODE_4B_ADDR_256B_PAGE_PGM_0x12
Hard to tell... it's obviously redundant with data_packet[4]. I could […]
Perhaps. But at least I have one known good configuration. Let's start with that.