From mboxrd@z Thu Jan  1 00:00:00 1970
From: Heiko Schocher <hs@denx.de>
Date: Tue, 28 May 2013 06:04:29 +0200
Subject: [U-Boot] dfu: dfu and UBI Volumes
In-Reply-To: <20130527192135.GX17119@bill-the-cat>
References: <519F97CA.4060901@denx.de>
	<6AD958CB-3CFC-4362-B72D-511147D041AC@antoniou-consulting.com>
	<20130524171213.GT17119@bill-the-cat> <51A1B522.2050405@denx.de>
	<20130527192135.GX17119@bill-the-cat>
Message-ID: <51A42CCD.1020607@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hello Tom,

Am 27.05.2013 21:21, schrieb Tom Rini:
> 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 <name> 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 <name> 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.

Yes, I think, thats the way to go ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany