Hi Siarhei!
Am 20.11.2015 um 13:57 schrieb Siarhei Siamashka:
[...]
If I understand you correctly, you'd do away with the "-p" and "-g[g]"
switches and instead use dedicated "[multi]progress" and "[multi][x]gauge"
commands, behaving like what would now be achieved with one of the
progress options combined with "write" or "multi[write]"?
Yes.
Done. I agree with your reasoning here and have thus dropped the other
options
apart from "-p". "--progress" remains as a 'quick and dirty' way to have the
standard "write" command output a progress bar and transfer stats.
(As suggested, "-v" output of the latter is now removed.)
There is also the "read" command, but I'm not sure if it needs
a progressbar either. Because I can't imagine it being ever used
to transfer a lot of data. Yes, we might implement something like
backing up the NAND flash in the future, but this will be probably
done by communicating with U-Boot (which can do the NAND reading
job) using the DFU protocol instead of FEL.
My thoughts, too. For now I haven't given 'read' any consideration.
The "FEL upload" (i.e. 'write') department seems more important from a
user's
perspective, e.g. for having useful feedback while a lengthy firmware
(updater)
gets transferred.
I agree that it should be possible to set the total size (only) once. Due
to the way the numbers passed to the callback function are modified, I'd
still want a way to tell if there's a "multi"-transfer pending - but that
could be done nicely using something like:
void progress_start(size_t total_bytes, bool multi);
I don't quite understand. Why do we want to distinguish between single
and multi transfers? Can you provide an example?
After considering your comments, and reading through the code again,
actually
I can't. :-) So I've taken the suggested route with this and got rid of most
of that crap. We're down to a progress_start() that passes the callback
function to be used, plus the (expected) total size in bytes; and a very
simple
progress_update(bytes_done) that informs the progress framework after every
chunk.
Also it looks like adding support for a trivial "echo" command might be
useful for adding extra annotations or markers between file transfers.
For example:
sunxi-fel uboot u-boot-sunxi-with-spl.bin \
echo "XXX" \
echo "0" \
echo "Uploading file A (1/2)" \
echo "XXX" \
write-with-dialog-gauge 0x40000000 file-a.bin \
echo "XXX" \
echo "0" \
echo "Uploading file B (2/2)" \
echo "XXX" \
write-with-dialog-gauge 0x41000000 file-b.bin \
| dialog --gauge "Starting upload" 6 70
I like that idea, as it nicely extends the possible interactions with
"dialog
--gauge". I've added a patch for an "echo-gauge" at the end of the v5
series.
Do we really want to have the SoC dependent chunk size? Normally we
should expect the transfer speed to be somewhere between 500 KB/s and
1000 KB/s (the speeds below 500 KB/s can be improved and we are
working on it). But even if we set the chunk size to only 128K, does
it really have any negative impact on anything?
[...]
Let's just get rid of it for now.
Done. I've selected the fixed transfer chunk size to be 128KiB per request.
Regards, B. Nortmann
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
