[U-Boot] [PATCH 1/4] dfu:cmd: get the default command arguments from environment

[Stephen Warren <swarren@wwwdotorg.org>]

On 06/13/2014 02:28 AM, Przemyslaw Marczak wrote:
> Dear Stephen,
> 
> On 06/12/2014 06:39 PM, Stephen Warren wrote:
>> On 06/12/2014 08:25 AM, Przemyslaw Marczak wrote:
>>> This change adds support to store the default DFU cmd line
>>> arguments in the environment.
>>>
>>> This is useful for users who usually use the same arguments
>>> for dfu command and do the upgrade frequently.
>>>
>>> DFU command use cases:
>>> - dfu <usb ctrl> <if> <dev> [<list>] - use command line args
>>> - dfu [<list>] - take the default command line args from env
>>> And for both - optional list the initialized DFU entities.
>>>
>>> To use the default dfu device configuration user should define:
>>> - $dfu_usb_con - e.g. "0"
>>> - $dfu_interface - e.g. "mmc"
>>> - $dfu_device - e.g. "0"
>>
>> Instead of adding code to every single command[1] to get cmdline
>> parameters from the environment, why not just define commands in the
>> environment and have the user run those.
>>
>> In other words, the same effect can be achieved by the following
>> environment settings:
>>
>> setenv dfu_default dfu \$dfu_usb_con \$dfu_interface \$dfu_device
>> (or even)
>> setenv dfu_default dfu 0 mmc 0
>>
>> and have the user run:
>>
>> run dfu_default
> 
> You are right, I can do this in that way. But in my intention I would
> like to simplify those specific commands so much as they could be.
> 
> In this case, writing:
>  "run somecmd" - is also frustrating as writing:
>  "somecmd arg1 arg2 ...argx"
> instead of:
>  "thor"  - just upgrade my device for predefined setup
> 
> In both cases the command always uses the same arguments - because it is
> device specific and actually determined by config - or board design.
>
> So as you can see, thor and dfu commands are specific - always takes
> constant parameters. And I think that this is a good reason to make it
> so simply as. e.g. android "fastboot" command.

I'm not familiar with the thor command, but dfu's arguments are
certainly not fixed.

Since the implementation of dfu is limited to exposing a single memory
device at once, and at least some board have multiple different memory
devices that can be exposed by DFU (e.g. both eMMC and SPI), the user
very likely needs to switch between different parameters to the dfu command.

As an example, see include/configs/am335x_evm.h which defines different
values for dfu_alt_info_* for eMMC and NAND. NVIDIA's Venice2 board will
have different values for eMMC and SPI.

(If we rework the dfu command-line so that dfu_alt_info specifies
everything about the memory devices, and supports multiple different
memory types in the list, rather than the information being split
between the dfu command-line and $dfu_alt_info, that would be better...)

...
> Looking for cmdline args in the environment in those two commands,
> could be changed to modification of just one dfu function:
...
> - but there is still left the USB controller - should be checked in each
> command, rather than checking in each board file.
> By the way USB index is not used anywhere...

Indeed. Hopefully this will be fixed one day, so that I can do something
like:

# Enable USB host mode on controller 1, and detect a USB mass storage
# device
usb start 1
# Start USB device mode on controller 0 and run USB mass storage
# protocol, to export the previous USB device to the host!
ums 0 usb 0

or:

# start a device-mode USB serial console or CDC Ethernet on controller 0
??? not sure of the comamnd here; perhaps there isn't one yet
# Enable USB host mode on controller 1, and detect a USB mass storage
# device
usb start 1

Right now, "usb start" enables host mode on /all/ USB controllers, which
can interefer with any desired device mode operation on some of the
controllers...