Re: [flashrom] [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
Am 21.07.2011 17:54 schrieb Stefan Tauner:
previously the dummies were initialized to be empty (all ones), which makes writes skip erasing altogether. with this patch the default is to fill it with random bytes instead and the old behavior can be enforced with stating "empty=yes" on the command line.
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
Regards, Carl-Daniel
On Thu, 21 Jul 2011 23:27:34 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 21.07.2011 17:54 schrieb Stefan Tauner:
previously the dummies were initialized to be empty (all ones), which makes writes skip erasing altogether. with this patch the default is to fill it with random bytes instead and the old behavior can be enforced with stating "empty=yes" on the command line.
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
did i mention that the man page needs an update? :P
On Thu, Jul 21, 2011 at 11:55:32PM +0200, Stefan Tauner wrote:
On Thu, 21 Jul 2011 23:27:34 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 21.07.2011 17:54 schrieb Stefan Tauner:
previously the dummies were initialized to be empty (all ones), which makes writes skip erasing altogether. with this patch the default is to fill it with random bytes instead and the old behavior can be enforced with stating "empty=yes" on the command line.
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
Works fine here, but having a commandline option such as the "content=..." in the updated patch is worthwhile IMHO, it saves the user quite some unneeded hassle to create dummy images on a filesystem, which is possibly even a bit harder on DOS or elsewhere due to missing dd and so on. Also in the qflashrom GUI I'd personally like to be able to present the user with a drop-down of possible dummy chip contents (which are autogenerated by libflashrom).
The "image=" option should stay of course, it's very useful too, e.g. for specially crafted test images etc. But for a few simple cases such as 0x00, 0xff, random, etc. the "content=" option makes sense, IMHO.
did i mention that the man page needs an update? :P
That too, yes.
Uwe.
Am 22.07.2011 12:54 schrieb Uwe Hermann:
On Thu, Jul 21, 2011 at 11:55:32PM +0200, Stefan Tauner wrote:
On Thu, 21 Jul 2011 23:27:34 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 21.07.2011 17:54 schrieb Stefan Tauner:
previously the dummies were initialized to be empty (all ones), which makes writes skip erasing altogether. with this patch the default is to fill it with random bytes instead and the old behavior can be enforced with stating "empty=yes" on the command line.
Signed-off-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
Works fine here, but having a commandline option such as the "content=..." in the updated patch is worthwhile IMHO, it saves the user quite some unneeded hassle to create dummy images on a filesystem,
Which user? Nobody except the active flashrom developers will ever test dummyflasher on DOS, and I hope our skills are not so limited that copying oldimage.bin to the same directory as flashrom.exe is impossible for us.
which is possibly even a bit harder on DOS or elsewhere due to missing dd and so on.
Then generate it on Linux where you cross-compile the DOS binary.
Also in the qflashrom GUI I'd personally like to be able to present the user with a drop-down of possible dummy chip contents (which are autogenerated by libflashrom).
You could use the pattern generator which is already present in flashrom, and write the generated pattern to a file which is supplied for flashing. That way, you can use those patterns for real programmers as well. The current content=/empty= proposal has zero benefits outside dummyflasher, and for that you can use dd or the pattern generator anyway.
The "image=" option should stay of course, it's very useful too, e.g. for specially crafted test images etc. But for a few simple cases such as 0x00, 0xff, random, etc. the "content=" option makes sense, IMHO.
did i mention that the man page needs an update? :P
That too, yes.
I should have sent a man page patch for that last night. No idea why it didn't show up. Let me check and resend.
Regards, Carl-Daniel
On Fri, 22 Jul 2011 16:11:22 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 22.07.2011 12:54 schrieb Uwe Hermann:
You could use the pattern generator which is already present in flashrom, and write the generated pattern to a file which is supplied for flashing. That way, you can use those patterns for real programmers as well. The current content=/empty= proposal has zero benefits outside dummyflasher, and for that you can use dd or the pattern generator anyway.
i have looked at the pattern generator it does not provide a random pattern yet. the 0xff and 0x00 patterns are spoiled by /* Write block number in the last two bytes of each 256-byte * block, big endian for easier reading of the hexdump.
but besides that it looks like i could easily integrate the pattern generator into my patch. i would add a all 0xff, all 0x00 and random pattern to it and add parsing for the other pattern types (or at least some? which?) to the content= parameter handling. later we may add a special handling for -r/-w/-v so that these test patterns could be used with all programmers not only with dummy. of course this can be done with files too... but it looks very easy to implement directly (i.e. not much additional code), so why not?
I should have sent a man page patch for that last night. No idea why it didn't show up. Let me check and resend.
hm i was working on an update too... will follow up yours then.
btw i was thinking about using some kind of preprocessor to mark features in the man page that are not compiled in the "current" configuration. groff may be even able to handle it itself, but using the cpp seems like an option too. not sure if clang would handle it correctly without printing unwanted output though...
the basic idea is that features that are not compiled in get a note or warning in the man page to make clear that there is such a feature, but that it is currently disabled. what do you think?
On Fri, 22 Jul 2011 17:40:02 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
btw i was thinking about using some kind of preprocessor to mark features in the man page that are not compiled in the "current" configuration. groff may be even able to handle it itself, but using the cpp seems like an option too. not sure if clang would handle it correctly without printing unwanted output though...
the basic idea is that features that are not compiled in get a note or warning in the man page to make clear that there is such a feature, but that it is currently disabled. what do you think?
Since we'll generate the manpage soon anyway... any opinions on the idea above?
On Sun, Aug 25, 2013 at 04:55:02PM +0200, Stefan Tauner wrote:
On Fri, 22 Jul 2011 17:40:02 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
btw i was thinking about using some kind of preprocessor to mark features in the man page that are not compiled in the "current" configuration. groff may be even able to handle it itself, but using the cpp seems like an option too. not sure if clang would handle it correctly without printing unwanted output though...
the basic idea is that features that are not compiled in get a note or warning in the man page to make clear that there is such a feature, but that it is currently disabled. what do you think?
Since we'll generate the manpage soon anyway... any opinions on the idea above?
I'm not too happy with that idea, as binary and manpage are not always installed in sync (I that this is a user/admin error, but still). How about adding this to the --help output: At the very bottom: "Disabled features: ...." and reference that in the manpage or add it to the manpage but add a sentence like 'To be sure, run "flashrom --help" and check the section "Disabled features"'.
Ciao Jörg
Am 25.08.2013 16:55 schrieb Stefan Tauner:
On Fri, 22 Jul 2011 17:40:02 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
btw i was thinking about using some kind of preprocessor to mark features in the man page that are not compiled in the "current" configuration. groff may be even able to handle it itself, but using the cpp seems like an option too. not sure if clang would handle it correctly without printing unwanted output though...
the basic idea is that features that are not compiled in get a note or warning in the man page to make clear that there is such a feature, but that it is currently disabled. what do you think?
Since we'll generate the manpage soon anyway... any opinions on the idea above?
I'd rather not do that. If a user specifies a disabled programmer, he/she will get a useful error message anyway, and flashrom --help does helpfully list all supported programmers. We could indicate that in the man page, but other than that I'd rather have every existing programmer driver documented in the man page. That way users will see all flashrom features even if the system vendor has decided to disable some feature.
Regards, Carl-Daniel
On Tue, 27 Aug 2013 02:10:21 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If a user specifies a disabled programmer, he/she will get a useful error message anyway, and flashrom --help does helpfully list all supported programmers.
I have noticed that this is not completely true. The list of supported mainboards is only compiled in for x86, hence -L does (debatably) not list all supported programmers.
-
Carl-Daniel Hailfinger -
Joerg Mayer -
Stefan Tauner -
Stefan Tauner -
Uwe Hermann