On Tue, May 28, 2013 at 08:24:06AM +0200, Heiko Schocher wrote: > Hello Wolfgang, > > Am 28.05.2013 07:58, schrieb Wolfgang Denk: > > Dear Heiko, > > > > In message <51a42ccd.1020...@denx.de> you wrote: > >> > >>> 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 ... > > > > I doubt that dfu_nand.c is the right place for this. What if I start > > using DFU on NOR flash? The decisions which device type (NAND, MMC, > > NOR, USB mass storage, ...) to habdle on one side, and which partition > > type / image type (raw, UBI volume, file, ...) on the other side are > > fully orthogonal to each other. They should be handled by independent > > code, and not one of them repeated for all implementations of the > > other. > > Yes, exactly ...
We can see about what re-org makes sense once we've got another implementation here. We might be able to share the filesystem-based write code, but that in part might cause some screams since it'll depend on our continued (ab)use of run_command. The device-specific code does end up being the device-specific API part. Unless we're adding ubifs in addition to ubi volume support to DFU, we don't have real shared filesystem stuff, yet. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
