Nico Huber 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)
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.
Maybe we should add a chip test mode to flashrom first. With all the possible Dedicrap programmers, hardware and firmware revisions we'll have a lot to test; or start to whitelist individual combi- nations :-/
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... I fear we have to get back to reverse engineering if we want reliable support for this crapware.
https://review.coreboot.org/#/c/28804/1/dediprog.c@399 PS1, Line 399: data_packet[3] = WRITE_MODE_4B_ADDR_256B_PAGE_PGM_0x12
For some reason I cannot explain, this needs to be WRITE_MODE_4B_ADDR_256B_PAGE_PGM. […]
Hard to tell... it's obviously redundant with data_packet[4]. I could imagine bad things. For instance they could have used hard-coded instructions first, and added data_packet[4] only later. Or maybe they try to cache and check the 4BA mode setting? who knows. I get the desperate feeling that we might need a more fine-grained version distinction.
-
Nico Huber (Code Review)