Re: Compressed kernels currently won't boot

From: Helge Deller <deller@gmx.de>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	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 22:19:32 +0200	[thread overview]
Message-ID: <2fc63e1d-dbcf-924b-e134-e5c2dcc75260@gmx.de> (raw)
In-Reply-To: <1564602968.3319.56.camel@HansenPartnership.com>

On 31.07.19 21:56, James Bottomley wrote:
> On Wed, 2019-07-31 at 21:46 +0200, Helge Deller wrote:
>> On 31.07.19 21:44, Sven Schnelle wrote:
>>> Hi James,
>>>
>>> On Wed, Jul 31, 2019 at 12:40:12PM -0700, James Bottomley wrote:
>>>
>>>> What about causing the compressed make to build both a stripped
>>>> and a non-stripped bzImage (say sbzImage and bzImage).  That way
>>>> you always have the stripped one available for small size things
>>>> like boot from tape or DVD?  but in the usual case we use the
>>>> bzImage with full contents.
>>>
>>> In that case we would also need to build two lifimages - how about
>>> adding a config option option? Something like "Strip debug
>>> information from compressed kernel images"?
>>
>> I agree, two lifimages don't make sense. Only one vmlinuz gets
>> installed. Instead of the config option, I tink my latest patch is
>> better.
>
> It doesn't solve the problem that if a stripped compressed image is >
> 128kb then it overwrites the decompress area starting at 0x00100000 so
> we can't decompress the end because we've already overwritten it before
> the decompressor gets to it.

I don't get this point.
  hppa64-linux-gnu-objdump -h vmlinuz
shows:
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
   0 .head.text    00000084  00000000000e0000  00000000000e0000  00001000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .opd          00000340  00000000000e0090  00000000000e0090  00001090  2**3
                   CONTENTS, ALLOC, LOAD, DATA
   2 .dlt          00000160  00000000000e03d0  00000000000e03d0  000013d0  2**3
                   CONTENTS, ALLOC, LOAD, DATA
   3 .rodata.compressed 01f3c2b0  00000000000e0530  00000000000e0530  00001530  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   4 .text         00005cc0  000000000201d000  000000000201d000  01f3e000  2**7
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   5 .data         00000060  0000000002022cc0  0000000002022cc0  01f43cc0  2**3
                   CONTENTS, ALLOC, LOAD, DATA

Only .head.text gets loaded at e0000, and it is basically just a few bytes which
sets-up registers and jump to .text segment (at 0201d000 in this case).
See: arch/parisc/boot/compressed/head.S
How should that get bigger than 128KB ?

Then the code in .text decompresses the whole kernel image behind itself
(behind "data").
Then the ELF loader moves the parts from the high-memory to the final
destination (e.g. 1000000).

The steps are:
1. palo loads vmlinuz into memory.
2. vmlinuz' head starts, and decompress_kernel() in arch/parisc/boot/compressed/misc.c
decompresses the vmlinuz file to a vmlinux file and stores it to
vmlinux_addr (which is behind the bss section of the boot decompressor).
3. Then the original kernel entry is started (arch/parisc/kernel/entry.S)
which moves the code to where it belongs and starts the kernel.

Helge

> What we could possibly do is be clever and align the .rodata.compressed
> so its last text byte ends where the uncompressed kernel text would
> end.  We could be even more clever and split .rodata.compressed into a
> load and a noload part so we would only load the part of the compressed
> kernel we need.  Then the lifimage creation scripts could discard the
> noload part containing the debug symbols.
>
> James
>