All of lore.kernel.org
 help / color / mirror / Atom feed
From: joshc@codeaurora.org (Josh Cartwright)
To: linux-arm-kernel@lists.infradead.org
Subject: AArch64 kernel image decompression
Date: Mon, 13 Jan 2014 16:10:25 -0600	[thread overview]
Message-ID: <20140113221025.GU8153@joshc.qualcomm.com> (raw)
In-Reply-To: <20140113111733.GD1189@mudshark.cambridge.arm.com>

On Mon, Jan 13, 2014 at 11:17:33AM +0000, Will Deacon wrote:
> On Fri, Jan 10, 2014 at 05:04:36PM +0000, Josh Cartwright wrote:
> > Hey Will-
>
> Hi Josh,
>
> > Scanning the Documentation/arm64/booting.txt document, I came across
> > this, listing an optional step a bootloader might take:
> >
> > "The AArch64 kernel does not currently provide a decompressor and
> > therefore requires decompression (gzip, etc.) to be performed by the
> > boot loader if a compressed Image target (e.g. Image.gz) is used."
> >
> > Do you envision that, if a decompressor is desired, it will always be
> > the responsibility of a bootloader to implement it?
>
> That's certainly our current stance, yes. It also simplifies the booting
> code and things like EFI stub, so I'd be reluctant to consider adding a
> decompressor to the arm64 kernel without a compelling use-case.

Okay, thanks for the clarification.

> > In other words, would you accept patches adding support for building
> > zImages (and others) for AArch64?
> 
> Are these patches actually needed, or are you trying to find a project
> involving the arm64 kernel?

Really, I'm just trying to get a better handle on the difference in
booting requirements for 32-bit and 64-bit ARM kernels.  I haven't yet
determined whether compression is even necessary for our usecase.

If we did find it necessary and you had said "yes, we'd like in-kernel
decompression, but we haven't gotten around to it yet", then we'd likely
go down the path of implementing it.  Anyway, I'm probably getting too
far ahead of myself. :)

Thanks,
   Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

      parent reply	other threads:[~2014-01-13 22:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 17:04 AArch64 kernel image decompression Josh Cartwright
2014-01-13 11:17 ` Will Deacon
2014-01-13 11:29   ` bhupesh.sharma at freescale.com
2014-01-13 11:42     ` Arnd Bergmann
2014-01-14  3:52       ` bhupesh.sharma at freescale.com
2014-01-14  5:19         ` Olof Johansson
2014-01-14  6:14           ` Arnd Bergmann
2014-01-14 10:59             ` Russell King - ARM Linux
2014-01-14 16:48             ` Stephen Warren
2014-01-14 12:51       ` Marek Vasut
2014-01-14 13:38         ` bhupesh.sharma at freescale.com
2014-01-14 13:47           ` Wolfgang Denk
2014-01-14 17:19             ` Olof Johansson
2014-01-14 18:53               ` Wolfgang Denk
2014-01-15  4:37                 ` Olof Johansson
2014-01-13 22:10   ` Josh Cartwright [this message]

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=20140113221025.GU8153@joshc.qualcomm.com \
    --to=joshc@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.