All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] gunzip: add gzwrite routine for extracting compresed images to block device
Date: Tue, 17 Feb 2015 20:46:14 +0100	[thread overview]
Message-ID: <201502172046.14198.marex@denx.de> (raw)
In-Reply-To: <54E229EF.2080307@boundarydevices.com>

On Monday, February 16, 2015 at 06:33:35 PM, Eric Nelson wrote:
> Hi Tom and Marek,
> 
> On 02/16/2015 10:03 AM, Tom Rini wrote:
> > On Mon, Feb 16, 2015 at 05:27:59PM +0100, Marek Vasut wrote:
> >> On Monday, February 16, 2015 at 12:16:06 AM, Eric Nelson wrote:
> >>> Initial filesystem images are generally highly compressible.
> >>> 
> >>> Add a routine gzwrite that allows gzip-compressed images to be
> >>> written to block devices.
> >>> 
> >>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> >> 
> >> Hi!
> >> 
> >> Stupid question -- can't you compress the thing in DRAM and then
> >> use fatwrite or ext4write to write it to FS? Or are you really
> >> after writing the data to a raw block device (in which case, you
> >> can use similar commands for raw block devices) ?
> > 
> > I _think_ (and I really hope so otherwise yes, this series needs
> > more expanation) that was this adds is the ability to {de,}compress
> > on the
> 
> (or explanation ;))
> 
> Sometimes words fail. I thought that was clear from the commit
> message but apparently not.
> 
> > fly rather than need to duplicate in DDR which could be
> > hard-to-impossible depending on the size of the data in question.
> 
> That's exactly right.
> 
> The purpose of this is to aid in loading images onto storage devices
> like eMMC where the storage size usually exceeds the size of RAM,
> but the compressed image size doesn't.
> 
> Even if the compressed image size does exceed RAM, the gzwrite
> routine and command give you the ability to do things piecewise,
> and save lots of read transfer time.
> 
> To give a quick concrete example, we were looking at programming a
> relatively small (100's) batch of boards that use a very light
> O/S, but have 4GiB of eMMC.
> 
> Using ums takes over 25 minutes per board, but loading board.img.gz
> and using gzwrite takes 5-6, which is pretty close to optimal given
> the speed of the eMMC chip.
> 
> My hope is that this is useful as is, and also that the gzwrite
> routine can be worked into the fastboot protocol.
> 
> Transferring gigabytes of data is slow over USB 2.0 and storage
> sizes keep getting bigger.

Cool, thanks for explaining :)

Best regards,
Marek Vasut

  reply	other threads:[~2015-02-17 19:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-15 23:16 [U-Boot] [PATCH 1/2] gunzip: add gzwrite routine for extracting compresed images to block device Eric Nelson
2015-02-15 23:16 ` [U-Boot] [PATCH 2/2] unzip: add gzwrite command to write compressed image " Eric Nelson
2015-04-23 13:14   ` [U-Boot] [U-Boot, " Tom Rini
2015-02-16 16:27 ` [U-Boot] [PATCH 1/2] gunzip: add gzwrite routine for extracting compresed images " Marek Vasut
2015-02-16 17:03   ` Tom Rini
2015-02-16 17:33     ` Eric Nelson
2015-02-17 19:46       ` Marek Vasut [this message]
2015-02-17 18:30 ` [U-Boot] [PATCH V2 " Eric Nelson
2015-02-23 18:59   ` Eric Nelson
2015-02-23 22:33   ` Tom Rini
2015-02-24  0:43     ` Eric Nelson
2015-04-23 13:13   ` [U-Boot] [U-Boot, V2, " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201502172046.14198.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.