Hi Igor, On 11/6/26 14:40, Igor Velkov wrote: > On 06/11/2026 20:10, Jerome Forissier wrote: >> ...I agree that compatibility is a must and that we should not >> introduce such a change lightly. Thanks for raising the point. Let's >> see what others think. I will drop this series if it is deemed unacceptable >> or if we simply need more time to discuss it. > > We are new here and not yet familiar enough with U-Boot's style; we > don't want to make it worse. We'll rework the options the way the > maintainers advise. The writer is a separate sink (lib/stream_sink.c), > so a 'cc' command can use it too. That notation is new to me, though: > more usage examples would help - which inputs and outputs, with what > offsets and sizes. > > I'd like the options to cover memory, a whole disk and a partition. > Ideally a file on a filesystem too; how to do that is not clear to me > yet, so I haven't tried. Still, the syntax should leave room for it > and stay easy to read. > > Igor
Are you willing to write something like a 'cc' for U-Boot? This 'cc' is only a new idea I am thinking of. I'm not much help with systems programming code so I'm only able to describe the user interface for the idea. I've attempted this previously as a U-Boot hush script for read/write of eMMC block image to/from file and then tftpput over the network, which is annoying to construct in this way and also as being unable to parse outcomes made it very error-prone. The most immediate 'cc' implementation would be to fully re-use existing commands. The idea of 'cc' is for any data read/write user command where you have source and/or destination with an intermediary buffer that does not necessarily have 1:1 relationship with the source or destination: 'cc dd' There may be some sub-commands (cc input, cc output, cc buffer) to assist with setting the variables so that env variable setting is discoverable by users at the command line, and a sub-command to begin the data transfer action based on the env variables e.g.: cc_input cc_output cc_addr cc_size I suggest 'cc dd' for the sub-command name to begin the data transfer, it is familiar as taking data from one place in chunks and putting it to another place. A subset of coreutils dd arguments could be parsed if we will want e.g. 'seek=' 'skip=' 'bs=' 'count=' 'status=' and not have to invent this syntax again, just refer to how it is written for dd documentation. I think load / save / 'mmc read' / 'mmc write' are good first candidates for cc command support on input and output, and with some more work to extend support for streaming commands then wget for input, mw for input and output, md for console output, etc. env set cc_input 'mmc read - 0 50000' env set cc_output 'mmc write - 50000 50000' env set buffer $loadaddr env set size 0x400 when cc_input env variable gets parsed out for 'cc dd' each iteration the support for mmc as a 'cc' command filters on argv[2] as a buffer address placeholder, and then argv[3] and argv[4] as initial inputs need to be re-calculated in a series of calls to the real 'mmc read' command so we don't overflow whatever cc_buffer_address and cc_buffer_size is specified. A similar filtering occurs for cc_output. Overlapping the input and output ranges is undefined behavior, but may be useful so don't prevent it. Initial support for input commands that are streaming like wget, when the output commands are not streaming (like I describe the most basic possible way to re-use existing commands) can just require that the memory buffer is large enough for the whole input, and failing early if overflowing $cc_buffer_size. Then re-factor the 'cc input mmc read' 'cc output mmc write' support as a streaming input / output, and streaming refactor of 'cc input wget', and then whatever 'cc input load' and 'cc output save' support for file on filesystem source/sink that you are interested in. This would be amazing, is it possible? -E
