Re: [flashrom] [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default

[Carl-Daniel Hailfinger]

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(a)student.tuwien.ac.at&gt;
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

-- 
http://www.hailfinger.org/

[PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default

[Stefan Tauner]

On Thu, 21 Jul 2011 23:27:34 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net&gt; 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(a)student.tuwien.ac.at&gt;
 >   
 
 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
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

[PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default

[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(a)gmx.net&gt; 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(a)student.tuwien.ac.at&gt;
 > >   
 > 
 > 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.
-- 
http://hermann-uwe.de     | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org

[PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default

[Carl-Daniel Hailfinger]

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(a)gmx.net&gt; 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(a)student.tuwien.ac.at&gt;
>>>   
>>>         
>> 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

-- 
http://www.hailfinger.org/

[PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default

[Stefan Tauner]

On Fri, 22 Jul 2011 16:11:22 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net&gt; 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?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Annotate disabled features in manpage

[Stefan Tauner]

On Fri, 22 Jul 2011 17:40:02 +0200
Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at&gt; 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?
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Annotate disabled features in manpage

[Joerg Mayer]

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(a)student.tuwien.ac.at&gt; 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

-- 
Joerg Mayer                                           <jmayer(a)loplof.de&gt;
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

Annotate disabled features in manpage

[Carl-Daniel Hailfinger]

Am 25.08.2013 16:55 schrieb Stefan Tauner:
 On Fri, 22 Jul 2011 17:40:02 +0200
 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at&gt; 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

-- 
http://www.hailfinger.org/

Annotate disabled features in manpage

[Stefan Tauner]

On Tue, 27 Aug 2013 02:10:21 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net&gt; 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.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner