From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Thu, 18 Jul 2013 07:36:40 +0200 Subject: [U-Boot] [RFC][DFU] Unification of dfu_alt_info alt settings description + command execution In-Reply-To: <20130717163440.6dbe1a18@amdc308.digital.local> References: <20130716173521.3dd7ec9e@amdc308.digital.local> <51E6715B.3040807@denx.de> <20130717163440.6dbe1a18@amdc308.digital.local> Message-ID: <51E77EE8.8050003@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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