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 panto@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)