From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= Date: Tue, 28 May 2013 18:43:27 +0200 (CEST) Subject: [U-Boot] dfu: dfu and UBI Volumes In-Reply-To: <3E2E325D-27DB-473E-AB48-7B738A0C2F9C@antoniou-consulting.com> References: <20130527090254.5071e4fd@amdc308.digital.local> <20130527212552.C08F2380E6A@gemini.denx.de> <20130527233735.GZ17119@bill-the-cat> <20130528055046.4258C38116A@gemini.denx.de> <20130528150159.GC5829@bill-the-cat> <53FA5D9D-DA5D-409C-A262-0427569C250C@antoniou-consulting.com> <1905526685.1261642.1369758701313.JavaMail.root@advansee.com> <3E2E325D-27DB-473E-AB48-7B738A0C2F9C@antoniou-consulting.com> Message-ID: <865724508.1261993.1369759407202.JavaMail.root@advansee.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Pantelis, On Tuesday, May 28, 2013 6:43:06 PM, Pantelis Antoniou wrote: > Hi Beno?t > > On May 28, 2013, at 7:31 PM, Beno?t Th?baudeau wrote: > > > Dear Pantelis Antoniou, > > > > On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote: > >> Hi Tom, > >> > >> On May 28, 2013, at 6:01 PM, Tom Rini wrote: > >> > >>> 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. > >>> > >> > >> Correct, the DFU protocol doesn't have a method to inform you before hand > >> about the size of the transfer about to happen. > >> > >> The only possible solution I see at this point is to have an environment > >> variable, i.e. dfubuf that controls the size of the buffer. > >> > >> Upon start of a dfu transfer we can allocate the buffer, and do our > >> thing. > > > > I don't know the details of the DFU implementation in U-Boot, but the > > specification leaves the choice between programming the firmware on-the-fly > > during the download, and later during the manifestation phase (or a mix of > > both). Hence, there is not need for a global firmware buffer if U-Boot goes > > for > > the on-the-fly programming strategy. The only buffer constraint would be > > wTransferSize (chosen by U-Boot for the control endpoint) in that case. See > > "7. Manifestation Phase" on page 26 here: > > http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf > > > > The problem is not DFU TBH, it's that since we don't have an option to append > to a file, we have to have the whole file transferred in RAM and written in > one go. The raw medium dfu methods in u-boot don't have a problem. > > > Of course this can't yet apply to writing files on file systems since the > > current API in U-Boot misses the append feature, but this could be applied > > to > > program raw memory partitions, including UBI images. > > > > It already happens for raw memory partitions, it's the UBI images being > discussed. But what does appending to a file has to do with programming a UBI image, which is a memory partition containing a whole file system? This is what I don't get in this discussion. Is it because of a restriction of the DFU API in U-Boot? Best regards, Beno?t