All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Sven Schnelle <svens@stackframe.org>
Cc: Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: Compressed kernels currently won't boot
Date: Wed, 31 Jul 2019 10:50:02 -0700	[thread overview]
Message-ID: <1564595402.3319.40.camel@HansenPartnership.com> (raw)
In-Reply-To: <20190731173016.GA23520@t470p.stackframe.org>

On Wed, 2019-07-31 at 19:30 +0200, Sven Schnelle wrote:
> Hi,
> 
> On Wed, Jul 31, 2019 at 09:44:03AM -0700, James Bottomley wrote:
> > I noticed this trying to test out compressed kernel booting.  The
> > problem is that a compressed kernel is divided into two pieces, one
> > of which starts at 0x000e0000 and is the bootstrap code which is
> > uncompressed into 0x00100000 and the rest of which is the real
> > compressed kernel which is loaded above the end of the current
> > decompressed size of the entire kernel.  palo decompresses the head
> > and jumps to it and it then decompresses the rest of the kernel
> > into place.  This means that the first part of the compressed image
> > can't be larger than 0x20000 == 131072 because otherwise it will be
> > loaded into an area that decompression will alter.
> > 
> > The problem is that a change was introduced by 
> > 
> > commit 34c201ae49fe9e0bf3b389da5869d810f201c740
> > Author: Helge Deller <deller@gmx.de>
> > Date:   Mon Oct 15 22:14:01 2018 +0200
> 
> Hmm. This is what i've been facing as well.

Yes, except you're a more extreme case than me ... you actually have
the compressed segment overlapping the end of the decompressed text. 
that does seem to mean we have a lot of no-load debug information which
isn't useful to the compressed image.

>  After reading this commit i'm not sure that the patch i've just sent
> ("parisc: strip debug information when building compressed images")
> is really wanted. However, it is really a pain to always copy huge
> lifimages around when booting parisc machines via LAN. Does someone
> really extract the vmlinux file from a compressed kernel images?
> Should we keep that?

Well, it's a thing.  There's a script in the kernel source tree

scripts/extract-vmlinux

that does it.  It doesn't seem to be packaged by debian, though.

James


  reply	other threads:[~2019-07-31 17:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 16:44 Compressed kernels currently won't boot James Bottomley
2019-07-31 17:30 ` Sven Schnelle
2019-07-31 17:50   ` James Bottomley [this message]
2019-07-31 19:40     ` James Bottomley
2019-07-31 19:44       ` Sven Schnelle
2019-07-31 19:46         ` Helge Deller
2019-07-31 19:56           ` James Bottomley
2019-07-31 20:19             ` Helge Deller
2019-07-31 20:49               ` James Bottomley
2019-07-31 21:44                 ` Helge Deller
2019-08-01  1:37                   ` James Bottomley
2019-07-31 21:01         ` James Bottomley
2019-07-31 21:08           ` Sven Schnelle
2019-07-31 21:13             ` Helge Deller
2019-07-31 21:51               ` Helge Deller
2019-08-01  8:10                 ` Sven Schnelle
2019-07-31 19:57 ` Helge Deller

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=1564595402.3319.40.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=linux-parisc@vger.kernel.org \
    --cc=svens@stackframe.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.