Hi Tom, First of all, sorry for late reply.
> On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote: > > Hi Tom, > > > > > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > > > > > We didn't support upload/download larger than available memory. > > > > This is pretty bad when you have to update your root filesystem > > > > for example. > > > > > > > > This patch removes the limitation (and the crashes when you > > > > transfered any file larger than 4MB). > > > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > > > which was over the top. > > > > > > > > The sequence number is a 16 bit counter; make sure we > > > > handle rollover correctly. This fixes the wrong transfers for > > > > large (> 256MB) images. > > > > > > > > Also utilize a variable to handle initialization, so that we > > > > don't rely on just the counter sent by the host. > > > > > > > > Signed-off-by: Pantelis Antoniou <pa...@antoniou-consulting.com> > > > > > > To be clear, patches 1-8 are good and we should take, but this one > > > means we can't use FAT/EXT* partitions without more work. I would > > > suggest that we set this part aside for a moment and perhaps limit > > > transfers that are larget than RAM to RAW only where we can write > > > in chunks today. > > > > > > > As fair as I remember, some additional work needs to be done with > > composite.c file (to remove nasty #ifdefs). There was a problem with > > newer version of dfu-utils (new handling of descriptors). > > I see you and Pantelis talking about if some changes were really > needed in composite.c or not, but nothing about dfu-utils. Changes in composite.c (adding some #ifdefs) were made because dfu-util developers made the significant change in descriptors handling between dfu-utils ver. 0.1 (which I've been using on my antic/test machine debian) and the newest dfu-utils (which Pantelis was using, and which is now available on recent debian). To be honest the current DFU code (v2013.01) works with the dfu-utils ver 0.1 (the old one). It breaks with new one. > Were you > objecting to the composite.c changes because you didn't need them, or > because they in turn broke trats (can I get one of these somewhere?) I'm objecting to adding a "quick hack style" #ifdefs to generic composite.c code. As fair as I remember this corrected code works with DFU, but I'd need to check if those composite.c changes will not break the UMS patches posted recently. Regarding TRATS: It is an official Tizen development board (mobile phone): http://www.youtube.com/watch?v=ya7ucT1wzOA It was distributed on some fair show, but I cannot tell how to obtain one. > The only other unresolved thing was about board_usb_init() which I > think was settled on trats needing to change behavior. As fair as I remember trats follows u-boot policy to enable things only when they are really needed. But I will not be stubborn here. On the end I might end up with a weak function (or enabling USB by default). I think, that this is a minor issue when compared to composite.c My proposition: - Now we have middle of Feb, we can add Pantelis Patches, UMS patches to u-boot tree (from Marek's USB tree) and fix conflicts up till v2013.03 release. I can point two big sets of patches (related only to Samsung boards) floating around without a common "base": Pantelis DFU work and UMS support patches. - I plan to work on composite/DFU (and potential UMS problems) at next week (up Friday I'm totally buried with other work) -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot