Feature #379
closedMerging Minipro code for TL866xx programmers
0%
Description
David Hendricks (@David Hendricks) expressed interest in adding support in that particular issue.
I think that the programmer is quite somewhat different than most programmers supported in flashrom, since the programmer itself has a database of supported flash chips and abstracts more behind hardware. Which would mean that /include/flashchips.h isn't usable in this programmer.
There is a working open source implementation of flashing software named minipro[1], but sparsely packaged (Fedora and CentOS, only proposed in Debian) and only supports a single programmer, instead of flashrom which is more versatile. The code of minipro is GPLv3 and flashrom is GPLv2, which are incompatible licenses. Re-implementing the entire code would make implementing a lot more work. Any suggestions how to proceed here?
Updated by Bert Vermeulen 15 days ago
I've looked into this, and it's not a good match.
The TL866* and other products in that vendor's range are fundamentally not SPI writers, the way flashrom needs. The host client sends programmer-commands like "get JEDEC ID", with a protocol ID on how to talk to that particular flash chip. The protocol ID comes from its chip database, included in the vendor's client and extracted by minipro. You do not send SPI commands to this programmer, it handles those itself.
But flashrom wants to do that same thing by sending 0x9f (JEDEC_RDID) via SPI, and reading 3/4 bytes via SPI. In order for these programmers to work with flashrom, the driver would have to intercept the SPI command string and reinterpret it, somehow divine the protocol ID to use, then send the response back to flashrom as if it were received from SPI. In other words, emulate an SPI device for flashrom's benefit.
As if that wasn't a bad enough fit, the two most recent models (T56 and T76) now need chip-specific bits of FPGA gateware to be uploaded, so another thing that would have to be added to flashrom -- nearly 700 bitstreams and pointers to them in the chip structs.
I recommend closing this ticket with great haste.
Updated by Anastasia Klimchuk 9 days ago
- Status changed from New to Closed
Bert, thank you so much for your research here! I really appreciate it.
Sorry there was no reaction at all on this ticket. Somehow it was forgotten and never discussed :(
I read all of the info, I had one thought on the topic of
You do not send SPI commands to this programmer, it handles those itself.
There is thing in flashrom called "Opaque programmer" , which means the flashrom programmer implements whatever it needs in probe/read/write. As example there is linux_mtd.spi implementing opaque.
There is also a corresponding entry in flashchips which is called "Opaque flash chip" https://github.com/flashrom/flashrom/blob/main/flashchips.c#L121
Theoretically that could be a way to implement something special? This is indeed as Eloy said would be a lot of work, and no guarantee that it will work eventually.
The problem though, you mentioned incompatible licenses?
Another thing is programmer itself has a database of supported flash chips this is not great :\
I don't remember any discussions with David about this - but I will check with him, just in case.
For the ticket, I think I will listen to Bert and close it now.
If new great idea comes up, we can re-open it or create new one. But it would be rather re-implementing the code, not merging.
Updated by David Hendricks 8 days ago
Anastasia Klimchuk wrote in #note-3:
I don't remember any discussions with David about this - but I will check with him, just in case.
I don't remember either. Perhaps this idea came from a brief IRC discussion or something.
As Anastasia notes, we do have the notion of "opaque" programmers where flashrom itself does not issue common SPI NOR flash commands. However it seems that this programmer is rather special and I don't see a need to duplicate work that someone else has already done.