
Hello Lukasz,
Am 17.07.2013 16:34, schrieb Lukasz Majewski:
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.
Ok.
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]
Hmm... and what if I have my uImage in /boot/ ?
The file size is taken from number of sent bytes via DFU/USB.
Yes.
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.
Ok, same for an ubi image.
Since, we aren't supporting "seek" kind of write to current ext4 implementation at u-boot, the "big" buffer must be used.
Ok, there are places to optimize ;-)
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 "-".
Ok. but this gives long constructs ...
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:
- img: "Device" + "Dev num" + "Dev parts"
- raw: "Device" + "Dev num" + "start" + "size"
- file: "Device" + "Dev num" + "Dev parts" + "FS"
and so on.
If we introduce a "Part_name" this should be also possible:
4. img: "Device" + "Dev num" + "Part_name" 5. file: "Device" + "Dev num" + "Part_name" + "FS"
or?
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).
Ah! If we have to write in a subdirectory, "NAME" is the fullpath + filename?
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?
No.
_As a side note:_
I'm now developing proof-of-concept idea of executing set of commands sent to u-boot by dfu-util [***].
Ok.
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.
That answers my next question which comed in my mind ...
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.
Hmm... is this not oversized for the "reset board" use case?
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 [*]?
Yes for every volume have different dfu entity. You update only one volume with one dfu-util command, or? So no different addresses needed ...
- 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 [**]?
Yes ... what is with the "vid_header_offset" parameter?
- ubi write img_addr ubivolumename ${filesize}
Here you combine volumes sent at [*] and store it at correct offset [**]?
Yes! But just one volume at once ...
I'm not an expert about ubi, so please be patient with my questions :-).
No problem! I also just learning ;-)
The above steps are just to get the idea, what must be done for updating an ubi image, as this were the steps if you type in commands.
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?
If we have the dfu_buf address availiable ... maybe it is worth a try ... thinking of sending per dfu a "run upd_ubi" and the "upd_ubi" command do the complete update ... but, if we update more than one image ... this will not work.
bye, Heiko