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 welcome. :)
Best regards, Stefan
All but the timing part ;-) http://article.gmane.org/gmane.comp.boot-loaders.u-boot/37626
Yes, thanks. I did already write a reply to this. Crashes on my system while programming 16Mbytes.
Best regards, Stefan
Odd, I didn't see your reply, saying "cr@sh" 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. :-/
The crash is undoubtedly due to a buffer overflow on the format string (16MB => . Adopting Clemen's proposal for a fixed length bar (see previous email for a 50 dot bar example) is trivial.
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"/ Apparently saveenv does four very short program operations.
=> saveenv
[snip]
Writing to Flash... | | | | done
[snip]
If you want to extend my patch, here's your chance to grab all the glory. ;-)
Best regards, gvb