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

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. 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?

Regards
Sven

  reply	other threads:[~2019-07-31 17:30 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 [this message]
2019-07-31 17:50   ` James Bottomley
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=20190731173016.GA23520@t470p.stackframe.org \
    --to=svens@stackframe.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-parisc@vger.kernel.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.