On Thu, 18 Jul 2013 07:36:40 +0200 Heiko Schocher h...@denx.de wrote,
Hi Heiko,
> Hello Lukasz,
>
> Am 17.07.2013 16:34, schrieb Lukasz Majewski:
> > On Wed, 17 Jul 2013 12:26:35 +0200 Heiko Schocher h...@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/ ?
Then you need to define NAME in a following way:
/boot/uImage.
I'm also aware, that this is NOT an elegant solution.
>
> > 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 ;-)
Frankly, handling those large buffers is cumbersome. I've observed that
our current sdhci implementation has some issues with handling such
large transfers.
>
> >>> 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 ...
I know, but we also want to clean up it once for a long time. I'm very
open for other ideas :-).
>
> >> 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?
Yes. This also looks valid.
>
> >>> 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?
As stated above, NAME needs to be extended by fullpath.
>
> > 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 ...
However, as Tormod pointed out we could perform reset at DFU_DEATACH
internal DFU state.
>
> > 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?
This is not only for reset :-). For me it seems possible to send a
bunch of commands via DFU to be executed on by one.
$dfu_commanfs=mmc read 0x44000000 0:2;crc32 0x44000000 0x80;.....
other...commands;reset
But having only reset implemented when dfu-util -R is executed is also
a good idea.
>
> >> 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.
Ok.
>
> bye,
> Heiko
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
