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?