From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 27 May 2013 15:21:35 -0400 Subject: [U-Boot] dfu: dfu and UBI Volumes In-Reply-To: <51A1B522.2050405@denx.de> References: <519F97CA.4060901@denx.de> <6AD958CB-3CFC-4362-B72D-511147D041AC@antoniou-consulting.com> <20130524171213.GT17119@bill-the-cat> <51A1B522.2050405@denx.de> Message-ID: <20130527192135.GX17119@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, May 26, 2013 at 09:09:22AM +0200, Heiko Schocher wrote: [snip] > Ah, looking in drivers/dfu/dfu_mmc.c, they use dfu->layout > for switching between DFU_RAW_ADDR, DFU_FS_FAT, DFU_FS_EXT4... > > After all ... should we add a DFU_UBI and add this to > drivers/dfu/dfu_nand.c? Yes, I think we should be able to adapt dfu_nand to support raw (current) and UBI (which will need a little further handling so you can update per UBI container). In MMC (and there's examples in trats and am335x_evm) we say ext4/fat/part/raw device#/start_blk part#/end_blk. I would imagine, but testing and implementation might show a better way, we do UBI as ubi ubiN volume-name, ie: rootfs ubi ubi0 rootfs user ubi ubi0 user-data and so forth, and augment dfu_nand.c with UBI knowledge, ala dfu_mmc and fat/ext knowledge. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: