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

[Lukasz Majewski <l.majewski@samsung.com>]

Hi Stephen,

> 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

I think that the fs also need fs_device_id and fs_partition.

> 

DFU rework and as a result restructuring the dfu_alt_info is a pending
work for some time. 

Your idea sounds very appealing.

> 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...

Yes, definitely.

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


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group