Hello, Am 27.05.2013 09:35, schrieb Pantelis Antoniou: > Hi Guys, > > On May 27, 2013, at 10:28 AM, Heiko Schocher wrote: > >> Hello Lukasz, >> >> Am 27.05.2013 09:02, schrieb Lukasz Majewski: >>> Hi Heiko, >>> >>>> Hello Tom, >>>> >>>> Am 24.05.2013 19:12, schrieb Tom Rini: >>>>> 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). >>>> >>>> This sounds easy ... but they have also raw nand partitions, for >>>> example spl partitions on one nand flash ... for which dfu_nand.c >>>> fits perfectly ... is it possible to use dfu_nand.c and another >>>> dfu_xxx.c at the same time? >>> >>> I'm not so familiar with nand devices handling, but in my opinion we >>> shall create dfu_ubi.c file. >>> >>> I think that, nand part of dfu handling shall be separated from ubi, >>> even if UBI itself is layed on nand. >> >> Yes, I tend also to this .. but not as a separte "dfu interface .." >> "dfu nand .." should stay, and each partition should know, if it >> is a raw nand, or UBI, or jffs2?,... as like in dfu_mmc.c ... but >> this should not be hardcoded in every dfu_xxx.c, instead it should >> be something like a subinterface ... if it is possible. >> > > I'm not completely up to speed with UBI, but dfu_ubi seems to be the way > to go for me.
But how to handle a raw nand partition and a ubi partition on one nand? If ubi is a new dfu interface, somebody must start dfu on u-boot with "dfu nand .." or "dfu ubi .." dependent on which partition has to be updated ... before using dfu-util on the host side ... and start dfu-util for the correct partition... This seems not really userfriendly to me ... if I have to use the u-boot shell, why using dfu-util on a host pc instead executing tftp and update my images within u-boot? Is ubi really a "interface" as nand or mmc ... ? > Looks like it's simple enough; erase (but don't step over the wear counters) > , write (but skip over the wear counters). Yep, or load the complete image in ram, and write it with "ubi write ..." > I don't know how smart you have to be with UBI version; be very careful > when the binary format of UBI changes. Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot