Hello. On Thu, 2011-11-03 at 09:44, Andrzej Pietrasiewicz wrote: > On Wednesday, November 02, 2011 8:30 PM Stefan Schmidt writes: > > > > Agreed. The eMMC flashing with files on FAT is nothing goni specific. > > Others should be able to use this as well. I see three different parts > > here that can be separated: > > I agree. Since there is interest in DFU implementation this can and should > be generalized.
Great! > > 1) The DFU protocol implementation which lives in usb gadget with an > > interface for flashing backends > > > > 2) The flashing backends (no idea where to put them best). At the > > moment that would be the implementation here with eMMC and files on FAT, > > mine with raw NAND devices and in the future maybe others. Each > > flashing backend should be generic enough to allow different boards > > using it. > > > > 3) Board specific information like partitions or hints for the flashing > > backend. The information itself should be in the board file here and > > only used by the flashing backends. > > > > How does this sound to you? Andrzej? > > Sounds good to me. In my implementation the interface between dfu gadget > and flashing backend is around the struct flash_entity. > It contains a character string intended to provide a human-readable name, > a void * context which is not interpreted by the gadget code, > but is passed to the flashing backend and understood by it. > The struct flash_entity also contains prepare-finish methods > to be called before and after read/write operations, and the read_block- > write_block pair. What do you think? I would need to use it for my NAND backend before I really can comment on it. I can only tell if I'm happy with and interface if I actually used it. :) Will do this when you send it a separate patch with only the DFU implementation with the flash entity as interface. See my roadmap proposal in the other mail. > As far as generalization is concerned, in my flashing backend > implementation I see these parts as candidates for generalization: > > 1) mbr/ebr reading > 2) reading/writing mmc > 3) read/write fat Agreed. That can be used by all kind of devices. > 4) generic prepare/finish; not sure if fat-specific prepare can be > generalized Would be good to get soem comments on the fs custodians around here. > 5) read/write_block Agreed. > 6) some more work should be put to create an interface between the board > initialization routine, the flashing backend and the DFU gadget > implementation. > In my implementation the board initialization routine calls board-specific > register_flash_areas, which, in turn, calls DFU gadget's > register_flash_entities. > What's your opinion? The interface between the configuration in the board file and the actual flashing backend is something I haven't wraped my mind around yet. Need to think about it. regards Stefan Schmidt _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
