On Wed, 17 Jul 2013 12:26:35 +0200 Heiko Schocher hs@denx.de wrote,
Hi Heiko,
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"
No. I made a mistake. It should be "partition to which we want to write"
You mean here the mtd partition for storing, right?
Yes, number of the partition to store data. The exact address will be extracted from mtdparts or partitions env variable.
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?
To store uImage file on ext4/fat/ext2 partition it is enough to only give:
uImage mmc 0 2,
which maps to the following command:
ext4write mmc 0:2 0x44000000 /uImage [size]
The file size is taken from number of sent bytes via DFU/USB.
With writing to file system, one need to first store the whole transmitted data to a buffer and then store the (big) buffer on the SD/eMMC device.
Since, we aren't supporting "seek" kind of write to current ext4 implementation at u-boot, the "big" buffer must be used.
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?
No, here img is for example a rootfs image. When storing it on the eMMC, it would be better to specify destination partition.
Wouldn't it be better to use here mtd partition names instead numbers for "Dev_part"?
I'd prefer to create a new entrance here (Part_name):
NAME | Type | Device | Dev_num | Dev_part | Part_name | FS | start | size |
I would like to avoid situation with ambiguous fields. One field shall only serve for one (clear) purpose. When not needed/used - field shall be marked as "-".
What if "start" and "size" are filled with values for the "Type" "img"? Or is this forbidden for the "Type" "img"?
I think, that each "Type" shall have predefined set of allowed attributes:
1. img: "Device" + "Dev num" + "Dev parts" 2. raw: "Device" + "Dev num" + "start" + "size" 3. file: "Device" + "Dev num" + "Dev parts" + "FS"
and so on.
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 ?
NAME: uImage and rootfs.img maps to files sent to board.
The "NAME" is used thereafter to provide exact name for file system write (ext4write/ fatwrite).
With DFU the distinction between dfu entities (files, raw images, etc) is performed via alt settings (-aX switch at dfu-util).
For the FS "ubi" we need to specify, how to burn this into nand. I think we have no "ubi format" command.
Is already ubi format command available at u-boot?
_As a side note:_
I'm now developing proof-of-concept idea of executing set of commands sent to u-boot by dfu-util [***].
Rationale for this is the lack of ability to reset u-boot after sending data to u-boot via DFU. dfu-util has -R option, but this seems to reset usb interface, not the target device.
I will set an env:
setenv dfu "dfu mmc 0;${dfu_commands}"
Then at dfu itself, I will read commands to be performed. Then I will set $dfu_commands env and exit from dfu 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 ...
So each volume shall have different dfu entity. Then those volumes are stored at ram with different addresses [*]?
- ubi part get_mtd_partition_name("Dev_part=3") vid_header_offset ^ From where get we
this parameter ... value in "start"?
So here you get information about the ("Dev_part=3") partition start offset [**]?
- ubi write img_addr ubivolumename ${filesize}
Here you combine volumes sent at [*] and store it at correct offset [**]?
I'm not an expert about ubi, so please be patient with my questions :-).
For me it looks like a mixture of ordinary u-boot commands with dfu transfer[s] needed to perform correct ubi image write. Maybe [***] will help you?
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