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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
