GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/toolchain.inc

266 lines
9.7 KiB
PHP
Raw Normal View History

Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
##
## This file is part of the coreboot project.
##
## Copyright (C) 2014 Google Inc
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; version 2 of the License.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
build: re-enable ccache support The ccache support was mostly disabled because it didn't hook onto most compilers anymore. Caveat: ccache and scan-build don't work together since scan-build doesn't like arguments in its compiler command line (eg. "ccache gcc"). Change-Id: I7c1c6e22cb662f2b08e774ea484ac1c412fdd2db Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5775 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 18:38:10 +02:00
# ccache integration
ifeq ($(CONFIG_CCACHE),y)
CCACHE:=$(word 1,$(wildcard $(addsuffix /ccache,$(subst :, ,$(PATH)))))
ifeq ($(CCACHE),)
$(error ccache selected, but not found in PATH)
endif
export CCACHE_COMPILERCHECK=content
export CCACHE_BASEDIR=$(top)
$(foreach arch,$(ARCH_SUPPORTED), \
$(eval CC_$(arch):=$(CCACHE) $(CC_$(arch))))
HOSTCC:=$(CCACHE) $(HOSTCC)
HOSTCXX:=$(CCACHE) $(HOSTCXX)
ROMCC=$(CCACHE) $(ROMCC_BIN)
endif
build: make scan-build work again This drops the scan-build related Kconfig options since it's now possible to simply run scan-build [-o outdir] make and get coreboot built with its report. There's also no inner make process anymore, and the way things work should be clearer now. Also adapt abuild to this new reality. Change-Id: I03e03334761ec83f718b3235ebf811834cd2e3e3 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5774 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 18:26:38 +02:00
# scan-build integration
ifneq ($(CCC_ANALYZER_OUTPUT_FORMAT),)
ifeq ($(CCC_ANALYZER_ANALYSIS),)
export CCC_ANALYZER_ANALYSIS := -analyzer-opt-analyze-headers
endif
$(foreach arch,$(ARCH_SUPPORTED), \
build: re-enable ccache support The ccache support was mostly disabled because it didn't hook onto most compilers anymore. Caveat: ccache and scan-build don't work together since scan-build doesn't like arguments in its compiler command line (eg. "ccache gcc"). Change-Id: I7c1c6e22cb662f2b08e774ea484ac1c412fdd2db Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5775 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 18:38:10 +02:00
$(eval CC_$(arch):=CCC_CC="$(CC_$(arch))" $(CC) ))
build: make scan-build work again This drops the scan-build related Kconfig options since it's now possible to simply run scan-build [-o outdir] make and get coreboot built with its report. There's also no inner make process anymore, and the way things work should be clearer now. Also adapt abuild to this new reality. Change-Id: I03e03334761ec83f718b3235ebf811834cd2e3e3 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5774 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 18:26:38 +02:00
HOSTCC:=CCC_CC="$(HOSTCC)" $(CC)
HOSTCXX:=CCC_CXX="$(HOSTCXX)" $(CXX)
ROMCC=CCC_CC="$(ROMCC_BIN)" $(CC)
endif
Introduce bootblock self-decompression Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16 23:14:04 +02:00
COREBOOT_STANDARD_STAGES := decompressor bootblock verstage romstage ramstage
MAP-decompressor := bootblock
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
mips: mips, not mipsel Change-Id: I49df089d3fd5f578702dcc32be08bf6245277a45 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9149 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-03-28 16:27:42 +01:00
ARCHDIR-i386 := x86
ARCHDIR-x86_32 := x86
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
ARCHDIR-x86_64 := x86
mips: mips, not mipsel Change-Id: I49df089d3fd5f578702dcc32be08bf6245277a45 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9149 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-03-28 16:27:42 +01:00
ARCHDIR-arm := arm
ARCHDIR-arm64 := arm64
ARCHDIR-riscv := riscv
arch/power8: Rename to ppc64 POWER8 is a specific implementation of ppc64, which is by now outdated (POWER9 has been on the market for a while). Rename arch/power8/ to potentially cover a wider range of hardware. TEST=Toolchains built before/after this commit can build coreboot for emulation/qemu-power8 from before/after this commit. Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/29943 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
2018-11-30 00:06:50 +01:00
ARCHDIR-ppc64 := ppc64
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
CFLAGS_arm +=
CFLAGS_arm64 += -mgeneral-regs-only
Move function/data sections to common CFLAGS Instead of adding -ffunction-sections and -fdata-sections to every architecture, just add it to CFLAGS_common, thus making sure that new architectures will pick it up automatically. Change-Id: I38e878851226565b7791d05e222cb4e502e0c8a3 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11105 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-31 22:50:03 +02:00
CFLAGS_riscv +=
CFLAGS_x86_32 +=
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
CFLAGS_x86_64 += -mcmodel=large -mno-red-zone
arch/power8: Rename to ppc64 POWER8 is a specific implementation of ppc64, which is by now outdated (POWER9 has been on the market for a while). Rename arch/power8/ to potentially cover a wider range of hardware. TEST=Toolchains built before/after this commit can build coreboot for emulation/qemu-power8 from before/after this commit. Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/29943 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
2018-11-30 00:06:50 +01:00
CFLAGS_ppc64 +=
toolchain.inc: Add x86-64 support For now, share code with x86, and use the "large" code model. Also align the architecture specific CFLAGS in toolchain.inc for cosmetics. Change-Id: Ie84893d3460115802fbd70c28b10e709029c6b4e Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:19:58 +01:00
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-20 01:11:14 +01:00
# Some boards only provide 2K stacks, so storing lots of data there leads to
# problems. Since C rules don't allow us to statically determine the maximum
# stack use, we use 1.5K as heuristic, assuming that we typically have lots
# of tiny stack frames and the odd large one.
#
Split MAYBE_STATIC to _BSS and _NONZERO variants These are required to cover the absensce of .data and .bss sections in some programs, most notably ARCH_X86 in execute-in-place with cache-as-ram. Change-Id: I80485ebac94b88c5864a949b17ad1dccdfda6a40 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35003 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-08-20 05:01:57 +02:00
# Store larger buffers in BSS, use MAYBE_STATIC_BSS to share code with __PRE_RAM__
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-20 01:11:14 +01:00
# on x86.
# Since GCCs detection of dynamic array bounds unfortunately seems to be
# very basic, you'll sometimes have to use a static upper bound for the
# size and an assert() to make sure it's honored (see gpio_base3_value()
# for an example).
# (If you absolutely need a larger stack frame and are 100% sure it cannot
# cause problems, you can whitelist it with #pragma diagnostic.)
toolchain.inc: Use -Wstack-usage only on gcc clang isn't happy with it Change-Id: I2c22171dedc77df24e739ec26335010f0f443963 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/19657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-05-10 22:02:55 +02:00
ifeq ($(CONFIG_COMPILER_GCC),y)
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-20 01:11:14 +01:00
CFLAGS_arm += -Wstack-usage=1536
CFLAGS_arm64 += -Wstack-usage=1536
CFLAGS_riscv += -Wstack-usage=1536
arch/power8: Rename to ppc64 POWER8 is a specific implementation of ppc64, which is by now outdated (POWER9 has been on the market for a while). Rename arch/power8/ to potentially cover a wider range of hardware. TEST=Toolchains built before/after this commit can build coreboot for emulation/qemu-power8 from before/after this commit. Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/29943 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
2018-11-30 00:06:50 +01:00
CFLAGS_ppc64 += -Wstack-usage=1536
toolchain.inc: Use -Wstack-usage only on gcc clang isn't happy with it Change-Id: I2c22171dedc77df24e739ec26335010f0f443963 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/19657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-05-10 22:02:55 +02:00
endif
arm, arm64, mips: Add rough static stack size checks with -Wstack-usage We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-12-20 01:11:14 +01:00
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
toolchain_to_dir = \
$(foreach arch,$(ARCH_SUPPORTED),\
build: break compiler flags out of $(CC) Having more than the executable in $(CC) only leads to trouble in a number of situations. Change-Id: I7642ca4068b3a3bd5798219d74de9e0eb85bb4e5 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5769 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 15:08:47 +02:00
$(eval CPPFLAGS_$(arch) += \
build: kill one indirection No need to first define X86_32 and then replace every single use of it with its lower cased equivalent. Just start out with the lower case versions in the first place. Change-Id: I1e771ef443db1b8d34018d19a64a9ee489cd8133 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5767 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 14:02:08 +02:00
-Isrc/arch/$(ARCHDIR-$(arch))/include))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
# set_stage_toolchain: Decides the toolchain to be used by every stage
# E.g.: If bootblock is x86_32, it sets ARCH-BOOTBLOCK-y = x86_32, whereas
# ARCH-BOOTBLOCK-n = armv7. Then, ARCH-BOOTBLOCK-y can be used anywhere to
# decide the compiler toolchain for bootblock stage
# This step is essential for initializing the toolchain for coreboot standard
# stages i.e. bootblock, romstage and ramstage, since it acts as the second
# parameter to create_class_compiler below in init_standard_toolchain
vboot: split class in library and stage The build system includes a bunch of files into verstage that also exist in romstage - generic drivers etc. These create link time conflicts when trying to link both the verstage copy and romstage copy together in a combined configuration, so separate "stage" parts (that allow things to run) from "library" parts (that contain the vboot specifics). Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10041 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-30 14:25:14 +02:00
map_stage = $(strip $(if $(MAP-$(1)),$(MAP-$(1)),$(1)))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
set_stage_toolchain= \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(foreach arch,$(ARCH_SUPPORTED), \
$(eval ARCH-$(1)-$($(shell \
echo CONFIG_ARCH_$(call map_stage,$(1))_$(arch) | \
tr '[:lower:]' '[:upper:]')) := $(arch)))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
Add minimal GNAT run time system (RTS) Add a stripped-down version of libgnat. This is somehow comparable to libgcc but for Ada programs. It's licensed under GPLv3 but with the runtime library exception. So it's totally fine to link it with our GPLv2 code and keep it under GPLv2. Change-Id: Ie6522abf093f0a516b9ae18ddc69131bd721dc0c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/11836 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-09-29 16:41:19 +02:00
# standard-archs: Tell which architectures are used by the standard stages.
standard-archs = $(sort $(foreach stagearch, \
$(patsubst %,ARCH-%-y,$(COREBOOT_STANDARD_STAGES)), \
$($(stagearch))))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
# create_class_compiler: Used to create compiler tool set for
# special classes
# @1: special class
# @2: compiler set to be used
# e.g.: smm special class uses i386 as compiler set
define create_class_compiler
toolchain.inc: Update 'required toolchain' error text The old text said: *** building <STAGE> without the required toolchain. Stop. Where <STAGE> could be any of the coreboot stages - bootblock, verstage, ramstage, romstage. This error message was very misleading though, because what it actually meant was that it didn't know what architecture was required to build the stage, not that the toolchain was missing. Update the text to better reflect the actual issue, and to give the user a hint as to what to look for: *** The toolchain architecture for <STAGE> is unknown. *** Check your .config file for CONFIG_ARCH_<STAGE>_* settings. Stop. Change-Id: Ic2a4f60c1f25e0f5e1ebde76781bcb8da0987d82 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16024 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker
2016-08-02 03:57:02 +02:00
$(if $(2),,$(warning *** The toolchain architecture for $(1) is unknown.) \
$(error Check your .config file for CONFIG_ARCH_$(1)_* settings))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
CC_$(1) := $(CC_$(2))
toolchain: Always use GCC for Ada sources We can't use $(CC) in case it's set to Clang. TEST=Built one target with Ada sources before and after this change and verified that the same compiler commands are emitted. Change-Id: I9b8ea35352d74b364f09fc12d8d981ca42f8b7c8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21366 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-09-03 23:42:58 +02:00
GCC_$(1) := $(GCC_CC_$(2))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
LD_$(1) := $(LD_$(2))
NM_$(1) := $(NM_$(2))
Set custom AR_ for each class TEST=Booted Nyan Blaze BUG=none BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I7e822e16117240f732ac55bb2c3816486a3e10cc Original-Reviewed-on: https://chromium-review.googlesource.com/204870 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 967455d6fed014f82198de4987ec103bb7c33d25) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I88025887fb0134f1e75028e0a4ed0c78af281c96 Reviewed-on: http://review.coreboot.org/8143 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-06-20 04:01:34 +02:00
AR_$(1) := $(AR_$(2))
Make Ada a first class citizen Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-01-14 01:13:33 +01:00
GNATBIND_$(1) := $(GNATBIND_$(2))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
OBJCOPY_$(1) := $(OBJCOPY_$(2))
OBJDUMP_$(1) := $(OBJDUMP_$(2))
STRIP_$(1) := $(STRIP_$(2))
READELF_$(1) := $(READELF_$(2))
build: Add ccopts back into the build The ccopts mechanism is needed for passing ARM assembler flags to GCC. There are many gotchas in adding ASFLAGS. As things have moved around, the revert doesn't remove cleanly, so this reverts and cleans up the ccopts. This reverts commit 25b56c3af514faa8a730d56fe14cae4960ac83aa. Change-Id: I44c025535258e6afb05a814123c10c24775a88e8 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/7352 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-06 23:50:22 +01:00
CFLAGS_$(1) = $$(CFLAGS_common) $$(CFLAGS_$(2))
Move -Wlogical-op into xcompile Clang doesn't know `-Wlogical-op`, so let's move it into xcompile where we can easily distinguish between the two. However, this requires us to split out `GCC_ADAFLAGS*` from `GCC_CFLAGS*`. Change-Id: I6a50de0bc5372f61337f237383d32645ba86b0fd Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33579 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-18 16:38:29 +02:00
ADAFLAGS_$(1) = --RTS=$$(obj)/libgnat-$(2)/ $$(ADAFLAGS_common) $$(GCC_ADAFLAGS_$(2))
rules.h: Add ENV_ macros to detect current architecture This patch expands the existing ENV_<stage> macros in <rules.h> with a set of ENV_<arch> macros which can be used to detect which architecture the current compilation unit is built for. These are more consistent than compiler-defined macros (like '#ifdef __arm__') and will make it easier to write small, architecture-dependent differences in common code (where we currently often use IS_ENABLED(CONFIG_ARCH_...), which is technically incorrect in a world where every stage can run on a different architecture, and merely kinda happened to work out for now). Also remove a vestigal <arch/rules.h> from ARM64 which was no longer used, and genericise ARM subarchitecture Makefiles a little to make things like __COREBOOT_ARM_ARCH__ available from all file types (including .ld). BUG=None TEST=Compiled Falco, Blaze, Jerry and Smaug. Change-Id: Id51aeb290b5c215c653e42a51919d0838e28621f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12433 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-11-13 22:28:41 +01:00
CPPFLAGS_$(1) = $$(CPPFLAGS_common) $$(CPPFLAGS_$(2)) -D__ARCH_$(2)__
build system: move compiler runtime determination to xcompile Instead of fetching libgcc's location and required compiler flags on every individual build, do it once in xcompile. Change-Id: Ie5832fcb21710c4cf381ba475589d42ce0235f96 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/10425 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-06-04 13:31:38 +02:00
COMPILER_RT_$(1) := $$(COMPILER_RT_$(2))
COMPILER_RT_FLAGS_$(1) := $$(COMPILER_RT_FLAGS_$(2))
linking: add and use LDFLAGS_common Add an LDFLAGS_common variable and use that for each stage during linking within all the architectures. All the architectures support gc-sections, and as such they should be linking in the same way. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage. Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11522 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-09-06 17:15:17 +02:00
LDFLAGS_$(1) = $$(LDFLAGS_common) $$(LDFLAGS_$(2))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
endef
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
# define_class: Allows defining any program as dynamic class and compiler tool
# set for the same based on the architecture for which the program is to be
# compiled
# @1: program (class name)
# @2: architecture for which the program needs to be compiled
# IMP: Ensure that define_class is called before any .c or .S files are added to
# the class of the program. Check subdirs-y for order of subdirectory inclusions
define define_class
classes-y += $(1)
$(eval $(call create_class_compiler,$(1),$(2)))
endef
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
# initialize standard toolchain (CC,AS and others) for give stage
# @1 : stage for which the toolchain is to be initialized
init_standard_toolchain = \
build: kill one indirection No need to first define X86_32 and then replace every single use of it with its lower cased equivalent. Just start out with the lower case versions in the first place. Change-Id: I1e771ef443db1b8d34018d19a64a9ee489cd8133 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5767 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 14:02:08 +02:00
$(eval $(call set_stage_toolchain,$(1))) \
build: remove call to missing function set_stage_libgcc never existed in our tree. Change-Id: I864fc683dd7b89a030daf05eafb9624ce828cb72 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5770 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 15:13:40 +02:00
$(eval $(call create_class_compiler,$(1),$(ARCH-$(1)-y)))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
init_stages = \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(foreach stage,$(COREBOOT_STANDARD_STAGES), \
$(eval $(call init_standard_toolchain,$(stage))))
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
$(eval $(call toolchain_to_dir))
$(call init_stages)
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
toolchain.inc: fix typo Change-Id: I6336881f0ec3568e14c03c55c7c060eba9f4be53 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12675 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-12-07 22:04:27 +01:00
# Test for coreboot toolchain (except when explicitly not requested)
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
ifneq ($(NOCOMPILE),1)
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# Only run if we're doing a build (not for tests, kconfig, ...)
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
# rationale: gcc versions by Linux distributions tend to be quite messed up
toolchain.inc: Test for toolchain when using llvm/clang Change-Id: I45ed5e289f9bfae90d71938243f921588b256e39 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12676 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:07:10 +01:00
# llvm/clang also needs patches supplied by the coreboot build
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
COMPILERFAIL:=0
toolchain.inc: Add IASL test as part of coreboot toolchain Even though coreboot has IASL as part of its toolchain, it was not being picked up when testing to make sure coreboot is being compiled with the coreboot toolchain. This patch adds an iasl test when testing coreboot toolchain. Change-Id: I5b989869417c3f60057a91842b911855d9528f1b Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12543 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-27 06:34:42 +01:00
IASLFAIL:=0
toolchain.inc: Test for toolchain when using llvm/clang Change-Id: I45ed5e289f9bfae90d71938243f921588b256e39 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12676 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:07:10 +01:00
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
ifneq ($(CONFIG_ANY_TOOLCHAIN),y)
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# Verify that the coreboot toolchain is being used.
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(foreach arch,$(sort $(foreach stage,\
$(COREBOOT_STANDARD_STAGES),$(ARCH-$(stage)-y))), \
$(if $(shell if [ -n "$(CC_$(arch))" ]; then \
$(CC_$(arch)) -v 2>&1 | grep -q "coreboot toolchain" || \
echo not-coreboot; else echo not-coreboot; fi), \
$(eval COMPILERFAIL:=1)\
$(warning The coreboot toolchain for '$(arch)'\
architecture was not found.)))
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# If iasl doesn't match the current coreboot version, fail the test
# TODO: Figure out if iasl is even needed for the build.
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(if $(shell if [ -n "$(IASL)" ]; then \
toolchain.inc: test IASL by version string instead of number Test that the coreboot toolchain version of IASL is being used by looking for the string 'coreboot toolchain' instead of a specific version number. While this may cause people to have to rebuild their toolchains again now, it helps to prevent toolchain failures when bisecting in the future. Change-Id: I9913eeae8f29ddc3ec8c70077c05d898595eb283 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-06 00:14:12 +01:00
$(IASL) -v 2>&1 | grep -q "coreboot toolchain" || \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
echo not-coreboot; else echo not-coreboot; fi), \
$(eval COMPILERFAIL:=1)$(eval IASLFAIL:=1)\
$(warning The coreboot toolchain version of iasl \
'$(shell util/crossgcc/buildgcc -s iasl)' was not found))
toolchain.inc: Test for valid toolchain when ANY_TOOLCHAIN is used Even when ANY_TOOLCHAIN is selected, a valid compiler for the requested architecture is needed. Change-Id: If1a0a1ca6b726e8e58d29c69de93546510582548 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12681 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:33:44 +01:00
else #$(CONFIG_ANY_TOOLCHAIN)
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# If the coreboot toolchain isn't being used, verify that there is A toolchain
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(foreach arch,$(sort \
$(foreach stage,$(COREBOOT_STANDARD_STAGES),$(ARCH-$(stage)-y))), \
toolchain.inc: Test for valid toolchain when ANY_TOOLCHAIN is used Even when ANY_TOOLCHAIN is selected, a valid compiler for the requested architecture is needed. Change-Id: If1a0a1ca6b726e8e58d29c69de93546510582548 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12681 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:33:44 +01:00
$(if $(CC_$(arch)),, $(eval COMPILERFAIL:=1) \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(warning No compiler found for '$(arch)' architecture. \
Install one or use the coreboot toolchain?)) )
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# If iasl isn't present, fail
# TODO: Figure out if iasl is even needed for the build.
toolchain.inc: Test for valid toolchain when ANY_TOOLCHAIN is used Even when ANY_TOOLCHAIN is selected, a valid compiler for the requested architecture is needed. Change-Id: If1a0a1ca6b726e8e58d29c69de93546510582548 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12681 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:33:44 +01:00
$(if $(IASL),, $(eval COMPILERFAIL:=1)$(eval IASLFAIL:=1) \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(warning iasl not found. \
Please install it or use the coreboot toolchain.))
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
endif
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# If the compiler check failed, print out warnings
build system: Test gccs that are actually used Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26 21:39:12 +01:00
ifeq ($(COMPILERFAIL),1)
toolchain.inc: print XGCCPATH if it's set To help a user debug issues, print the current XGCCPATH value if it's set. Change-Id: I69afdd1c93cfd4747547ecad0d5e1ab4c87511b7 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12677 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:13:40 +01:00
ifneq ($(XGCCPATH),)
$(warning )
$(warning Path to your toolchain is currently set to '$(XGCCPATH)')
endif
toolchain.inc: Improve help messages for coreboot toolchain Show better help text on how to compile the coreboot toolchain or use an unsupported toolchain. Change-Id: I64a2159d324d673784669b2464c1a2769b048678 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12557 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-25 20:44:15 +01:00
$(warning )
toolchain.inc: Update help text, Add TODO. - Update the help text to be more informative. - Add todo about IASL - we shouldn't require it if the build doesn't use it. Change-Id: Iffeb94f78c1ae7535a8a7b9b0b9f1728301a42b3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12680 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-07 22:27:34 +01:00
$(warning To build the entire coreboot toolchain: run 'make crossgcc')
toolchain.inc: Add IASL test as part of coreboot toolchain Even though coreboot has IASL as part of its toolchain, it was not being picked up when testing to make sure coreboot is being compiled with the coreboot toolchain. This patch adds an iasl test when testing coreboot toolchain. Change-Id: I5b989869417c3f60057a91842b911855d9528f1b Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12543 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-27 06:34:42 +01:00
ifeq ($(IASLFAIL),1)
toolchain.inc: Update help text, Add TODO. - Update the help text to be more informative. - Add todo about IASL - we shouldn't require it if the build doesn't use it. Change-Id: Iffeb94f78c1ae7535a8a7b9b0b9f1728301a42b3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12680 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-07 22:27:34 +01:00
$(warning To build just IASL: run 'make iasl')
toolchain.inc: Move nocompile around entire check, Comment endifs Move the check for NOCOMPILE flag around the whole block. There's no need to test COMPILERFAIL if NOCOMPILE is set. Comment the endif lines to make it easier to understand. Signed-off-by: Martin Roth <martinroth@google.com> Change-Id: Id7bb5ca13e6bf1cabf4b7b2ff3256b47b966bac1 Reviewed-on: https://review.coreboot.org/12678 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-12-07 22:20:55 +01:00
endif #($(IASLFAIL),1)
toolchain.inc: Update help text, Add TODO. - Update the help text to be more informative. - Add todo about IASL - we shouldn't require it if the build doesn't use it. Change-Id: Iffeb94f78c1ae7535a8a7b9b0b9f1728301a42b3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12680 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-12-07 22:27:34 +01:00
$(warning For more toolchain build targets: run 'make help_toolchain')
toolchain.inc: Improve help messages for coreboot toolchain Show better help text on how to compile the coreboot toolchain or use an unsupported toolchain. Change-Id: I64a2159d324d673784669b2464c1a2769b048678 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12557 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-25 20:44:15 +01:00
$(warning )
toolchain.inc: Skip how to use any toolchain if it's selected If ANY_TOOLCHAIN is selected, don't bother telling the user how to do what they've already done. Change-Id: I7182d18a91e832aa56638ec64fe8b3b0c38cff7a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:24:57 +01:00
ifneq ($(CONFIG_ANY_TOOLCHAIN),y)
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(warning To try to use any toolchain in your path, \
run 'make menuconfig', then select)
$(warning the config option: 'General setup', \
and 'Allow building with any toolchain')
$(warning Note that this is NOT supported. \
Using it means you're on your own.)
toolchain.inc: Skip how to use any toolchain if it's selected If ANY_TOOLCHAIN is selected, don't bother telling the user how to do what they've already done. Change-Id: I7182d18a91e832aa56638ec64fe8b3b0c38cff7a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-07 22:24:57 +01:00
$(warning )
endif #($(CONFIG_ANY_TOOLCHAIN),y)
$(error Halting the build)
toolchain.inc: Move nocompile around entire check, Comment endifs Move the check for NOCOMPILE flag around the whole block. There's no need to test COMPILERFAIL if NOCOMPILE is set. Comment the endif lines to make it easier to understand. Signed-off-by: Martin Roth <martinroth@google.com> Change-Id: Id7bb5ca13e6bf1cabf4b7b2ff3256b47b966bac1 Reviewed-on: https://review.coreboot.org/12678 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-12-07 22:20:55 +01:00
endif #($(COMPILERFAIL),1)
endif #($(NOCOMPILE),1)
Makefile: Add toolchain version check This is an initial check for the coreboot toolchain versions. It currently checks binutils, gcc, clang, and iasl. The other components are slightly more difficult to test, but should follow on shortly. If the toolchain is not the correct version, make will halt with an error. Change-Id: I41daf6c4545c01dc21231d78fd081bbcf77c4726 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12846 Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Tested-by: build bot (Jenkins)
2016-01-06 00:07:42 +01:00
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
# Run the toolchain version checks if the requested target is 'test-toolchain'
# Checks the versions of GCC, binutils, clang, and IASL
Makefile: Add toolchain version check This is an initial check for the coreboot toolchain versions. It currently checks binutils, gcc, clang, and iasl. The other components are slightly more difficult to test, but should follow on shortly. If the toolchain is not the correct version, make will halt with an error. Change-Id: I41daf6c4545c01dc21231d78fd081bbcf77c4726 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12846 Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Tested-by: build bot (Jenkins)
2016-01-06 00:07:42 +01:00
ifneq ($(MAKECMDGOALS),)
ifneq ($(filter test-toolchain,$(MAKECMDGOALS)),)
$(foreach arch, $(ARCH_SUPPORTED), \
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(if $(shell if [ -n "$(GCC_CC_$(arch))" ]; then \
$(GCC_CC_$(arch)) -v 2>&1 | \
grep -q "$(shell util/crossgcc/buildgcc -s gcc)" || \
echo not-current; fi), \
$(eval COMPILER_OUT_OF_DATE:=1) \
$(warning The coreboot toolchain version of gcc for '$(arch)' \
architecture is not the current version.)) \
$(if $(shell if [ -n "$(CLANG_CC_$(arch))" ]; then \
$(CLANG_CC_$(arch)) -v 2>&1 | \
grep -q "$(shell util/crossgcc/buildgcc -s clang)" || \
echo not-current; fi), \
$(eval COMPILER_OUT_OF_DATE:=1)\
$(warning The coreboot toolchain version of clang for \
'$(arch)' architecture is not the current version.)) \
$(if $(shell if [ "$(OBJDUMP_$(arch))" != "invalidobjdump" ]; then \
$(OBJDUMP_$(arch)) -v 2>&1 | \
grep -q "$(shell util/crossgcc/buildgcc -s binutils)" || \
echo not-current; fi), \
$(eval COMPILER_OUT_OF_DATE:=1)\
$(warning The coreboot toolchain version of binutils for \
'$(arch)' architecture is not the current version.)) \
Makefile: Add toolchain version check This is an initial check for the coreboot toolchain versions. It currently checks binutils, gcc, clang, and iasl. The other components are slightly more difficult to test, but should follow on shortly. If the toolchain is not the correct version, make will halt with an error. Change-Id: I41daf6c4545c01dc21231d78fd081bbcf77c4726 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12846 Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Tested-by: build bot (Jenkins)
2016-01-06 00:07:42 +01:00
)
toolchain.inc: Fix whitespace issues and wrap long lines Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-11 18:30:24 +01:00
$(if $(shell if [ -n "$(IASL)" ]; then $(IASL) -v 2>&1 | \
grep -q "$(shell util/crossgcc/buildgcc -s iasl)" || \
echo not-coreboot; fi), \
$(eval COMPILER_OUT_OF_DATE:=1)\
$(warning The coreboot toolchain version of iasl \
is not the current version))
toolchain.inc: Update comments This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15 22:56:06 +01:00
endif #($(filter crossgcc_check%,$(MAKECMDGOALS)),)
endif #($(MAKECMDGOALS),)