Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
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 > > > > > > 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
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
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 > > > > 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. 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?) The only other unresolved thing was about board_usb_init() which I think was settled on trats needing to change behavior. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2013 05:01 AM, 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 >>> >> >> 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 thought it ended up being resolved. I'll have to re-read the thread again I guess. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIjHWAAoJENk4IS6UOR1WEs0P/07uTOJRh+8hBgnpcXwBZ8zD keEtN8vHs3JYOjW1k6styAFNGXy+PBhOJNOIx6ClsdTvCRU8FtGh09SZUAYBrZEj 5WbfqGaeFWY9bpgAhwsNRMXD3mcHq3EGvRm0Ga+ep/EDFd+lgswvfx9EtgxkOjy5 MM0G4BnjwJxWM4DW2Wkk/rXI7Xy8jpVn3abUPLva4iY8X5L6ez9GXp/VNv6nCoNI i+LuGXEnv7BsO9g+x5pvYlnQeMC5BPC7vKNMq9dj8o6MZ/Q7jCQkqz85GIqyDTta UByzr24G4xK5m7V0iFSlV7fnRHjcg7q+uAB6u2YSibssyibIuLoJA2VdiGZqp8oH OUBQ3L2v84QHhcKTQm/yqcQ4FWHaHQ369v4QwnON29yFqtb7Z/M3GEKCqPbPIlge eg+Bb8fymdjELQT4Bo0+EkydlvaQOhkSjxBlVa9GTkRyoPxpE7RNY5lgciseVZO4 hKG/Xfnce7fpQNoE8fJCWRslQp3sOiDE65gFRzNJN/15i+my+xYmN5HiNPWhcgmI 2EVJGx9/LXqZ6yGZh8bQCC3yvNnshG+cm4qAj58ytkLjVSVnsd7yxFYbexUTEJ0q YwOmE/72cgL/3IzpRUmh4o5G+uFJqhFx7zndMQyItdTN09mhZu7dCUtgud66A1Qg wUiQkeF4sWubUMIpYUvz =L9X2 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
Dear Lukasz Majewski, > 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 > > > > 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). > > It is on top of my queue, but I'm currently buried with other work and > need to postpone this. > > However it is still on the back of my head and I push myself to fix > this. Guys, can you just tell me what I should drop from u-boot-usb to submit a pullRQ with the rest ? Otherwise I'll drop the whole DFU stuff and be done with it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
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 > > 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). It is on top of my queue, but I'm currently buried with other work and need to postpone this. However it is still on the back of my head and I push myself to fix this. -- 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
Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.
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 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. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
