Re: Compressed kernels currently won't boot

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2019-07-31 at 23:44 +0200, Helge Deller wrote:
> On 31.07.19 22:49, James Bottomley wrote:
> > On Wed, 2019-07-31 at 22:19 +0200, Helge Deller wrote:
> > > 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  00001
> > > 000
> > >   2**2
> > >                     CONTENTS, ALLOC, LOAD, READONLY, CODE
> > >     1
> > > .opd          00000340  00000000000e0090  00000000000e0090  00001
> > > 090
> > >   2**3
> > >                     CONTENTS, ALLOC, LOAD, DATA
> > >     2
> > > .dlt          00000160  00000000000e03d0  00000000000e03d0  00001
> > > 3d0
> > >   2**3
> > >                     CONTENTS, ALLOC, LOAD, DATA
> > >     3 .rodata.compressed
> > > 01f3c2b0  00000000000e0530  00000000000e0530  00001530  2**0
> > >                     CONTENTS, ALLOC, LOAD, DATA
> > >     4
> > > .text         00005cc0  000000000201d000  000000000201d000  01f3e
> > > 000
> > >   2**7
> > >                     CONTENTS, ALLOC, LOAD, READONLY, CODE
> > >     5
> > > .data         00000060  0000000002022cc0  0000000002022cc0  01f43
> > > cc0
> > >   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).
> > 
> > Actually, you're looking at the wrong thing, you want to look at
> > the
> > program header (the segments) not the section header.  It's the
> > program
> > header we load.  If I extract this from the current debian kernel
> > we
> > get
> > 
> > jejb@ion:~/git/linux-build/arch/parisc/boot/compressed> readelf -l
> > /boot/vmlinuz-4.19.0-5-parisc64-smp
> > 
> > Elf file type is EXEC (Executable file)
> > Entry point 0xe0000
> > There are 4 program headers, starting at offset 64
> > 
> > Program Headers:
> >    Type           Offset             VirtAddr           PhysAddr
> >                   FileSiz            MemSiz              Flags  Ali
> > gn
> >    PHDR           0x0000000000000040 0x0000000000001040
> > 0x0000000000000000
> >                   0x00000000000000e0 0x00000000000000e0  R E    0x8
> >    LOAD           0x0000000000001000 0x00000000000e0000
> > 0x00000000000e0000
> >                   0x00000000000004d8
> > 0x00000000000004d8  RWE    0x1000
> >    LOAD           0x0000000000002000 0x0000000001400000
> > 0x0000000001400000
> >                   0x00000000003dd46c
> > 0x00000000003e1000  RWE    0x1000
> >    GNU_STACK      0x0000000000000000 0x0000000000000000
> > 0x0000000000000000
> >                   0x0000000000000000
> > 0x0000000000000000  RWE    0x10
> > 
> >   Section to Segment mapping:
> >    Segment Sections...
> >     00
> >     01     .head.text .opd .dlt
> >     02     .text .data .rodata .eh_frame .bss
> >     03
> > 
> > The two LOAD sections corresponding to what PALO actually loads.
> > The
> > problem happens if the length of the first load section is bigger
> > than
> > 0x20000.
> 
> What exactly is the problem if the first section is bigger than
> 0x20000?
> 
> > Now if you look what happens after your change:
> > jejb@ion:~/git/linux-build/build/parisc64/arch/parisc/boot> readelf
> > -l bzImage
> 
> Ok - bzImage is the same as ./vmlinuz.
> 
> > Elf file type is EXEC (Executable file)
> > Entry point 0xe0000
> > There are 4 program headers, starting at offset 64
> > 
> > Program Headers:
> >    Type           Offset             VirtAddr           PhysAddr
> >                   FileSiz            MemSiz              Flags  Ali
> > gn
> >    PHDR           0x0000000000000040 0x0000000000001040
> > 0x0000000000000000
> >                   0x00000000000000e0 0x00000000000000e0  R E    0x8
> >    LOAD           0x0000000000001000 0x00000000000e0000
> > 0x00000000000e0000
> >                   0x00000000004ae760
> > 0x00000000004ae760  RWE    0x1000
> >    LOAD           0x00000000004b0000 0x000000000118a000
> > 0x000000000118a000
> >                   0x0000000000006044
> > 0x000000000000a000  RWE    0x1000
> >    GNU_STACK  0    0x0000000000000000 0x0000000000000000
> > 0x0000000000000000
> >                   0x0000000000000000
> > 0x0000000000000000  RWE    0x10
> > 
> >   Section to Segment mapping:
> >    Segment Sections...
> >     00
> >     01     .head.text .opd .dlt .rodata.compressed
> >     02     .text .data .rodata .eh_frame .bss
> >     03
> > 
> > So the first section tries to load between 0x000e0000-0x0058e760
> > and
> > that's overwritten at 0x00100000 when the decompression starts
> > because
> > 0x00100000 is our KERNEL_BINARY_TEXT_START.
> 
> The decompression decompresses the image from .rodata.compressed
> to an area behind .bss.
> So, "vmlinux" ends up behind .bss for further processing.
> This "vmlinux" (which can have multiple ELF sections) is then started
> at the high address.
> That address is way above the 0x00100000 or KERNEL_BINARY_TEXT_START.
> It then finally moves itself (the ELF sections) to 0x00100000.
> 
> > The result for me is that
> > I get the Decompressing linux ... message followed by a HPMC.
> 
> It actually does boot for me and Sven without a HPMC.
> The decompression is slow (~40 seconds on my c3000 for 160MB).
> I still *believe* you are facing a HPMC because of other reasons.
> On which machine do you start.
> How much memory?

This turned out to be a very eccentric bug.  Apparently we don't have
an archclean target in our arch/parisc/Makefile, so files in there
never get cleaned out by make mrproper.  This, in turn means that the
sizes.h file in arch/parisc/boot/compressed never gets removed and
worse, when you transition to an O=build/parisc[64] build model it
overrides the generated file.  The upshot being my bzImage was building
with a SZ_end that was too small.

I fixed it by making mrproper clean everyting.

James

---

diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 8acb8fa1f8d6..945952166468 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -182,5 +182,8 @@ define archhelp
 	@echo  '  zinstall	- Install compressed vmlinuz kernel'
 endef
 
+archclean:
+	$(Q)$(MAKE) $(clean)=$(boot)
+
 archheaders:
 	$(Q)$(MAKE) $(build)=arch/parisc/kernel/syscalls all