From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 24 May 2013 13:12:13 -0400 Subject: [U-Boot] dfu: dfu and UBI Volumes In-Reply-To: <6AD958CB-3CFC-4362-B72D-511147D041AC@antoniou-consulting.com> References: <519F97CA.4060901@denx.de> <6AD958CB-3CFC-4362-B72D-511147D041AC@antoniou-consulting.com> Message-ID: <20130524171213.GT17119@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 Fri, May 24, 2013 at 07:42:01PM +0300, Pantelis Antoniou wrote: > Hi Heiko, > > On May 24, 2013, at 7:39 PM, Heiko Schocher wrote: > > > Hello, > > > > just digging in DFU support in U-Boot for an upcoming board support > > based on an AM335x. This board support uses for example a rootfs in > > an UBI Volume on a NAND flash, and this should be updated with dfu ... > > > > How To do this? Current state on this board is to erase the rootfs > > mtd partition with a nand erase and write the new image using > > dfu_nand.c ... which calls in the end nand_write ... which is ... > > lets say ... not the prefered way on an UBI volume ... > > > > How to solve this? Any ideas? > > Well, what would you like ideally to do? Why is nand_write not ideal for > a UBI volume. > > Note that dfu will skip over the bad blocks... Presumably because they want to replace say ubi0:rootfs (and leave ubi0:user-data and ubi0:u-boot-env and so forth alone) rather than write in a new ubi container of everything. I would suggest that, so long as our existing UBI infrastructure allows this, you add a new method, dfu_ubi which takes care of programming things. This shouldn't be too bad to write as I've heard the existing infrastucture was easily expanded for SPI (and patches are pending a little more clean up prior to posting). -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: