| Submitter | Willy Tarreau |
|---|---|
| Date | 2015-09-10 21:13:36 |
| Message ID | <20150910211336.GA14424@1wt.eu> |
| Download | mbox | patch |
| Permalink | /patch/4321/ |
| State | New |
| Headers | show |
Comments
Hi Willy, You might be interested in another approach that is used in the chromium branch <https://chromium.googlesource.com/chromiumos/third_party/flashrom>. The "--diff" longopt allows the user to supply a file to diff against the -w argument. This is useful in cases where the user wishes to skip the initial read step, and flashrom will figure out which blocks need to be erased and written thereby eliminating unnecessary erase/write operations as well. There is some documentation for it here: https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom#TOC-Speeding-Up-Writes On Thu, Sep 10, 2015 at 2:13 PM, Willy Tarreau <w@1wt.eu> wrote: > Hello, > > I was bothered by having to read all the contents of an empty flash > before programming just a boot loader to it. It's particularly long > when using a buspirate board. I looked into the code to see how to > bypass this and discovered it was already planned but not implemented > due to the (presumably) complex API of the doit() function. > > I took a different route : I'm using 3 different write levels in write_it: > - normal write (read first) > - trusted write (no need to read but still erase) > - fully trusted write (flash assumed to be clean) > > These ones are set using a new "-t" flag for which I have even updated > the man page and indicated that it's not recommended. > > It worked well for me so I'm sending the patches assuming they'll be > useful for someone else. > > BTW, to give you a bit more context, I was writing a 8MB flash to upgrade > a small router from its 4MB one, so I just had to add 4MB of \xff after the > existing image before flashing it. > > Best regards, > Willy > > > _______________________________________________ > flashrom mailing list > flashrom@flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >
Hi David, On Mon, Sep 14, 2015 at 11:10:31AM -0700, David Hendricks wrote: > Hi Willy, > You might be interested in another approach that is used in the chromium > branch <https://chromium.googlesource.com/chromiumos/third_party/flashrom>. > The "--diff" longopt allows the user to supply a file to diff against the > -w argument. This is useful in cases where the user wishes to skip the > initial read step, and flashrom will figure out which blocks need to be > erased and written thereby eliminating unnecessary erase/write operations > as well. > > There is some documentation for it here: > https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom#TOC-Speeding-Up-Writes Thank you I'll take a look at it, it can indeed be another solution. The only thing is that it requires the creation of an extra file and I tend to find that it's not always convenient to have to create files for known patterns. However I think that it would be possible based on your approach to provide an option to replace the file with a known pattern for some cases (eg: full of 0xff or full of 0x00, which could be called "assume-clean" or "assume-dirty"), which would achieve the same result and at the same time not change the spirit of your latest work. Best regards, Willy
Please also see layout patches - https://github.com/stefanct/flashrom/pull/3 + https://github.com/stefanct/flashrom/pull/4 Best regards, Anton Kochkov. On Mon, Sep 14, 2015 at 9:18 PM, Willy Tarreau <w@1wt.eu> wrote: > Hi David, > > On Mon, Sep 14, 2015 at 11:10:31AM -0700, David Hendricks wrote: >> Hi Willy, >> You might be interested in another approach that is used in the chromium >> branch <https://chromium.googlesource.com/chromiumos/third_party/flashrom>. >> The "--diff" longopt allows the user to supply a file to diff against the >> -w argument. This is useful in cases where the user wishes to skip the >> initial read step, and flashrom will figure out which blocks need to be >> erased and written thereby eliminating unnecessary erase/write operations >> as well. >> >> There is some documentation for it here: >> https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom#TOC-Speeding-Up-Writes > > Thank you I'll take a look at it, it can indeed be another solution. The > only thing is that it requires the creation of an extra file and I tend to > find that it's not always convenient to have to create files for known > patterns. However I think that it would be possible based on your > approach to provide an option to replace the file with a known pattern > for some cases (eg: full of 0xff or full of 0x00, which could be called > "assume-clean" or "assume-dirty"), which would achieve the same result > and at the same time not change the spirit of your latest work. > > Best regards, > Willy > > > _______________________________________________ > flashrom mailing list > flashrom@flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom
Patch
diff --git a/flashrom.c b/flashrom.c index a389cb2..fdd95c3 100644 --- a/flashrom.c +++ b/flashrom.c @@ -2020,8 +2020,8 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_cinfo("FAILED.\n"); goto out; } + msg_cinfo("done.\n"); } - msg_cinfo("done.\n"); /* Build a new image taking the given layout into account. */ if (build_new_image(flash, read_all_first, oldcontents, newcontents)) {
Hello, I was bothered by having to read all the contents of an empty flash before programming just a boot loader to it. It's particularly long when using a buspirate board. I looked into the code to see how to bypass this and discovered it was already planned but not implemented due to the (presumably) complex API of the doit() function. I took a different route : I'm using 3 different write levels in write_it: - normal write (read first) - trusted write (no need to read but still erase) - fully trusted write (flash assumed to be clean) These ones are set using a new "-t" flag for which I have even updated the man page and indicated that it's not recommended. It worked well for me so I'm sending the patches assuming they'll be useful for someone else. BTW, to give you a bit more context, I was writing a 8MB flash to upgrade a small router from its 4MB one, so I just had to add 4MB of \xff after the existing image before flashing it. Best regards, Willy From 0d6a5248b79b2d62c4f2355772ed0538c8284883 Mon Sep 17 00:00:00 2001 From: Willy Tarreau <w@1wt.eu> Date: Thu, 10 Sep 2015 22:16:01 +0200 Subject: cleanup: move misplaced done message in read_all_first --- flashrom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)