I was able to test this and it works with one small change (see
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-
Patch Set #1, 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.
Patch Set #1, Line 399:
data_packet = 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. I could
imagine bad things. For instance they could have used hard-coded
instructions first, and added data_packet 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
To view, visit change 28804. To unsubscribe, or for help writing mail filters, visit settings.