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

Lukasz Majewski l.majewski at samsung.com
Wed Jul 17 16:34:40 CEST 2013


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.

> 
> > 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



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group


More information about the U-Boot mailing list