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/+/386428

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.

View Change

2 comments:

• File dediprog.c:

  • Patch Set #1, 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.

  • Patch Set #1, 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.

To view, visit change 28804. To unsubscribe, or for help writing mail filters, visit settings.