Update READMEHEADmain

Upstream has adopted something equivalent to my target-gen patches. You
don't need my fork anymore!

I'm attempting the "universal" algorithm, so talk about that.

1 files changed, 21 insertions, 7 deletions

diff --git a/README.md b/README.md
index 1f05bef..611b67c 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@ support a variety of MCUs and flash parts.
 These flash programming algorithms compete with NXP's flash programming
 algorithms, which are distributed in device family packs (DFPs). NXP's
 algorithms also work with probe-rs, so prefer those if you want something
-official.
+official (and probably better tested).
 
 I've found these algorithms can program flash 2x to 3x faster than NXP's
 offerings. These algorithms definitely support page crossings; meaning, if the
@@ -27,8 +27,7 @@ directories. Furthermore, those four boards have three different flash parts;
 the flash part implementation is in `src/` as part of the core package.
 
 Before attempting to generate the flash programming algorithms for [probe-rs],
-install the `target-gen` tool. It's available in the probe-rs repository. [My
-fork][probe-rs-fork] has some `target-gen` patches that might be useful.
+install the `target-gen` tool. It's available in the probe-rs repository.
 
 Use `target-gen test` to test each algorithm on its EVK. For convenience,
 there are dedicated Cargo configurations you can use. For example, to test the
@@ -52,13 +51,28 @@ To generate the algorithm for a different EVK, change the `--package` selection.
 [probe-rs]: https://probe.rs
 [probe-rs-fork]: https://github.com/mciantyre/probe-rs
 
-Eventually, I might try to define a universal flash programming algorithm,
-one that works across different flash parts. But for now, they're separate by
-manufacturer.
+Each flash algorithm should know how to work with all supported flash parts.
+The algorithm figures out which flash part you're using and varies some configs
+based on the part.
+
+Despite being somewhat dynamic, all flash parts are expected to support quad
+I/O for both reads and writes. The algorithm doesn't vary the kind of sequence
+its using. If your circuit doesn't use the additional I/O signals, you'll need
+to change the algorithm's source.
 
 FlexSPI pin muxing assumes you're using the boot ROM's primary FlexSPI1
 interface. In fact, all algorithms assume you're using FlexSPI1! If your board
 is doing something different, then you'll need to manually change the pin muxing
-/ FlexSPI instance. There's no board-by-board configuration.
+/ FlexSPI instance.
+
+I should eventually change the way the sequences are represented and how the IP
+commands work. Right now, sequences that need a "write enable" have them in the
+sequence itself. (That might be expected; see the way NXP's boot ROM encodes the
+sequences.) Another approach is to have a dedicated "write enable" sequence that
+software issues before the erase / program / write status IP command. That would
+reduce sequence usage in the LUT. I haven't been LUT constrained, so no need to
+do this right now.
+
+What to contribute? Send questions, thoughts, and commits via email.
 
 License: APACHE-2.0