[U-Boot] [PATCH 10/13] sunxi: Make the fastboot buffer larger

[Maxime Ripard]

Hi Ian,

On Tue, Sep 01, 2015 at 08:22:04AM +0100, Ian Campbell wrote:
> On Mon, 2015-08-31 at 16:46 +0200, Maxime Ripard wrote:
> > When using fastboot and flashing a larger image such as the main partition
> > of a system, the current 32MB limit for the buffer is quite small.
> 
> (Apart from rooting/rescuing the odd phone I'm completely unfamiliar
> with fastboot, so sorry if this is all obvious).
>  
> The main partition of a system these days is measured in GB, I think.
> So why does going from 32MB to 256MB for the buffer make a useful
> difference?
> 
> Is there some enormous per-buffer overhead which needs to be amortised?
> Or is something else going on?
> 
> IOW what is the practical impact of this change?

It really depends on the image content you're trying to flash, but
there's two things to consider:

  - On a NAND device, you will just flash the actual content, but not
    the extra empty space in the partition, and the FS will
    automatically grow the first time you mount it.

  - If there's some blocks that are filled with the same content, the
    sparse image format I was refactoring earlier in that patchset
    will be able to compress it to 16 bytes (iirc), instead of a full
    block (512 bytes or a page, depending on whether you use an MMC or
    a NAND). On NAND images, there's often a lot of pages filled with
    0xff, which fall into that category, I'd expect it to be similar
    on block partitions for the extra space.

The current use case we have for example is to flash a 4GB partition
with a debian system, in a UBI partition. Even though it's a decent
system, storage size-wise, the file actually transfered and stored in
the memory is around 210MB once compressed, and 270MB if not
compressed.

Of course, this will all depend on the ratio between the empty space
and the files themselves, and what files you actually have there, but
while 32MB is definitely useless, 256MB is already a decent size.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/579d3bde/attachment.sig>