[U-Boot] [PATCH] dfu: initial implementation

[Andrzej Pietrasiewicz]

Hello Stefan,

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.

> 
> 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?

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
4) generic prepare/finish; not sure if fat-specific prepare can be
generalized
5) read/write_block
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?

Thanks,

Andrzej