On 04/19/2016 10:18 PM, Carl-Daniel Hailfinger wrote:
You're introducing a new toplevel parameter for this, and I wonder whether it would make more sense to handle it as a programmer option. The dummy programmer supports reading in emulated flash chip content on startup and writing out emulated flash chip content on shutdown, all specified with -p dummy:emulate=M25P10.RES,image=foobar.bin
For consistency reasons, we should make sure that supplying assumed chip contents works as designed both for hardware-based programmers as well as the dummy programmer. I don't have a strong preference for -C or -p foobar:image=some.bin, and would like to hear what others think.
I strongly prefer a standalone toplevel option, as the feature is programmer independent. Of course, this means that for the dummy programmer we now have -C and -p image=some.bin. I don't consider it a bad thing, but a good thing. An important use case for the dummy programmer is to test flashrom under various conditions. This might be flashrom getting "-C" with the contents of the chip, or flashrom getting no "-C" and reading first. Both execution flows should be testable using the dummy programmer. On the other hand, separate options allow mismatch of "-C" and the image file specified in "-p dummy:image=some.bin". Specifying wrong chip contents is an undesireable situation one really wants to avoid in practice, because it causes flashrom to do unpredictable things. In my oppinion, we should nevertheless support getting into this situation with the dummy programmer, as we are equally able to get into that situation with real programmers. Yet a way to avoid the mismatch seems a good thing to have, too. So I suggest to have "-C" load the "actual contents" of the chip independently from any programmer option or any programmer code, but make it possible for the dummy programmer to initialize the emulated flash chip from the loaded "actual contents". Something like -p dummy:autoimage comes to my mind, although I understand that loading the "-C" can well be performed after programmer initialization, but initializing the emulated dummy flash chip is done during programmer initialization. I still tend to work around that in code (i.e. having the -C load before programmer init, even if it complicates the read/erase/program/verify logic).
Regards, Michael Karcher