summaryrefslogtreecommitdiff
path: root/arch/s390/boot/compressed/vmlinux.lds.S
AgeCommit message (Collapse)Author
2022-05-06s390/boot: get rid of startup archiveHeiko Carstens
The final kernel image is created by linking decompressor object files with a startup archive. The startup archive file however does not contain only optional code and data which can be discarded if not referenced. It also contains mandatory object data like head.o which must never be discarded, even if not referenced. Move the decompresser code and linker script to the boot directory and get rid of the startup archive so everything is kept during link time. Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/boot: move dma sections from decompressor to decompressed kernelAlexander Egorenkov
This change simplifies the task of making the decompressor relocatable. The decompressor's image contains special DMA sections between _sdma and _edma. This DMA segment is loaded at boot as part of the decompressor and then simply handed over to the decompressed kernel. The decompressor itself never uses it in any way. The primary reason for this is the need to keep the aforementioned DMA segment below 2GB which is required by architecture, and because the decompressor is always loaded at a fixed low physical address, it is guaranteed that the DMA region will not cross the 2GB memory limit. If the DMA region had been placed in the decompressed kernel, then KASLR would make this guarantee impossible to fulfill or it would be restricted to the first 2GB of memory address space. This commit moves all DMA sections between _sdma and _edma from the decompressor's image to the decompressed kernel's image. The complete DMA region is placed in the init section of the decompressed kernel and immediately relocated below 2GB at start-up before it is needed by other parts of the decompressed kernel. The relocation of the DMA region happens even if the decompressed kernel is already located below 2GB in order to keep the first implementation simple. The relocation should not have any noticeable impact on boot time because the DMA segment is only a couple of pages. After relocating the DMA sections, the kernel has to fix all references which point into it. In order to automate this, place all variables pointing into the DMA sections in a special .dma.refs section. All such variables must be defined using the new __dma_ref macro. Only variables containing addresses within the DMA sections must be placed in the new .dma.refs section. Furthermore, move the initialization of control registers from the decompressor to the decompressed kernel because some control registers reference tables that must be placed in the DMA data section to guarantee that their addresses are below 2G. Because the decompressed kernel relocates the DMA sections at startup, the content of control registers CR2, CR5 and CR15 must be updated with new addresses after the relocation. The decompressed kernel initializes all control registers early at boot and then updates the content of CR2, CR5 and CR15 as soon as the DMA relocation has occurred. This practically reverts the commit a80313ff91ab ("s390/kernel: introduce .dma sections"). Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/boot: move sclp early buffer from fixed address in asm to CAlexander Egorenkov
To make the decompressor relocatable, the early SCLP buffer with a fixed address must be replaced with a relocatable C buffer of the according size and alignment as required by SCLP. Introduce a new function sclp_early_set_buffer() into the SCLP driver which enables the decompressor to change the SCLP early buffer at any time. This will be useful when the decompressor becomes fully relocatable and might need to change the SCLP early buffer to one with an address < 2G as required by SCLP because it was loaded at an address >= 2G. Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-07-27s390/boot: make stacks part of the decompressor's imageAlexander Egorenkov
Instead of using constant addresses for the normal and dump-info stacks, allocate both stacks in the decompressor's image and load the stack register in a position-independent manner. This will allow loading and entering the decompressor at an arbitrary memory address without corrupting the content at the fixed addresses used until now for both stacks. This is one of the prerequisites for being able to kexec the decompressor from its load address without relocating it first. Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-12-09s390/boot: add build-id to decompressorPhilipp Rudo
More and more functionality from the early boot phase gets carried over to the decompressor. With this the complexity of the code and thus the chance to introduce bugs increases. In order to be able to debug these early boot bugs the distributions have to package the decompressors vmlinux together with the other debuginfos. However for that the distributions require the vmlinux to contain a build-id. Per default the section containing the build-id is placed first in the section table. So make sure to move it behind the .text section otherwise the image would be unbootable. Signed-off-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-11-20s390/decompressor: add symbols supportVasily Gorbik
Information printed by print_pgm_check_info() is crucial for debugging decompressor problems. Printing instruction addresses is better than nothing, but turns further debugging into tedious job of figuring out which function those addresses correspond to. This change adds simplistic symbols resolution support. And adds %pS format specifier support to decompressor_printk(). Decompressor symbols list is extracted and sorted with nm -n -S: ... 0000000000010000 0000000000000014 T startup 0000000000010014 00000000000000b0 t startup_normal 0000000000010180 00000000000000b2 t startup_kdump ... Then functions are filtered and contracted to a form: "10000 14 startup\0""10014 b0 startup_normal\0""10180 b2 startup_kdump\0" ... Which makes it trivial to find beginning of an entry and names are 0 terminated, so could be used as is. Symbols are binary-searched. To get symbols list with final addresses and then get it into the decompressor's image the same trick as for kallsyms is used. Decompressor's vmlinux is linked twice. Symbols are stored in .decompressor.syms section, current size is about 2kb. Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2020-09-16s390/boot: enable .bss section for compressed kernelAlexander Egorenkov
- Support static uninitialized variables in compressed kernel. - Remove chkbss script - Get rid of workarounds for not having .bss section Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21s390/startup: adjust _sdma and _edma to page boundariesVasily Gorbik
Move .dma.text section alignment out of section description, otherwise zeros used to align the section are included in the section itself (and section is not really aligned by itself). $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001e38 000000000001b1c8 000000000001b1c8 0001c1c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001b1c8..0x000000000001d2bf ... Also add alignment before _edma linker symbol definition, so that entire .dma* region is rounded up to page boundaries. $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001000 000000000001c000 000000000001c000 0001d000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001c000..0x000000000001dfff ... $ cat /sys/kernel/debug/kernel_page_tables ---[ Identity Mapping ]--- 0x0000000000000000-0x000000000001c000 112K PTE RW NX 0x000000000001c000-0x000000000001d000 4K PTE RO X 0x000000000001d000-0x0000000000100000 908K PTE RW NX ... Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-05-07s390/boot: fix compiler error due to missing awk strtonumMartin Schwidefsky
The strtonum awk function is a GNU extension and is not available with all versions of awk. The link of bzImage fails with this error message: >> awk: line 2: function or never defined >> awk: line 2: function strtonum never defined objcopy: --pad-to: bad number: arch/s390/boot/compressed/vmlinux Drop the awk script and the --pad-to objcopy parameter it generated and use a FILL pattern with an appropriate alignment in the linker script for the arch/s390/boot/compressed/vmlinux file. Fixes: f6780686525c ("s390/boot: pad bzImage to 4K") Reported-by: kbuild test robot <lkp@intel.com> Suggested-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-29s390/kernel: introduce .dma sectionsGerald Schaefer
With a relocatable kernel that could reside at any place in memory, code and data that has to stay below 2 GB needs special handling. This patch introduces .dma sections for such text, data and ex_table. The sections will be part of the decompressor kernel, so they will not be relocated and stay below 2 GB. Their location is passed over to the decompressed / relocated kernel via the .boot.preserved.data section. The duald and aste for control register setup also need to stay below 2 GB, so move the setup code from arch/s390/kernel/head64.S to arch/s390/boot/head.S. The duct and linkage_stack could reside above 2 GB, but their content has to be preserved for the decompresed kernel, so they are also moved into the .dma section. The start and end address of the .dma sections is added to vmcoreinfo, for crash support, to help debugging in case the kernel crashed there. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10s390: introduce .boot.preserved.data sectionGerald Schaefer
Introduce .boot.preserve.data section which is similar to .boot.data and "shared" between the decompressor code and the decompressed kernel. The decompressor will store values in it, and copy over to the decompressed image before starting it. This method allows to avoid using pre-defined addresses and other hacks to pass values between those boot phases. Unlike .boot.data section .boot.preserved.data is NOT a part of init data, and hence will be preserved for the kernel life time. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09s390: introduce .boot.data sectionVasily Gorbik
Introduce .boot.data section which is "shared" between the decompressor code and the decompressed kernel. The decompressor will store values in it, and copy over to the decompressed image before starting it. This method allows to avoid using pre-defined addresses and other hacks to pass values between those boot phases. .boot.data section is a part of init data, and will be freed after kernel initialization is complete. For uncompressed kernel image, .boot.data section is basically the same as .init.data Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09s390/decompressor: rework uncompressed image info collectionVasily Gorbik
The kernel decompressor has to know several bits of information about uncompressed image. Currently this info is collected by running "nm" on uncompressed vmlinux + "sed" and producing sizes.h file. This method worked well, but it has several disadvantages. Obscure symbols name pattern matching is fragile. Adding new values makes pattern even longer. Logic is spread across code and make file. Limited ability to adjust symbols values (currently magic lma value of 0x100000 is always subtracted). Apart from that same pieces of information (and more) would be needed for early memory detection and features like KASLR outside of boot/compressed/ folder where sizes.h is generated. To overcome limitations new "struct vmlinux_info" has been introduced to include values needed for the decompressor and the rest of the boot code. The only static instance of vmlinux_info is produced during vmlinux link step by filling in struct fields by the linker (like it is done with input_data in boot/compressed/vmlinux.scr.lds.S). This way individual values could be adjusted with all the knowledge linker has and arithmetic it supports. Later .vmlinux.info section (which contains struct vmlinux_info) is transplanted into the decompressor image and dropped from uncompressed image altogether. While doing that replace "compressed/vmlinux.scr.lds.S" linker script (whose purpose is to rename .data section in piggy.o to .rodata.compressed) with plain objcopy command. And simplify decompressor's linker script. Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-07-02s390/decompressor: correct EXCLUDE_FILE constructVasily Gorbik
The following linker construct is problematic with linkers of binutils < 2.28: EXCLUDE_FILE (*piggy.o) *(.rodata.*) from 8f1732fc2a11dc of binutils: "though the linker accepts this without complaint the EXCLUDE_FILE part is silently ignored and has no effect." Silent ignoring of EXCLUDE_FILE construct made .rodata.compressed be part of .rodata, and in case of .rodata.compressed following some unaligned data, input_len would also become unaligned. from arch/s390/boot/compressed/vmlinux.map: .rodata.compressed 0x0000000000012fea 0x4d57e7 arch/s390/boot/compressed/piggy.o 0x0000000000012fea input_len 0x0000000000012fee input_data input_len is later used here: arch/s390/boot/compressed/misc.c:113 __decompress(input_data, input_len, NULL, NULL, output, 0, NULL, error); asm generated by gcc looks like: .loc 3 113 0 egfrl %r11,input_len from what assembler generates invalid (the second operand must be aligned on a doubleword boundary): 0x00000000000129b4 <+148>: c4 bc 00 00 03 1b lgfrl %r11,0x12fea hence specification exception is recognized. To avoid an issue use EXCLUDE_FILE construct which is recognized by older linkers (since at least binutils-2_11) *(EXCLUDE_FILE (*piggy.o) .rodata.compressed) Also ensure that .rodata.compressed is at least doubleword aligned. Fixes: 89b5202e81df ("s390/decompressor: support uncompressed kernel") Reported-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-07-02s390/decompressor: discard ___kcrctab sectionVasily Gorbik
___kcrctab section is not used during the decompressor phase and could be discarded to save the memory. It is currently generated due to lib/mem.S usage, which exports few symbols. Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-06-25s390/decompressor: support uncompressed kernelVasily Gorbik
Implement uncompressed kernel support (when "None" is picked in kernel compression mode list). In that case an actual decompression code is skipped and control is passed from boot/head.S to startup_continue in kernel/head64.S. To achieve that uncompressed kernel payload is conditionally put at 0x100000 in bzImage. In reality this is very close to classic uncompressed kernel "image", but the decompressor has its own build and link process, kernel/head64.S lives at 0x100000 rather than at 0x11000, and .bss section is reused for both stages. Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-02-27s390/decompressor: discard __ex_table sectionVasily Gorbik
Exception table (__ex_table section) is not used during the decompressor phase and could be discarded to save the memory. It is currently generated due to sclp_service_call function (sclp_early_core.c). An assumption is that decompressor usage of sclp_service_call via sclp_early_printk should never trigger exceptions. Signed-off-by: Vasily Gorbik <gor@linux.vnet.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-01-23s390/decompressor: discard __ksymtab and .eh_frame sectionsVasily Gorbik
__ksymtab sections created for exported symbols are not needed during the decompressor phase and could be discarded to save the memory. The source of those exports is ebcdic.o, which is linked into both vmlinux and boot/compressed/vmlinux. .eh_frame section is also unused and could be discarded from boot/compressed/vmlinux. The same has been done for vmlinux in: "s390/kernel: emit CFI data in .debug_frame and discard .eh_frame sections". Signed-off-by: Vasily Gorbik <gor@linux.vnet.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-01-23s390/decompressor: swap .text and .rodata.compressed sectionsVasily Gorbik
.rodata.compressed section contains compressed linux image and is quite large. By swapping text and rodata.compressed sections, the decompressor code ends up between 0x11000 and 0x100000 addresses, which makes it easier: - to distinguish the decompressor phase from decompressed code (which lives above 0x100000, except for small startup_continue), - define break points which don't intersect with the main kernel image later. Signed-off-by: Vasily Gorbik <gor@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-25s390: remove 31 bit supportHeiko Carstens
Remove the 31 bit support in order to reduce maintenance cost and effectively remove dead code. Since a couple of years there is no distribution left that comes with a 31 bit kernel. The 31 bit kernel also has been broken since more than a year before anybody noticed. In addition I added a removal warning to the kernel shown at ipl for 5 minutes: a960062e5826 ("s390: add 31 bit warning message") which let everybody know about the plan to remove 31 bit code. We didn't get any response. Given that the last 31 bit only machine was introduced in 1999 let's remove the code. Anybody with 31 bit user space code can still use the compat mode. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-10-18s390: fix linker script for 31 bit buildsHeiko Carstens
Because of a change in the s390 arch backend of binutils (commit 23ecd77 "Pick the default arch depending on the target size" in binutils repo) 31 bit builds will fail since the linker would now try to create 64 bit binary output. Fix this by setting OUTPUT_ARCH to s390:31-bit instead of s390. Thanks to Andreas Krebbel for figuring out the issue. Fixes this build error: LD init/built-in.o s390x-4.7.2-ld: s390:31-bit architecture of input file `arch/s390/kernel/head.o' is incompatible with s390:64-bit output Cc: Andreas Krebbel <Andreas.Krebbel@de.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-02-26[S390] add support for compressed kernelsMartin Schwidefsky
Add the "bzImage" compile target and the necessary code to generate compressed kernel images. The old style uncompressed "image" target is preserved, a simple make will build them both. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>