linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: Compressed kernels currently won't boot
Date: Wed, 31 Jul 2019 21:57:40 +0200	[thread overview]
Message-ID: <b0b3cac2-682a-cde5-3a62-9aa8328431f8@gmx.de> (raw)
In-Reply-To: <1564591443.3319.30.camel@HansenPartnership.com>

On 31.07.19 18:44, 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
>
>      parisc: Include compressed vmlinux file in vmlinuz boot kernel
>
>
> Which moved the compressed vmlinux from the second segment to the
> first, which is what makes it too big for me.  This patch reverting
> that piece allows me to boot again.

There are two requirements:
1. Make sure not to use too much memory for "old" machines. Otherwise
you won't be able to boot a compressed kernel on e.g. a 16MB machine.

If you move the compressed data behind where the kernel would
self-extract itself, you double the amount of memory required.
I think with the patch below I won't be able to boot my 715/64
any longer.

2. Old palo versions had a bug which prevented the ELF loader
to load sections above 16MB. So, one needs to keep everything
thin in the low memory without extracting over oneself.

3. There might have been other reasons too, but currently I
don't remember :-)

I believe the the patch I sent for arch/parisc/boot/compressed/vmlinux.lds.S:
+       /* bootloader code and data starts at least behind area of extracted kernel */
+       . = MAX(ABSOLUTE(.), (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START));
keeps everything bootable (on low-memory-machines and with palo ELF bootloader bug).

Helge

>
> diff --git a/arch/parisc/boot/compressed/vmlinux.lds.S b/arch/parisc/boot/compressed/vmlinux.lds.S
> index bfd7872739a3..5841aa373c03 100644
> --- a/arch/parisc/boot/compressed/vmlinux.lds.S
> +++ b/arch/parisc/boot/compressed/vmlinux.lds.S
> @@ -42,12 +42,6 @@ SECTIONS
>   #endif
>   	_startcode_end = .;
>
> -	/* vmlinux.bin.gz is here */
> -	. = ALIGN(8);
> -	.rodata.compressed : {
> -		*(.rodata.compressed)
> -	}
> -
>   	/* bootloader code and data starts behind area of extracted kernel */
>   	. = (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START);
>
> @@ -73,6 +67,12 @@ SECTIONS
>   		*(.rodata.*)
>   		_erodata = . ;
>   	}
> +	/* vmlinux.bin.gz is here */
> +	. = ALIGN(8);
> +	.rodata.compressed : {
> +		*(.rodata.compressed)
> +	}
> +
>   	. = ALIGN(8);
>   	.bss : {
>   		_bss = . ;
>


      parent reply	other threads:[~2019-07-31 19:57 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
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 [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=b0b3cac2-682a-cde5-3a62-9aa8328431f8@gmx.de \
    --to=deller@gmx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).