[U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution

[Heiko Schocher <hs@denx.de>]

Hello Lukasz,

Am 17.07.2013 16:34, schrieb Lukasz Majewski:
> On Wed, 17 Jul 2013 12:26:35 +0200 Heiko Schocher hs at 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:
>
> 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.

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany