From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 21 Oct 2015 10:09:28 -0400 Subject: [U-Boot] Fastboot behaviour with sparse images In-Reply-To: <20151012134301.GB2278@lukather> References: <20151012134301.GB2278@lukather> Message-ID: <20151021140928.GR23893@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Oct 12, 2015 at 03:43:01PM +0200, Maxime Ripard wrote: > Hi, > > I'm currently writing the support in U-Boot for NAND-backed devices > using fastboot [1], and that work derived a bit to supporting the > sparse images. > > For "regular" images that are being stored, we expect a pair of > download and flash commands. Simple. > > Things start to get a bit more complex with sparse images that have > been split because of a max-download-size lower than the actual image > size. > > Here, from what I could gather from various random blog posts, the > fastboot client implementation and dumping a few USB sessions, the > client simply creates several download / flash pairs, always on the > same partition, without any way to distinct that from several > subsequent writes issued by the user. > > So, I'm guessing that the expectation is that the bootloader > implementation should store the last offset it wrote to, and simple > resume from there if the partition names in the flash commands are the > same, which would prevent two subsequent write on the same partition > by any client. Am I right? > > A related question is when should we erase the NAND partition? Only > when doing fastboot erase, or also when doing fastboot write (which, > combined with the issue raised above, would also mean that we don't > want to do an erase on the whole partition everytime there's a flash > command on it). I think for this last question, some experimentation with the existing tools might be required. As there's no required explicit erase for MMC, I think it might make sense to say you erase nand up front and then write as anything else starts getting really tricky and we're just second-guessing the user. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: