[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