Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> OK, here is a simulation of what I will create tonight. I think this is
>> both workable, very effective, and meets Wolfgang's constraints.
>
> I like it.
>
>> > ./dots 99
>> Writing to Flash... 0123456
In message <[EMAIL PROTECTED]> you wrote:
>
> > In message <[EMAIL PROTECTED]> you wrote:
> > >
> > > There is no way to add an end marker without using a new line (or use
> > > '\r' which is really unacceptable, and more justifiably so). Since we
> > > are settling in on having 50 (?probably wa
In message <[EMAIL PROTECTED]> you wrote:
>
> OK, here is a simulation of what I will create tonight. I think this is
> both workable, very effective, and meets Wolfgang's constraints.
I like it.
> > ./dots 99
> Writing to Flash... 0123456789 Done
>
>
On Fri, 07 Mar 2008 17:33:34 +0100
Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > There is no way to add an end marker without using a new line (or use
> > '\r' which is really unacceptable, and more justifiably so). Since we
> > are settling in on
Wolfgang Denk wrote:
[snip]
> But there is also a few other things to consider: keeping the output
> terse and efficient; keeping the same look and feel acrross different
> boards and platforms, etc. If you add such code to the CFI driver,
> users might request that such code also gets added
On Fri, 2008-03-07 at 00:38, Stefan Roese wrote:
> I insist on nothing. I'm just pointing out, that the current implementation
> can be enhanced.
How about adding a CONFIG_CFI_SHOW_PROGRESS option
that enable/disables this feature as well?
jdl
In message <[EMAIL PROTECTED]> you wrote:
>
> There is no way to add an end marker without using a new line (or use
> '\r' which is really unacceptable, and more justifiably so). Since we
> are settling in on having 50 (?probably want to use a #define) dots
> unless there are fewer than 50 unit
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> I was too terse. The problem is that I added a progress bar.
>> Previously, the printout sequence was:
>>Writing to Flash...
>> followed by an indeterminate wait, followed by the string "done." which
>> formed the composite:
In message <[EMAIL PROTECTED]> you wrote:
>
> I was too terse. The problem is that I added a progress bar.
> Previously, the printout sequence was:
>Writing to Flash...
> followed by an indeterminate wait, followed by the string "done." which
> formed the composite:
>Writing to Flash...
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> The saveenv also looks funky. I only mucked with the cmd_mem.c command
>> to make it display better with the progress dots, obviously the saveenv
>> command needs to have the same changes
>>s/"Writing to Flash... "/"Writing
In message <[EMAIL PROTECTED]> you wrote:
>
> The saveenv also looks funky. I only mucked with the cmd_mem.c command
> to make it display better with the progress dots, obviously the saveenv
> command needs to have the same changes
>s/"Writing to Flash... "/"Writing to Flash\n"/
Please don'
On Friday 07 March 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > I already have enough "glory" in U-Boot history. ;) I leave this for
> > somebody else for now. Let's see, if somebody steps up...
>
> Indeed: since v1.3.1:
>
> Developers with the most changesets
> Stefan
On Mar 7, 2008, at 8:15 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> I already have enough "glory" in U-Boot history. ;) I leave this
>> for somebody
>> else for now. Let's see, if somebody steps up...
>
> Indeed: since v1.3.1:
>
> Developers with the most changese
In message <[EMAIL PROTECTED]> you wrote:
>
> I already have enough "glory" in U-Boot history. ;) I leave this for somebody
> else for now. Let's see, if somebody steps up...
Indeed: since v1.3.1:
Developers with the most changesets
Stefan Roese 109 (13.2%)
Kumar Gala
In message <[EMAIL PROTECTED]> you wrote:
>
> I don't think printing the programming time/speed at beginning of the
> operation is doable. At least not without bigger changes. But an output at
> end of the operation like:
>
> Wrote 512kB in 5.4 seconds (94,8 kB/s)
U-Boot output shall be terse.
On Friday 07 March 2008, Jerry Van Baren wrote:
> Odd, I didn't see your reply, saying "[EMAIL PROTECTED]" must trigger our mail
> filter, it's built on Microsoft technology. ;-) I can read your reply
> in gmane.org, now that I know to look. :-/
Understood. :)
> The crash is undoubtedly due to
Stefan Roese wrote:
> On Friday 07 March 2008, Jerry Van Baren wrote:
>>> would be nice. This way the developer could see, if the interface to the
>>> FLASH chips is optimized. But I think this is overkill too. Let's
>>> concentrate on a clean progress bar with a fixed length.
>>>
>>> Patches welco
On Friday 07 March 2008, Jerry Van Baren wrote:
> > would be nice. This way the developer could see, if the interface to the
> > FLASH chips is optimized. But I think this is overkill too. Let's
> > concentrate on a clean progress bar with a fixed length.
> >
> > Patches welcome. :)
> >
> > Best re
Jerry Van Baren wrote:
> Clemens Koller wrote:
[snip]
> Here is a revised command line example that autoscales to 50 dots:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int k;
> int cnt;
> int scale;
>
> if(sscanf(argv[1], "%d", &cnt)
Stefan Roese wrote:
> On Friday 07 March 2008, Clemens Koller wrote:
>> ACK from my side to Jerry's version. Maybe a quite long fixed length (~40
>> characters) bar would also be reasonable and the dot-time scaled to fit the
>> progress.
>>
>> A progress bar needs IMO two informations:
>> - that it
Clemens Koller wrote:
> Jerry Van Baren schrieb:
>> Michael Schwingen wrote:
>>> Wolfgang Denk wrote:
Please let's stay terse. Printing a dot is a single character on the
console. I dislike funny stuff which requires output of non-printing
characters or (weven worse!) terminal spec
On Friday 07 March 2008, Clemens Koller wrote:
> ACK from my side to Jerry's version. Maybe a quite long fixed length (~40
> characters) bar would also be reasonable and the dot-time scaled to fit the
> progress.
>
> A progress bar needs IMO two informations:
> - that it's still working... so a qui
Jerry Van Baren schrieb:
> Michael Schwingen wrote:
>> Wolfgang Denk wrote:
>>> Please let's stay terse. Printing a dot is a single character on the
>>> console. I dislike funny stuff which requires output of non-printing
>>> characters or (weven worse!) terminal specific escape sequences.
>>>
On Thursday 06 March 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > > Backspace or CR without LF should work on all terminals, no?
> >
> > I don't see here any problems either.
>
> It messes up log files and is a PITA to filter out in regression
> tests.
I see. I didn't
In message <[EMAIL PROTECTED]> you wrote:
>
> > Backspace or CR without LF should work on all terminals, no?
>
> I don't see here any problems either.
It messes up log files and is a PITA to filter out in regression
tests.
> > If it is possible to estimate how long the operation will take, this
Michael Schwingen wrote:
> Wolfgang Denk wrote:
>> Please let's stay terse. Printing a dot is a single character on the
>> console. I dislike funny stuff which requires output of non-printing
>> characters or (weven worse!) terminal specific escape sequences.
>>
> Backspace or CR without LF sh
On Thursday 06 March 2008, Michael Schwingen wrote:
> Wolfgang Denk wrote:
> > Please let's stay terse. Printing a dot is a single character on the
> > console. I dislike funny stuff which requires output of non-printing
> > characters or (weven worse!) terminal specific escape sequences.
>
> Bac
Wolfgang Denk wrote:
> Please let's stay terse. Printing a dot is a single character on the
> console. I dislike funny stuff which requires output of non-printing
> characters or (weven worse!) terminal specific escape sequences.
>
Backspace or CR without LF should work on all terminals, no?
In message <[EMAIL PROTECTED]> you wrote:
>
> Fine with me too. Even though I would prefer to switch this progress output
> on
> all FLASH access routines to something like % too. This way we have an idea
> how long this operation it is going to last.
Please let's stay terse. Printing a dot is
On Thursday 06 March 2008, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > I do like such a progress output. But printing each KB seems a little
> > too much from my point of view. Could even slow down the programming
> > because of the slow serial output on some systems.
>
> I
In message <[EMAIL PROTECTED]> you wrote:
>
> I do like such a progress output. But printing each KB seems a little
> too much from my point of view. Could even slow down the programming
> because of the slow serial output on some systems.
I agree that a counter is overkill.
I suggest we continue
[EMAIL PROTECTED] wrote on :
> On Wednesday 05 March 2008, York Sun wrote:
> > Add flash programming counter. It prints how many KB has been
> > programmed in case you suspect it hangs when programming large
> > files.
[...]
> + if (!((count - cnt) % (1 << 14)))
> +
On Wednesday 05 March 2008, York Sun wrote:
> Add flash programming counter. It prints how many KB has been programmed
> in case you suspect it hangs when programming large files.
I do like such a progress output. But printing each KB seems a little
too much from my point of view. Could even slow
Add flash programming counter. It prints how many KB has been programmed
in case you suspect it hangs when programming large files.
Signed-off-by: York Sun <[EMAIL PROTECTED]>
---
drivers/mtd/cfi_flash.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/
34 matches
Mail list logo
