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.
|
|
|
|
|
##
|
|
|
|
|
|
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
|
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), \
|
2014-05-17 18:38:10 +02:00
|
|
|
$(eval CC_$(arch):=CCC_CC="$(CC_$(arch))" $(CC) ))
|
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
|
|
|
|
2015-03-28 16:27:42 +01:00
|
|
|
ARCHDIR-i386 := x86
|
|
|
|
|
ARCHDIR-x86_32 := x86
|
2016-01-11 18:30:24 +01:00
|
|
|
ARCHDIR-x86_64 := x86
|
2015-03-28 16:27:42 +01:00
|
|
|
ARCHDIR-arm := arm
|
|
|
|
|
ARCHDIR-arm64 := arm64
|
|
|
|
|
ARCHDIR-riscv := riscv
|
|
|
|
|
ARCHDIR-mips := mips
|
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
|
|
|
|
2016-01-11 18:30:24 +01:00
|
|
|
CFLAGS_arm +=
|
|
|
|
|
CFLAGS_arm64 += -mgeneral-regs-only
|
2015-07-31 22:50:03 +02:00
|
|
|
CFLAGS_mips += -mips32r2 -G 0 -mno-abicalls -fno-pic
|
|
|
|
|
CFLAGS_riscv +=
|
|
|
|
|
CFLAGS_x86_32 +=
|
2016-01-11 18:30:24 +01:00
|
|
|
CFLAGS_x86_64 += -mcmodel=large -mno-red-zone
|
2018-11-30 00:06:50 +01:00
|
|
|
CFLAGS_ppc64 +=
|
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.
|
|
|
|
|
#
|
|
|
|
|
# Store larger buffers in BSS, use MAYBE_STATIC to share code with __PRE_RAM__
|
|
|
|
|
# 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.)
|
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_mips += -Wstack-usage=1536
|
|
|
|
|
CFLAGS_riscv += -Wstack-usage=1536
|
2018-11-30 00:06:50 +01:00
|
|
|
CFLAGS_ppc64 += -Wstack-usage=1536
|
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),\
|
2014-05-17 15:08:47 +02:00
|
|
|
$(eval CPPFLAGS_$(arch) += \
|
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
|
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= \
|
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
|
|
|
|
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
|
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))
|
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))
|
2014-06-20 04:01:34 +02:00
|
|
|
AR_$(1) := $(AR_$(2))
|
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))
|
2014-11-06 23:50:22 +01:00
|
|
|
CFLAGS_$(1) = $$(CFLAGS_common) $$(CFLAGS_$(2))
|
2019-06-18 16:38:29 +02:00
|
|
|
ADAFLAGS_$(1) = --RTS=$$(obj)/libgnat-$(2)/ $$(ADAFLAGS_common) $$(GCC_ADAFLAGS_$(2))
|
2015-11-13 22:28:41 +01:00
|
|
|
CPPFLAGS_$(1) = $$(CPPFLAGS_common) $$(CPPFLAGS_$(2)) -D__ARCH_$(2)__
|
2015-06-04 13:31:38 +02:00
|
|
|
COMPILER_RT_$(1) := $$(COMPILER_RT_$(2))
|
|
|
|
|
COMPILER_RT_FLAGS_$(1) := $$(COMPILER_RT_FLAGS_$(2))
|
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
|
|
|
|
|
|
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 = \
|
2014-05-17 14:02:08 +02:00
|
|
|
$(eval $(call set_stage_toolchain,$(1))) \
|
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 = \
|
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)
|
2015-03-26 21:39:12 +01:00
|
|
|
|
2015-12-07 22:04:27 +01:00
|
|
|
# Test for coreboot toolchain (except when explicitly not requested)
|
2015-03-26 21:39:12 +01:00
|
|
|
ifneq ($(NOCOMPILE),1)
|
2016-01-15 22:56:06 +01:00
|
|
|
# Only run if we're doing a build (not for tests, kconfig, ...)
|
2015-03-26 21:39:12 +01:00
|
|
|
# rationale: gcc versions by Linux distributions tend to be quite messed up
|
2015-12-07 22:07:10 +01:00
|
|
|
# llvm/clang also needs patches supplied by the coreboot build
|
2015-03-26 21:39:12 +01:00
|
|
|
COMPILERFAIL:=0
|
2015-11-27 06:34:42 +01:00
|
|
|
IASLFAIL:=0
|
2015-12-07 22:07:10 +01:00
|
|
|
|
2015-03-26 21:39:12 +01:00
|
|
|
ifneq ($(CONFIG_ANY_TOOLCHAIN),y)
|
2016-01-15 22:56:06 +01:00
|
|
|
# Verify that the coreboot toolchain is being used.
|
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.)))
|
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.
|
2016-01-11 18:30:24 +01:00
|
|
|
$(if $(shell if [ -n "$(IASL)" ]; then \
|
2016-01-06 00:14:12 +01:00
|
|
|
$(IASL) -v 2>&1 | grep -q "coreboot toolchain" || \
|
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))
|
2015-12-07 22:33:44 +01:00
|
|
|
else #$(CONFIG_ANY_TOOLCHAIN)
|
2016-01-15 22:56:06 +01:00
|
|
|
# If the coreboot toolchain isn't being used, verify that there is A toolchain
|
2016-01-11 18:30:24 +01:00
|
|
|
$(foreach arch,$(sort \
|
|
|
|
|
$(foreach stage,$(COREBOOT_STANDARD_STAGES),$(ARCH-$(stage)-y))), \
|
2015-12-07 22:33:44 +01:00
|
|
|
$(if $(CC_$(arch)),, $(eval COMPILERFAIL:=1) \
|
2016-01-11 18:30:24 +01:00
|
|
|
$(warning No compiler found for '$(arch)' architecture. \
|
|
|
|
|
Install one or use the coreboot toolchain?)) )
|
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.
|
2015-12-07 22:33:44 +01:00
|
|
|
$(if $(IASL),, $(eval COMPILERFAIL:=1)$(eval IASLFAIL:=1) \
|
2016-01-11 18:30:24 +01:00
|
|
|
$(warning iasl not found. \
|
|
|
|
|
Please install it or use the coreboot toolchain.))
|
2015-03-26 21:39:12 +01:00
|
|
|
endif
|
2016-01-15 22:56:06 +01:00
|
|
|
|
|
|
|
|
# If the compiler check failed, print out warnings
|
2015-03-26 21:39:12 +01:00
|
|
|
ifeq ($(COMPILERFAIL),1)
|
2015-12-07 22:13:40 +01:00
|
|
|
ifneq ($(XGCCPATH),)
|
|
|
|
|
$(warning )
|
|
|
|
|
$(warning Path to your toolchain is currently set to '$(XGCCPATH)')
|
|
|
|
|
endif
|
2015-11-25 20:44:15 +01:00
|
|
|
$(warning )
|
2015-12-07 22:27:34 +01:00
|
|
|
$(warning To build the entire coreboot toolchain: run 'make crossgcc')
|
2015-11-27 06:34:42 +01:00
|
|
|
ifeq ($(IASLFAIL),1)
|
2015-12-07 22:27:34 +01:00
|
|
|
$(warning To build just IASL: run 'make iasl')
|
2015-12-07 22:20:55 +01:00
|
|
|
endif #($(IASLFAIL),1)
|
2015-12-07 22:27:34 +01:00
|
|
|
$(warning For more toolchain build targets: run 'make help_toolchain')
|
2015-11-25 20:44:15 +01:00
|
|
|
$(warning )
|
2015-12-07 22:24:57 +01:00
|
|
|
ifneq ($(CONFIG_ANY_TOOLCHAIN),y)
|
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.)
|
2015-12-07 22:24:57 +01:00
|
|
|
$(warning )
|
|
|
|
|
endif #($(CONFIG_ANY_TOOLCHAIN),y)
|
|
|
|
|
$(error Halting the build)
|
2015-12-07 22:20:55 +01:00
|
|
|
endif #($(COMPILERFAIL),1)
|
|
|
|
|
|
|
|
|
|
endif #($(NOCOMPILE),1)
|
2016-01-06 00:07:42 +01:00
|
|
|
|
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
|
2016-01-06 00:07:42 +01:00
|
|
|
ifneq ($(MAKECMDGOALS),)
|
|
|
|
|
ifneq ($(filter test-toolchain,$(MAKECMDGOALS)),)
|
|
|
|
|
$(foreach arch, $(ARCH_SUPPORTED), \
|
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.)) \
|
2016-01-06 00:07:42 +01:00
|
|
|
)
|
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))
|
2016-01-15 22:56:06 +01:00
|
|
|
endif #($(filter crossgcc_check%,$(MAKECMDGOALS)),)
|
|
|
|
|
endif #($(MAKECMDGOALS),)
|