Re: [flashrom] [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
21 Jul
2011
21 Jul
'11
11:27 p.m.
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>
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/
21 Jul
21 Jul
11:55 p.m.
New subject: [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
On Thu, 21 Jul 2011 23:27:34 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> wrote:
Am 21.07.2011 17:54 schrieb Stefan Tauner:
did i mention that the man page needs an update? :P
--
Kind regards/Mit freundlichen Grüßen, 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>
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 
22 Jul
22 Jul
12:54 p.m.
New subject: [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
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> 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>
> >
>
> 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
4:11 p.m.
New subject: [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
Am 22.07.2011 12:54 schrieb Uwe Hermann:
On Thu, Jul 21, 2011 at 11:55:32PM +0200, Stefan
Tauner wrote:
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.
On Thu, 21 Jul 2011 23:27:34 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)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(a)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.
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.
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/
did i mention that the man page needs an update?
:P
That too, yes.
5:40 p.m.
New subject: [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
On Fri, 22 Jul 2011 16:11:22 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)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?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
25 Aug
25 Aug
4:55 p.m.
New subject: Annotate disabled features in manpage
On Fri, 22 Jul 2011 17:40:02 +0200
Stefan Tauner <stefan.tauner(a)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?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
26 Aug
26 Aug
2:34 p.m.
New subject: Annotate disabled features in manpage
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> wrote:
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>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
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?
27 Aug
27 Aug
2:10 a.m.
New subject: Annotate disabled features in manpage
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> wrote:
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/
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? 
9 May
9 May
9 a.m.
New subject: Annotate disabled features in manpage
On Tue, 27 Aug 2013 02:10:21 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)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.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
2365
days inactive
3388
days old
8 comments
5 participants
participants (5)
-
Carl-Daniel Hailfinger -
Joerg Mayer -
Stefan Tauner -
Stefan Tauner -
Uwe Hermann