renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-15 08:44:14 +08:00
Code
7aa0055e06
linux-next/arch/s390/Makefile

174 lines
5.4 KiB
Makefile
Raw Normal View History

s390: add SPDX identifiers to the remaining files It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the remaining arch/s390/ files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-24 22:00:38 +08:00
# SPDX-License-Identifier: GPL-2.0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
#
# s390/Makefile
#
# This file is included by the global makefile so that you can add your own
# architecture-specific flags and dependencies. Remember to do have actions
# for "archclean" and "archdep" for cleaning up and making dependencies for
# this architecture
#
# Copyright (C) 1994 by Linus Torvalds
#
[S390] add support for compressed kernels 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>
2010-02-27 05:37:53 +08:00
LD_BFD := elf64-s390
kbuild: rename LDFLAGS to KBUILD_LDFLAGS Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS. For some reason, LDFLAGS was not renamed. Using a well-known variable like LDFLAGS may result in accidental override of the variable. Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention. I did not touch Makefiles under tools/ since the tools build system is a different world. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
2018-08-24 07:20:39 +08:00
KBUILD_LDFLAGS := -m elf64_s390
s390: use -fPIC for module compile The xfs module uses a lot of tracepoint, with TRACEPOINTS=y and a few debugging options the GOT table of the xfs module will get bigger than 4K. To get a working xfs module it needs to be compiled with -fPIC instead of -fpic. To play safe use -fPIC for all modules. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-01-11 22:26:01 +08:00
KBUILD_AFLAGS_MODULE += -fPIC
KBUILD_CFLAGS_MODULE += -fPIC
kbuild: enable 'make AFLAGS=...' to add additional options to AS The variable AFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of AFLAGS with KBUILD_AFLAGS all over the tree. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k, s390 Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-16 03:59:31 +08:00
KBUILD_AFLAGS += -m64
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
KBUILD_CFLAGS += -m64
s390/decompressor: support extra debug flags Since decompressor cflags and aflags are made from scratch add extra debug flags when CONFIG_DEBUG_INFO is enabled. Also adds support for CONFIG_DEBUG_INFO_DWARF4 option. 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-29 01:22:21 +08:00
aflags_dwarf := -Wa,-gdwarf-2
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
KBUILD_AFLAGS_DECOMPRESSOR := -m64 -D__ASSEMBLY__
s390/decompressor: support extra debug flags Since decompressor cflags and aflags are made from scratch add extra debug flags when CONFIG_DEBUG_INFO is enabled. Also adds support for CONFIG_DEBUG_INFO_DWARF4 option. 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-29 01:22:21 +08:00
KBUILD_AFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),$(aflags_dwarf))
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
KBUILD_CFLAGS_DECOMPRESSOR := -m64 -O2
KBUILD_CFLAGS_DECOMPRESSOR += -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY
KBUILD_CFLAGS_DECOMPRESSOR += -fno-delete-null-pointer-checks -msoft-float
KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-option,-ffreestanding)
s390/decompressor: support extra debug flags Since decompressor cflags and aflags are made from scratch add extra debug flags when CONFIG_DEBUG_INFO is enabled. Also adds support for CONFIG_DEBUG_INFO_DWARF4 option. 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-29 01:22:21 +08:00
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
UTS_MACHINE := s390x
s390/kasan: increase instrumented stack size to 64k Increase kasan instrumented kernel stack size from 32k to 64k. Other architectures seems to get away with just doubling kernel stack size under kasan, but on s390 this appears to be not enough due to bigger frame size. The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting stack overflow is fs sync on xfs filesystem: #0 [9a0681e8] 704 bytes check_usage at 34b1fc #1 [9a0684a8] 432 bytes check_usage at 34c710 #2 [9a068658] 1048 bytes validate_chain at 35044a #3 [9a068a70] 312 bytes __lock_acquire at 3559fe #4 [9a068ba8] 440 bytes lock_acquire at 3576ee #5 [9a068d60] 104 bytes _raw_spin_lock at 21b44e0 #6 [9a068dc8] 1992 bytes enqueue_entity at 2dbf72 #7 [9a069590] 1496 bytes enqueue_task_fair at 2df5f0 #8 [9a069b68] 64 bytes ttwu_do_activate at 28f438 #9 [9a069ba8] 552 bytes try_to_wake_up at 298c4c #10 [9a069dd0] 168 bytes wake_up_worker at 23f97c #11 [9a069e78] 200 bytes insert_work at 23fc2e #12 [9a069f40] 648 bytes __queue_work at 2487c0 #13 [9a06a1c8] 200 bytes __queue_delayed_work at 24db28 #14 [9a06a290] 248 bytes mod_delayed_work_on at 24de84 #15 [9a06a388] 24 bytes kblockd_mod_delayed_work_on at 153e2a0 #16 [9a06a3a0] 288 bytes __blk_mq_delay_run_hw_queue at 158168c #17 [9a06a4c0] 192 bytes blk_mq_run_hw_queue at 1581a3c #18 [9a06a580] 184 bytes blk_mq_sched_insert_requests at 15a2192 #19 [9a06a638] 1024 bytes blk_mq_flush_plug_list at 1590f3a #20 [9a06aa38] 704 bytes blk_flush_plug_list at 1555028 #21 [9a06acf8] 320 bytes schedule at 219e476 #22 [9a06ae38] 760 bytes schedule_timeout at 21b0aac #23 [9a06b130] 408 bytes wait_for_common at 21a1706 #24 [9a06b2c8] 360 bytes xfs_buf_iowait at fa1540 #25 [9a06b430] 256 bytes __xfs_buf_submit at fadae6 #26 [9a06b530] 264 bytes xfs_buf_read_map at fae3f6 #27 [9a06b638] 656 bytes xfs_trans_read_buf_map at 10ac9a8 #28 [9a06b8c8] 304 bytes xfs_btree_kill_root at e72426 #29 [9a06b9f8] 288 bytes xfs_btree_lookup_get_block at e7bc5e #30 [9a06bb18] 624 bytes xfs_btree_lookup at e7e1a6 #31 [9a06bd88] 2664 bytes xfs_alloc_ag_vextent_near at dfa070 #32 [9a06c7f0] 144 bytes xfs_alloc_ag_vextent at dff3ca #33 [9a06c880] 1128 bytes xfs_alloc_vextent at e05fce #34 [9a06cce8] 584 bytes xfs_bmap_btalloc at e58342 #35 [9a06cf30] 1336 bytes xfs_bmapi_write at e618de #36 [9a06d468] 776 bytes xfs_iomap_write_allocate at ff678e #37 [9a06d770] 720 bytes xfs_map_blocks at f82af8 #38 [9a06da40] 928 bytes xfs_writepage_map at f83cd6 #39 [9a06dde0] 320 bytes xfs_do_writepage at f85872 #40 [9a06df20] 1320 bytes write_cache_pages at 73dfe8 #41 [9a06e448] 208 bytes xfs_vm_writepages at f7f892 #42 [9a06e518] 88 bytes do_writepages at 73fe6a #43 [9a06e570] 872 bytes __writeback_single_inode at a20cb6 #44 [9a06e8d8] 664 bytes writeback_sb_inodes at a23be2 #45 [9a06eb70] 296 bytes __writeback_inodes_wb at a242e0 #46 [9a06ec98] 928 bytes wb_writeback at a2500e #47 [9a06f038] 848 bytes wb_do_writeback at a260ae #48 [9a06f388] 536 bytes wb_workfn at a28228 #49 [9a06f5a0] 1088 bytes process_one_work at 24a234 #50 [9a06f9e0] 1120 bytes worker_thread at 24ba26 #51 [9a06fe40] 104 bytes kthread at 26545a #52 [9a06fea8] kernel_thread_starter at 21b6b62 To be able to increase the stack size to 64k reuse LLILL instruction in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE (65192) value as unsigned. Reported-by: Benjamin Block <bblock@linux.ibm.com> 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-10-26 21:29:59 +08:00
STACK_SIZE := $(if $(CONFIG_KASAN),65536,16384)
kbuild: add endianness flag to CHEKCFLAGS The kernel depends on macros like __BYTE_ORDER__, __BIG_ENDIAN__ or __LITTLE_ENDIAN__. OTOH, sparse doesn't know about the endianness of the kernel and by default uses the same as the machine on which sparse was built. Ensure that sparse can predefine the macros corresponding to how the kernel was configured by adding -m{big,little}-endian to CHECKFLAGS in the main Makefile (and so for all archs). Also, remove the equivalent done in arch specific Makefiles. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29 02:27:35 +08:00
CHECKFLAGS += -D__s390__ -D__s390x__
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
[S390] add support for compressed kernels 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>
2010-02-27 05:37:53 +08:00
export LD_BFD
s390: pass march flag to assembly files as well Currently the march flag gets only passed to C files, but not to assembler files. This means that we can't add new instructions like e.g. aghik to asm files, since the assembler doesn't know of the new instructions if the appropriate march flag isn't specified. So also pass the march flag when compiling assembler files as well. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-08-14 22:06:02 +08:00
mflags-$(CONFIG_MARCH_Z900) := -march=z900
mflags-$(CONFIG_MARCH_Z990) := -march=z990
mflags-$(CONFIG_MARCH_Z9_109) := -march=z9-109
mflags-$(CONFIG_MARCH_Z10) := -march=z10
mflags-$(CONFIG_MARCH_Z196) := -march=z196
mflags-$(CONFIG_MARCH_ZEC12) := -march=zEC12
s390: add support for IBM z14 machines Add detection for machine type 0x3906 and set the ELF platform name to z14. Add the miscellaneous-instruction-extension 2 facility to the list of facilities for z14. And allow to generate code that only runs on a z14 machine. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-04-12 20:17:25 +08:00
mflags-$(CONFIG_MARCH_Z13) := -march=z13
mflags-$(CONFIG_MARCH_Z14) := -march=z14
s390: pass march flag to assembly files as well Currently the march flag gets only passed to C files, but not to assembler files. This means that we can't add new instructions like e.g. aghik to asm files, since the assembler doesn't know of the new instructions if the appropriate march flag isn't specified. So also pass the march flag when compiling assembler files as well. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-08-14 22:06:02 +08:00
s390/sclp: convert early sclp console code to C The 31-bit assembler code for the early sclp console is error prone as git commit fde24b54d976cc123506695c17db01438a11b673 "s390/sclp: clear upper register halves in _sclp_print_early" has shown. Convert the assembler code to C. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-08 16:20:04 +08:00
export CC_FLAGS_MARCH := $(mflags-y)
s390: pass march flag to assembly files as well Currently the march flag gets only passed to C files, but not to assembler files. This means that we can't add new instructions like e.g. aghik to asm files, since the assembler doesn't know of the new instructions if the appropriate march flag isn't specified. So also pass the march flag when compiling assembler files as well. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-08-14 22:06:02 +08:00
aflags-y += $(mflags-y)
cflags-y += $(mflags-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
s390: allow to set gcc -mtune flag Add a new Kconfig choice group which allows to configure how gcc should tune the generated code (via -mtune option). By default the -mtune parameter will match the -march parameter. This is a rather large patch, but I wouldn't know how to make this shorter unfortunately. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-10-30 19:12:50 +08:00
cflags-$(CONFIG_MARCH_Z900_TUNE) += -mtune=z900
cflags-$(CONFIG_MARCH_Z990_TUNE) += -mtune=z990
cflags-$(CONFIG_MARCH_Z9_109_TUNE) += -mtune=z9-109
cflags-$(CONFIG_MARCH_Z10_TUNE) += -mtune=z10
cflags-$(CONFIG_MARCH_Z196_TUNE) += -mtune=z196
cflags-$(CONFIG_MARCH_ZEC12_TUNE) += -mtune=zEC12
s390: add support for IBM z14 machines Add detection for machine type 0x3906 and set the ELF platform name to z14. Add the miscellaneous-instruction-extension 2 facility to the list of facilities for z14. And allow to generate code that only runs on a z14 machine. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-04-12 20:17:25 +08:00
cflags-$(CONFIG_MARCH_Z13_TUNE) += -mtune=z13
cflags-$(CONFIG_MARCH_Z14_TUNE) += -mtune=z14
s390: allow to set gcc -mtune flag Add a new Kconfig choice group which allows to configure how gcc should tune the generated code (via -mtune option). By default the -mtune parameter will match the -march parameter. This is a rather large patch, but I wouldn't know how to make this shorter unfortunately. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-10-30 19:12:50 +08:00
s390: add assembler include path for vx-insn.h With git commit 0eab11c7e0d30de14a15ccd8269eef238321a8e1 "s390/vx: allow to include vx-insn.h with .include" and an older gcc we get errors like this: {standard input}:6: Error: can't open asm/vx-insn.h for reading: No such file or directory arch/s390/kernel/fpu.c:57: Error: Unrecognized opcode: `vstm' To solve this issue simply add the path to arch/s390/include to all assembler runs. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-09-06 16:46:36 +08:00
cflags-y += -Wa,-I$(srctree)/arch/$(ARCH)/include
[PATCH] lockdep: s390 CONFIG_FRAME_POINTER support CONFIG_FRAME_POINTER support for s390. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Ingo Molnar <mingo@elte.hu> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-03 15:24:38 +08:00
#
# Prevent tail-call optimizations, to get clearer backtraces:
#
cflags-$(CONFIG_FRAME_POINTER) += -fno-optimize-sibling-calls
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
ifeq ($(call cc-option-yn,-mpacked-stack),y)
cflags-$(CONFIG_PACK_STACK) += -mpacked-stack -D__PACK_STACK
aflags-$(CONFIG_PACK_STACK) += -D__PACK_STACK
endif
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
KBUILD_AFLAGS_DECOMPRESSOR += $(aflags-y)
KBUILD_CFLAGS_DECOMPRESSOR += $(cflags-y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
ifeq ($(call cc-option-yn,-mstack-size=8192 -mstack-guard=128),y)
cflags-$(CONFIG_CHECK_STACK) += -mstack-size=$(STACK_SIZE)
[S390] Improved kernel stack overflow checking. Recent cvs versions of gcc have support for an improved stack overflow checking that calculates the size of the guard size for each function. If the compiler accepts -mstack-size without -mstack-guard then the new stack check is available. We always want to use the new stack checker. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2007-04-27 22:01:46 +08:00
ifneq ($(call cc-option-yn,-mstack-size=8192),y)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
cflags-$(CONFIG_CHECK_STACK) += -mstack-guard=$(CONFIG_STACK_GUARD)
endif
[S390] Improved kernel stack overflow checking. Recent cvs versions of gcc have support for an improved stack overflow checking that calculates the size of the guard size for each function. If the compiler accepts -mstack-size without -mstack-guard then the new stack check is available. We always want to use the new stack checker. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2007-04-27 22:01:46 +08:00
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
ifdef CONFIG_WARN_DYNAMIC_STACK
ifeq ($(call cc-option-yn,-mwarn-dynamicstack),y)
KBUILD_CFLAGS += -mwarn-dynamicstack
KBUILD_CFLAGS_DECOMPRESSOR += -mwarn-dynamicstack
endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
endif
s390: introduce execute-trampolines for branches Add CONFIG_EXPOLINE to enable the use of the new -mindirect-branch= and -mfunction_return= compiler options to create a kernel fortified against the specte v2 attack. With CONFIG_EXPOLINE=y all indirect branches will be issued with an execute type instruction. For z10 or newer the EXRL instruction will be used, for older machines the EX instruction. The typical indirect call basr %r14,%r1 is replaced with a PC relative call to a new thunk brasl %r14,__s390x_indirect_jump_r1 The thunk contains the EXRL/EX instruction to the indirect branch __s390x_indirect_jump_r1: exrl 0,0f j . 0: br %r1 The detour via the execute type instruction has a performance impact. To get rid of the detour the new kernel parameter "nospectre_v2" and "spectre_v2=[on,off,auto]" can be used. If the parameter is specified the kernel and module code will be patched at runtime. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-01-26 19:46:47 +08:00
ifdef CONFIG_EXPOLINE
ifeq ($(call cc-option-yn,$(CC_FLAGS_MARCH) -mindirect-branch=thunk),y)
CC_FLAGS_EXPOLINE := -mindirect-branch=thunk
CC_FLAGS_EXPOLINE += -mfunction-return=thunk
CC_FLAGS_EXPOLINE += -mindirect-branch-table
export CC_FLAGS_EXPOLINE
s390: add automatic detection of the spectre defense Automatically decide between nobp vs. expolines if the spectre_v2=auto kernel parameter is specified or CONFIG_EXPOLINE_AUTO=y is set. The decision made at boot time due to CONFIG_EXPOLINE_AUTO=y being set can be overruled with the nobp, nospec and spectre_v2 kernel parameters. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-03-23 20:04:49 +08:00
cflags-y += $(CC_FLAGS_EXPOLINE) -DCC_USING_EXPOLINE
s390: disable asm code expolines if cc does not support it To avoid a mixture of asm code with expolines and c code without them, propagate CC_USING_EXPOLINE to KBUILD_AFLAGS and use it to detect whether asm code should have expolines or not. 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-06-15 16:22:18 +08:00
aflags-y += -DCC_USING_EXPOLINE
s390: introduce execute-trampolines for branches Add CONFIG_EXPOLINE to enable the use of the new -mindirect-branch= and -mfunction_return= compiler options to create a kernel fortified against the specte v2 attack. With CONFIG_EXPOLINE=y all indirect branches will be issued with an execute type instruction. For z10 or newer the EXRL instruction will be used, for older machines the EX instruction. The typical indirect call basr %r14,%r1 is replaced with a PC relative call to a new thunk brasl %r14,__s390x_indirect_jump_r1 The thunk contains the EXRL/EX instruction to the indirect branch __s390x_indirect_jump_r1: exrl 0,0f j . 0: br %r1 The detour via the execute type instruction has a performance impact. To get rid of the detour the new kernel parameter "nospectre_v2" and "spectre_v2=[on,off,auto]" can be used. If the parameter is specified the kernel and module code will be patched at runtime. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-01-26 19:46:47 +08:00
endif
endif
s390/ftrace: hotpatch support for function tracing Make use of gcc's hotpatch support to generate better code for ftrace function tracing. The generated code now contains only a six byte nop in each function prologue instead of a 24 byte code block which will be runtime patched to support function tracing. With the new code generation the runtime overhead for supporting function tracing is close to zero, while the original code did show a significant performance impact. Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-01-09 20:08:28 +08:00
ifdef CONFIG_FUNCTION_TRACER
s390/ftrace: Add -mfentry and -mnop-mcount support Utilize -mfentry and -mnop-mcount gcc options together with -mrecord-mcount to get compiler generated calls to the profiling functions as nops which are compatible with current -mhotpatch=0,3 approach. At the same time -mrecord-mcount enables __mcount_loc section generation by the compiler which allows to avoid using scripts/recordmcount.pl script. Link: http://lkml.kernel.org/r/patch-4.thread-aa7b8d.git-aa7b8dbf236f.your-ad-here.call-01533557518-ext-9465@work.hours Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-08-06 21:17:47 +08:00
ifeq ($(call cc-option-yn,-mfentry -mnop-mcount),n)
# make use of hotpatch feature if the compiler supports it
cc_hotpatch := -mhotpatch=0,3
ifeq ($(call cc-option-yn,$(cc_hotpatch)),y)
CC_FLAGS_FTRACE := $(cc_hotpatch)
KBUILD_AFLAGS += -DCC_USING_HOTPATCH
KBUILD_CFLAGS += -DCC_USING_HOTPATCH
endif
endif
s390/ftrace: hotpatch support for function tracing Make use of gcc's hotpatch support to generate better code for ftrace function tracing. The generated code now contains only a six byte nop in each function prologue instead of a 24 byte code block which will be runtime patched to support function tracing. With the new code generation the runtime overhead for supporting function tracing is close to zero, while the original code did show a significant performance impact. Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-01-09 20:08:28 +08:00
endif
s390/vdso: revise CFI annotations of vDSO functions Revise and add CFI CFA and register rule annotations to the vDSO functions for proper stack unwinding and debugging. Because glibc might call the vDSO in special ways, the vDSO code does not rely on a stack frame created by the caller. The TOD clock value can be therefore not stored in the pre-allocated stack area and additional stack space is required. To correctly annotate these situations with CFI, the .cfi_val_offset directive is required to create relative offsets on the value of the stack register %r15. Because the .cfi_val_offset directive is available with recent GNU assembler versions only, additional checks are necessary. Note that if the vDSO is assembled with an older assembler version, stack unwinding and debugging from within the vDSO code might not be possible. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-20 18:46:13 +08:00
# Test CFI features of binutils
cfi := $(call as-instr,.cfi_startproc\n.cfi_val_offset 15$(comma)-160\n.cfi_endproc,-DCONFIG_AS_CFI_VAL_OFFSET=1)
kbuild: enable 'make CFLAGS=...' to add additional options to CC The variable CFLAGS is a wellknown variable and the usage by kbuild may result in unexpected behaviour. On top of that several people over time has asked for a way to pass in additional flags to gcc. This patch replace use of CFLAGS with KBUILD_CFLAGS all over the tree and enabling one to use: make CFLAGS=... to specify additional gcc commandline options. One usecase is when trying to find gcc bugs but other use cases has been requested too. Patch was tested on following architectures: alpha, arm, i386, x86_64, mips, sparc, sparc64, ia64, m68k Test was simple to do a defconfig build, apply the patch and check that nothing got rebuild. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-15 04:21:35 +08:00
KBUILD_CFLAGS += -mbackchain -msoft-float $(cflags-y)
KBUILD_CFLAGS += -pipe -fno-strength-reduce -Wno-sign-compare
s390/vdso: revise CFI annotations of vDSO functions Revise and add CFI CFA and register rule annotations to the vDSO functions for proper stack unwinding and debugging. Because glibc might call the vDSO in special ways, the vDSO code does not rely on a stack frame created by the caller. The TOD clock value can be therefore not stored in the pre-allocated stack area and additional stack space is required. To correctly annotate these situations with CFI, the .cfi_val_offset directive is required to create relative offsets on the value of the stack register %r15. Because the .cfi_val_offset directive is available with recent GNU assembler versions only, additional checks are necessary. Note that if the vDSO is assembled with an older assembler version, stack unwinding and debugging from within the vDSO code might not be possible. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-20 18:46:13 +08:00
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables $(cfi)
KBUILD_AFLAGS += $(aflags-y) $(cfi)
s390/decompressor: correct build flags The decompressor requires its own set of cc and asm flags, to avoid building with features which do not make sense at such an early boot stage (e.g. expoline, ftrace). Currently cc flags are already set for the decompressor, but "cflags-y" is not exported and hence empty. To fix that and to add asm flags, define and export KBUILD_AFLAGS_DECOMPRESSOR and KBUILD_CFLAGS_DECOMPRESSOR and rely on them in the decompressor's Makefile. 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-06-15 18:28:05 +08:00
export KBUILD_AFLAGS_DECOMPRESSOR
export KBUILD_CFLAGS_DECOMPRESSOR
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
OBJCOPYFLAGS := -O binary
s390/boot: make head.S and als.c be part of the decompressor only Since uncompressed kernel image does not have to be bootable anymore, move head.S, head_kdump.S and als.c to boot/ folder and compile them in just in the decompressor. 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-06-12 21:11:40 +08:00
head-y := arch/s390/kernel/head64.o
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
[S390] standardize Kbuild rules Introducing this Kbuild file allow us to: make arch/s390/ And thus building all the core part of s390. Same as on other architectures. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-10-25 22:10:09 +08:00
# See arch/s390/Kbuild for content of core part of the kernel
core-y += arch/s390/
[S390] s390: hibernation support for s390 This patch introduces the hibernation backend support to the s390 architecture. Now it is possible to suspend a mainframe Linux guest using the following command: echo disk > /sys/power/state Signed-off-by: Hans-Joachim Picht <hans@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2009-06-16 16:30:52 +08:00
[S390] Replace $(ARCH) macros in Makefile Since $(ARCH) is always "s390" we can replace it with "s390". Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-02-21 17:55:46 +08:00
libs-y += arch/s390/lib/
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
drivers-y += drivers/s390/
# must be linked after kernel
drivers-$(CONFIG_OPROFILE) += arch/s390/oprofile/
[S390] Replace $(ARCH) macros in Makefile Since $(ARCH) is always "s390" we can replace it with "s390". Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2007-02-21 17:55:46 +08:00
boot := arch/s390/boot
s390/syscalls: add Makefile to generate system call header files Generate the system call specific files from the archheaders and archprepare make targets. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-12-11 21:54:08 +08:00
syscalls := arch/s390/kernel/syscalls
s390/facilities: add helper tool to generate facility lists Modifying the architecture level set facility lists was always very error prone. Given the numbering of the facility bits within the Principles of Operation, where the most significant bit number is 0, it happened a lot of times that wrong bits were set or cleared. Therefore this patch adds a tool "gen_facilities" which generates include/generated/facilites.h. The definition of the bits to be set is contained within arch/s390/include/asm/facilities_src.h and can be easily extended to e.g. also generate such lists for the KVM module. The generated file looks like this: #define FACILITIES_ALS _AC(0xc1006450f0040000,UL) #define FACILITIES_ALS_DWORDS 1 The facility bits defined in this patch match 1:1 to the current masks that can be found in head.S. That is if the tool gets executed with -march=z990 then the generated masks will equal the masks in head.S for CONFIG_MARCH_Z990. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-02 14:08:44 +08:00
tools := arch/s390/tools
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
s390: remove uncompressed kernel image build Dropping support for uncompressed kernel "image" build. Having both image and bzImage makes it complicated to add new code to an early boot phase (which is part of vmlinux for uncompressed kernel and a separate arch/s390/boot/compressed/vmlinux for bzImage). e.g. sclp_early_core.o is used for both, the decompressor phase and the main kernel. The fact of having uncompressed kernel "image" forces us to have a single object file and sacrifice instrumentation flags on such files (so that we could use them early). The story gets much more complicated with the need to utilize some of the string functions. With bzImage only support, we have 2 separate boot stages each built and linked separately, which allows to reuse some shared code, but recompile with appropriate flags. 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-06-11 20:35:01 +08:00
all: bzImage
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
s390: set bzImage as default image for packaging Even though s390 compressed kernel support has been introduced long ago, by default uncompressed kernel image is used by packaging targets like: "make rpm-pkg", "make deb-pkg" as well as "make image_name". At the same time "make install" would use compressed bzImage by default. To avoid ambiguity, set bzImage as default image for packaging. 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-02-20 18:31:34 +08:00
#KBUILD_IMAGE is necessary for packaging targets like rpm-pkg, deb-pkg...
KBUILD_IMAGE := $(boot)/bzImage
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
install: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $@
s390: remove uncompressed kernel image build Dropping support for uncompressed kernel "image" build. Having both image and bzImage makes it complicated to add new code to an early boot phase (which is part of vmlinux for uncompressed kernel and a separate arch/s390/boot/compressed/vmlinux for bzImage). e.g. sclp_early_core.o is used for both, the decompressor phase and the main kernel. The fact of having uncompressed kernel "image" forces us to have a single object file and sacrifice instrumentation flags on such files (so that we could use them early). The story gets much more complicated with the need to utilize some of the string functions. With bzImage only support, we have 2 separate boot stages each built and linked separately, which allows to reuse some shared code, but recompile with appropriate flags. 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-06-11 20:35:01 +08:00
bzImage: vmlinux
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
[S390] zfcpdump support. s390 machines provide hardware support for creating Linux dumps on SCSI disks. For creating a dump a special purpose dump Linux is used. The first 32 MB of memory are saved by the hardware before the dump Linux is booted. Via an SCLP interface, the saved memory can be accessed from Linux. This patch exports memory and registers of the crashed Linux to userspace via a debugfs file. For more information refer to Documentation/s390/zfcpdump.txt, which is included in this patch. Signed-off-by: Michael Holzheu <holzheu@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2007-04-27 22:01:49 +08:00
zfcpdump:
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
[S390] vdso: add missing vdso_install target Add missing vdso_install target to install the unstripped vdso images into $(MODLIB)/vdso/. These files are helpful when containing additional debugging information. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2010-05-17 16:00:09 +08:00
vdso_install:
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso64 $@
$(Q)$(MAKE) $(build)=arch/$(ARCH)/kernel/vdso32 $@
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
s390/facilities: add helper tool to generate facility lists Modifying the architecture level set facility lists was always very error prone. Given the numbering of the facility bits within the Principles of Operation, where the most significant bit number is 0, it happened a lot of times that wrong bits were set or cleared. Therefore this patch adds a tool "gen_facilities" which generates include/generated/facilites.h. The definition of the bits to be set is contained within arch/s390/include/asm/facilities_src.h and can be easily extended to e.g. also generate such lists for the KVM module. The generated file looks like this: #define FACILITIES_ALS _AC(0xc1006450f0040000,UL) #define FACILITIES_ALS_DWORDS 1 The facility bits defined in this patch match 1:1 to the current masks that can be found in head.S. That is if the tool gets executed with -march=z990 then the generated masks will equal the masks in head.S for CONFIG_MARCH_Z990. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-02 14:08:44 +08:00
$(Q)$(MAKE) $(clean)=$(tools)
s390/syscalls: add Makefile to generate system call header files Generate the system call specific files from the archheaders and archprepare make targets. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-12-11 21:54:08 +08:00
archheaders:
$(Q)$(MAKE) $(build)=$(syscalls) uapi
s390/facilities: add helper tool to generate facility lists Modifying the architecture level set facility lists was always very error prone. Given the numbering of the facility bits within the Principles of Operation, where the most significant bit number is 0, it happened a lot of times that wrong bits were set or cleared. Therefore this patch adds a tool "gen_facilities" which generates include/generated/facilites.h. The definition of the bits to be set is contained within arch/s390/include/asm/facilities_src.h and can be easily extended to e.g. also generate such lists for the KVM module. The generated file looks like this: #define FACILITIES_ALS _AC(0xc1006450f0040000,UL) #define FACILITIES_ALS_DWORDS 1 The facility bits defined in this patch match 1:1 to the current masks that can be found in head.S. That is if the tool gets executed with -march=z990 then the generated masks will equal the masks in head.S for CONFIG_MARCH_Z990. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-02 14:08:44 +08:00
archprepare:
s390/syscalls: add Makefile to generate system call header files Generate the system call specific files from the archheaders and archprepare make targets. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-12-11 21:54:08 +08:00
$(Q)$(MAKE) $(build)=$(syscalls) kapi
s390/tools: generate header files in arch/s390/include/generated/ Previously, the generated dis.h and facilities.h header files have been stored in include/generated. Because they are s390 specific, store them in the arch/s390/include/generated/asm/ directory. Also update references to the header files respectively. To prevent name collisions with those header files in asm/ that include the generated ones, rename the generated headers files and add an -defs suffix. Also update the generators to create the ifdef guards respectively. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-01-11 19:13:18 +08:00
$(Q)$(MAKE) $(build)=$(tools) kapi
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
# Don't use tabs in echo arguments
define archhelp
s390: remove uncompressed kernel image build Dropping support for uncompressed kernel "image" build. Having both image and bzImage makes it complicated to add new code to an early boot phase (which is part of vmlinux for uncompressed kernel and a separate arch/s390/boot/compressed/vmlinux for bzImage). e.g. sclp_early_core.o is used for both, the decompressor phase and the main kernel. The fact of having uncompressed kernel "image" forces us to have a single object file and sacrifice instrumentation flags on such files (so that we could use them early). The story gets much more complicated with the need to utilize some of the string functions. With bzImage only support, we have 2 separate boot stages each built and linked separately, which allows to reuse some shared code, but recompile with appropriate flags. 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-06-11 20:35:01 +08:00
echo '* bzImage - Kernel image for IPL ($(boot)/bzImage)'
s390: add 'install' target to 'make help' Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-11-25 18:54:36 +08:00
echo ' install - Install kernel using'
echo ' (your) ~/bin/$(INSTALLKERNEL) or'
echo ' (distribution) /sbin/$(INSTALLKERNEL) or'
echo ' install to $$(INSTALL_PATH)'
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 06:20:36 +08:00
endef
Copy Permalink