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