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
