Hello Lukasz,
Am 16.07.2013 17:35, schrieb Lukasz Majewski:
Dear All,
Since DFU usage at u-boot is spreading to different device types (MMC, NAND), file systems, raw partitions, ubi, etc, I think that it is a good moment to unify and structure the form of dfu_alt_info environment variable.
Full Ack!
Proposed new format for single dfu entity:
NAME | Type | Device | Dev_num | Dev_part | FS | start | size |
where:
Name - name of the alt setting (as seen by dfu-util -l) Type - description of the image (raw, file, img, command [*]) Device - physical device on which data are stored (mmc, nand, "-") Dev_num - number of the device - it is possible to store data via DFU on several devices of the same type. Dev_part - number of partitions on the device.
Should this be "number of the partition on the device"
You mean here the mtd partition for storing, right?
FS - information about file system on the device (fat, ext2/ext4, ubi). start - start offset from the beginning of the Device (byte or LBA number addressed) size - maximal number of blocks to be stored on the Device (expressed with Bytes of LBA number) (protection from overwriting the whole device)
Example:
Maybe dummy questions ...
NAME | Type | Device | Dev_num | Dev_part | FS | start | size |
u-boot | raw | mmc | 0 | "-" [**] | "-" | 0x80 | 0x100 | uImage | file | mmc | 0 | 2 | ext4 | "-" | "-" |
Is this enough information? Where to store the uImage file on the ext4 partition?
root.img | img | mmc | 0 | 5 | "-" | "-" | "-" |
img means here: getting an image and storing it on the mtd partition "Dev_part" if start and size are marked with "-", beginning on start of the partition?
Wouldn't it be better to use here mtd partition names instead numbers for "Dev_part"?
What if "start" and "size" are filled with values for the "Type" "img"? Or is this forbidden for the "Type" "img"?
root.img | raw | mmc | 0 | "-" | "-" | 0x1000| 0x4000|
u-boot | raw | nand | 0 | "-" | "-" | 0x100 | 0x100 | uImage | file | nand | 0 | 3 | ubi | "-" | "-" |
s/uImage/rootfs.img ? s/file/img ?
For the FS "ubi" we need to specify, how to burn this into nand. I think we have no "ubi format" command. With "ubi write ..." we can only write ubi volumes ... and we want here to burn an ubi image, which was created with ubinize and contains one or more ubi volumes.
Maybe usecase for updating ubi volumes: ubivolumename | img | nand | 0 | 3 | ubivol | "-" | "-" |
If you want to update an ubivolume ...
results in this steps: - get image per dfu @ img_addr We need to get here the complete image, as ubi write cannot write incremental ... - ubi part get_mtd_partition_name("Dev_part=3") vid_header_offset ^ From where get we this parameter ... value in "start"? - ubi write img_addr ubivolumename ${filesize}
command | cmd | "-" | "-" | "-" | "-" | "-" | "-" |
[*] - support for sending command via DFU (see below) [**] - "-" - indicates that no value is provided for this field. Despite of that it is mandatory to facilitate parsing.
Please share any possible use cases - for now and for the future. My goal is to devise dfu_alt_info structure which would work for us for a long time.
After setting up new format, it would be possible to replace different dfu command variations (i.e. dfu mmc 0, dfu nand) with only one command "dfu".
DFU extension - Command execution.
As a follow up I plan to add support for sending file filled with command[s]. This would provide interface for automated tests and force board to reset itself after emulated reset command from dfu-util program.
dfu_alt_info = "command cmd - - - - - -;"
and then on host: dfu-util -aN -D file_with_commands
The end step would be to extend dfu-util to support -C switch, which would allow to send u-boot command quoted as text:
dfu-util -aN -C "reset"
bye, Heiko