Serprog future, 32bit addressing, and I'd like to get rid of write+poll sequences for each byte...

[Urja Rannikko]

Hi,

So Stefan suggested that serprog should switch to 32-bit addressing
and do it with a change of protocol version, thus creating a
compatibility boundary
and also significantly slowing down the case of 1-byte writes
(write_jedec_1, write_28sf040, write_82802ab, ... also
write_en29lv640b but that writes 16bit words*)

but with the positive side of keeping the flashrom serprog driver
simpler in that sense (no supoprt code for old 24bit)...

I had different ideas (either a 2-byte command to switch the highest
byte of the address or just a bunch of new 32bit addressing commands),
but I thought about it for a moment, trying to find
what would be needed for the protocol version change to be OK with me:

1. frser-duino (and other SPI-only) being about the only serprog
firmware not used only by developers should continue to work; in
essense we'd allow protocol version 1 if supported bustypes is only
SPI because for SPI-only functionality the versions would be identical
(maybe if contains SPI and other mask only to SPI and print warning,
but i dunno.) - I'd switch the libfrser SPI-only build to announce
version 2 much later (if at all), in essense when most distributed
flashrom versions would've gotten the version 2 support.

2. We should get rid of write_jedec_1 resulting in a huge sequence of
1-byte writes (and polls) being sent to the programmer - this is the
case that the bigger addressing would noticeably impact (with like 5
ops with address per byte written). Also, I'm now assuming this would
be after we get something like the write_jedec_1 changes and poll
opcode supoprt
I've made here:
https://github.com/urjaman/flashrom/commits/serprog-improvements into
flashrom. I'll try to look at them again and clean that up into a
patch sequence for review/comments in the meantime.

So my suggestion/idea is that we'd essentially hint the programmer
code about the 1-byte write sequence being done, kinda something like
this:

static int write_byte_program_jedec_common(const struct flashctx
*flash, const uint8_t *src,
                                           chipaddr dst, unsigned int mask)
{
        chipaddr bios = flash->virtual_memory;
        chip_hint(BYTE_PGM_START);
        /* Issue JEDEC Byte Program command */
        start_program_jedec_common(flash, mask);
        chip_hint(BYTE_PGM_DATA_ADDR_DATA_BYTE);
        /* transfer data from source to destination */
        chip_writeb(flash, *src, dst);
        toggle_ready_jedec(flash, bios);
        chip_hint(BYTE_PGM_END);
        return 0;
}

where each hint (except start/end just to contain the sequence) would
only affect the next
operation (write or poll) done, and the possible options would be:
immediate/const address and data (default if no hint)
variable address (const data) (this'd be used by the 82802b and 28sf040 stuff)
variable data (const address) (no use for this afaik but these can be
implemented as 2 bits that allow this).
variable address and data

where "variable" means the address and data of the byte being written
and const being just embedded into the sequence that is repeated for
each byte.

Serprog code would create the sequence for writing the byte on the first byte
and transfer it into the device and on subsequent bytes just verify
that the sequence hasnt changed (if has, send a new sequence - this
would allow the sequence to contain stuff like a page address, as long
as it doesnt change on every byte) and compile these programming
writeb's into an extended write-n command that'd be sent to the device
where each byte would represent going through the sequence stored
previously with new address and data for that byte.

* write_en29lv640b: I dunno what do do about this for this case...
maybe just leave it as is until somebody has one and wants to test
stuff...I mean we could design the serprog protocol to allow hinting
of 2-byte sequences too...

So, comments?