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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to