[U-Boot] dfu: dfu and UBI Volumes

[Tom Rini <trini@ti.com>]

On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130527233735.GZ17119@bill-the-cat> you wrote:
> > 
> > > Where exactly is this 8 MB limit coming into play?
> > 
> > In buffering the data.  We cannot write a chunk of a file to a
> > filesystem and then append to it, we don't have the API today.
> 
> Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
> not load a 256 MiB file to RAM, and then write it to a file system?
> 
> I have definitely dealt with images and files bigger than 8 MiB in
> thepast, so I really don't see where any buffer problem could be.

I thought I might not have been clear about where this limit comes from,
after I sent the email.  The problem we have, and this is only for
writing to a filesystem (_not_ writing of a filesystem) is that we do
not have the API for appending to files, only create/overwrite.  So we
must read the whole file into memory, and then write it out.  The DFU
protocol doesn't have (I would swear anyhow) a part where it says "I'm
about to send you a blob of X bytes", so we cannot know at the start how
much data is coming our way.

Today we "solve" this with a statically defined
CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
be that same value.  Going forward, we may be able to switch this to
(and both of these are off the top of my head) a getenv to see how much
space to malloc, or just making it a malloc and adding some compile-time
check to ensure that the malloc area is at least as big as
CONFIG_SYS_DFU_MAX_FILE_SIZE.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130528/4a2e0ec7/attachment.pgp>