[U-Boot] [PATCH] dfu: fix some issues with reads/uploads

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/30/2014 02:28 AM, Lukasz Majewski wrote:
> Stephen Warren wrote:
...
>> Wouldn't it be better to have the following separate
>> "backends" to DFU:
>>
>> * MMC (raw IO only)
>> * NAND (raw IO only)
>> * RAM (raw IO only)
>> * Filesystem (anything that fs/fat/ext* load/write can support)
>>
>> That way, DFU could be applied to e.g. USB mass storage, IDE,
>> SATA, ... devices too.
> 
> I think that separating the IO even from dfu_mmc.c code would be a good
> way to go. 
> 
> Could you however, present how would you like to fit it to the current
> design?

Here's how I'd love to see the dfu command work. It would take a bit of
refactoring of the code, and a change to the format of the dfu_alt_info
variable and "dfu" command parameters. Perhaps we could have an option
to the "dfu" command saying which cmdline style the user is using?

dfu_alt_info = setting [; setting]*

setting = mmc_format | nand_format | ram_format | fs_format

mmc_format = "mmc" device_id hwpart_num start_sector sector_count

nand_format = "nand" device_id start_sector sector_count

ram_format = "ram" start_address byte_count

fs_format = "fs" fs_device_type fs_device_id filename

All fs access would be through the generic filesystem API in fs/fs.c
rather than by using run_command(). The "fs_device_type",
"fs_device_id", and "filename" parameters in "fs_format" above would
simply be passed directly to the fs.c APIs without any interpretation by
the DFU code. This would allow automatic support of any memory device
type that "load", "ls", ... support. The code also wouldn't have to
construct command-lines and then re-parse them; calling functions
directly is a lot simpler.

The "dfu" command wouldn't take any device type/ID parameters. Instead,
all device IDs would be part of the dfu_alt_info variable. This would
allow e.g. eMMC partitions and SPI flash devices to be exposed at the
same time, rather than having to somehow co-ordinate executing one dfu
command in U-Boot to update the SPI flash, then quitting that, then
starting a different dfu command in U-Boot to update some data on eMMC.
It's harder to automate that vs. just starting dfu once, then running a
single script on the host which writes a bunch of dfu settings in
sequence without the need for co-ordination.

I'm not sure how much time I have to actually work on converting the
code to work that way though. Since we already have a working non-DFU
flashing solution using U-Boot[1], my management sees any work on DFU as
a bit redundant. Still, it would be nice to use standard protocols for
this...

[1] https://github.com/NVIDIA/tegra-uboot-flasher-scripts