coreboot-kgpe-d16/src/arch/x86/Makefile.inc

372 lines
14 KiB
PHP
Raw Normal View History

2012-07-20 07:11:21 +02:00
################################################################################
##
## This file is part of the coreboot project.
##
2012-07-20 07:11:21 +02:00
## Copyright (C) 2012 Alexandru Gagniuc <mr.nuke.me@gmail.com>
## Copyright (C) 2009-2010 coresystems GmbH
## Copyright (C) 2009 Ronald G. Minnich
##
## 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.
##
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
Remove address from GPLv2 headers As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-03-26 15:17:45 +01:00
## Foundation, Inc.
##
################################################################################
# i386 specific tools
NVRAMTOOL:=$(objutil)/nvramtool/nvramtool
OPTION_TABLE_H:=
ifeq ($(CONFIG_HAVE_OPTION_TABLE),y)
cbfs-files-y += cmos_layout.bin
cmos_layout.bin-file = $(obj)/cmos_layout.bin
cmos_layout.bin-type = 0x01aa
$(obj)/cmos_layout.bin: $(NVRAMTOOL) $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout
@printf " OPTION $(subst $(obj)/,,$(@))\n"
$(NVRAMTOOL) -y $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout -L $@
OPTION_TABLE_H:=$(obj)/option_table.h
$(OPTION_TABLE_H): $(NVRAMTOOL) $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout
@printf " OPTION $(subst $(obj)/,,$(@))\n"
$(NVRAMTOOL) -y $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout -H $@
endif # CONFIG_HAVE_OPTION_TABLE
stripped_vgabios_id = $(call strip_quotes,$(CONFIG_VGA_BIOS_ID))
cbfs-files-$(CONFIG_VGA_BIOS) += pci$(stripped_vgabios_id).rom
pci$(stripped_vgabios_id).rom-file := $(call strip_quotes,$(CONFIG_VGA_BIOS_FILE))
pci$(stripped_vgabios_id).rom-type := optionrom
cbfs-files-$(CONFIG_INTEL_MBI) += mbi.bin
mbi.bin-file := $(call strip_quotes,$(CONFIG_MBI_FILE))
mbi.bin-type := mbi
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32)$(CONFIG_ARCH_ROMSTAGE_X86_64),y)
CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstool Some projects (like ChromeOS) put more content than described by CBFS onto their image. For top-aligned images (read: x86), this has traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the area actually managed by CBFS, as opposed to ROM_SIZE) that is used to calculate the CBFS entry start offset. On bottom-aligned boards, many define a fake (smaller) ROM_SIZE for only the CBFS part, which is not consistently done and can be an issue because ROM_SIZE is expected to be a power of two. This patch changes all non-x86 boards to describe their actual (physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a mainboard Kconfig select (which is the correct place to declare unchangeable physical properties of the board). It also changes the cbfstool create invocation to use CBFS_SIZE as the -s parameter for those architectures, which defaults to ROM_SIZE but gets overridden for special use cases like ChromeOS. This has the advantage that cbfstool has a consistent idea of where the area it is responsible for ends, which offers better bounds-checking and is needed for a subsequent fix. Also change the FMAP offset to default to right behind the (now consistently known) CBFS region for non-x86 boards, which has emerged as a de-facto standard on those architectures and allows us to reduce the amount of custom configuration. In the future, the nightmare that is ChromeOS's image build system could be redesigned to enforce this automatically, and also confirm that it doesn't overwrite any space used by CBFS (which is now consistently defined as the file size of coreboot.rom on non-x86). CQ-DEPEND=CL:231576,CL:231475 BRANCH=None BUG=chromium:422501 TEST=Built and booted on Veyron_Pinky. Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71 Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229974 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9619 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-10 22:11:50 +01:00
CBFSTOOL_PRE1_OPTS = -m x86 -s $(CONFIG_ROM_SIZE) \
-o $$(( $(CONFIG_ROM_SIZE) - $(CONFIG_CBFS_SIZE) ))
# Make sure that segment for .car.data is ignored while adding romstage.
CBFSTOOL_PRE_OPTS = -b $(shell cat $(objcbfs)/base_xip.txt) -S ".car.data"
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
endif
## Calculate the base address of CBFS for later comparisons
CBFS_BASE_ADDRESS=$(call int-add, $(call int-subtract, 0xffffffff $(CONFIG_CBFS_SIZE)) 1)
###############################################################################
# bootblock
###############################################################################
ifeq ($(CONFIG_ARCH_BOOTBLOCK_X86_32)$(CONFIG_ARCH_BOOTBLOCK_X86_64),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
# Add the assembly file that pulls in the rest of the dependencies in
# the right order. Make sure the auto generated bootblock.inc is a proper
# dependency. Make the same true for the linker sript.
bootblock-y += bootblock.S
$(obj)/arch/x86/bootblock.bootblock.o: $(objgenerated)/bootblock.inc
bootblock-y += bootblock.ld
$(obj)/arch/x86/bootblock.bootblock.ld: $(objgenerated)/bootblock.ld
bootblock_romccflags := -mcpu=i386 -O2 -D__PRE_RAM__ -D__BOOTBLOCK__
ifeq ($(CONFIG_SSE),y)
bootblock_romccflags := -mcpu=k7 -msse -O2 -D__PRE_RAM__ -D__BOOTBLOCK__
endif
# This is a hack in case there are no per chipset linker files.
$(objgenerated)/empty:
touch $@
$(objgenerated)/bootblock.ld: $$(filter-out $(obj)/arch/x86/bootblock.bootblock.ld, $$(filter %.ld,$$(bootblock-objs))) $(objgenerated)/empty
@printf " GEN $(subst $(obj)/,,$(@))\n"
cat $^ >> $@.tmp
mv $@.tmp $@
$(objgenerated)/bootblock.inc: $(src)/arch/x86/$(subst ",,$(CONFIG_BOOTBLOCK_SOURCE)) $(objutil)/romcc/romcc $(OPTION_TABLE_H) $(KCONFIG_AUTOHEADER)
@printf " ROMCC $(subst $(obj)/,,$(@))\n"
$(CC_bootblock) $(CPPFLAGS_bootblock) -MM -MT$(objgenerated)/bootblock.inc \
$< > $(objgenerated)/bootblock.inc.d
$(ROMCC) -c -S $(bootblock_romccflags) -I. $(CPPFLAGS_bootblock) $< -o $@
$(objcbfs)/bootblock.debug: $(obj)/arch/x86/bootblock.bootblock.o $(obj)/arch/x86/bootblock.bootblock.ld
@printf " LINK $(subst $(obj)/,,$(@))\n"
ifeq ($(CONFIG_ARCH_BOOTBLOCK_X86_32),y)
$(LD_bootblock) -m elf_i386 --oformat elf32-i386 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
else
$(LD_bootblock) -m elf_x86_64 --oformat elf64-x86-64 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
endif
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
endif # CONFIG_ARCH_BOOTBLOCK_X86_32 / CONFIG_ARCH_BOOTBLOCK_X86_64
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
###############################################################################
# romstage
###############################################################################
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32)$(CONFIG_ARCH_ROMSTAGE_X86_64),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
crt0s = $(src)/arch/x86/prologue.inc
romstage-srcs += $(src)/arch/x86/romstage.ld
crt0s += $(src)/cpu/x86/32bit/entry32.inc
romstage-srcs += $(src)/cpu/x86/32bit/entry32.ld
crt0s += $(src)/cpu/x86/fpu_enable.inc
ifeq ($(CONFIG_SSE),y)
crt0s += $(src)/cpu/x86/sse_enable.inc
endif
crt0s += $(cpu_incs-y)
ifneq ($(CONFIG_ROMCC),y)
romstage-srcs += $(src)/mainboard/$(MAINBOARDDIR)/romstage.c
else # CONFIG_ROMCC == y
# This order matters. The mainboards requiring ROMCC need their mainboard
# code to follow the prior crt0s files for program flow control. The
# romstage.inc from the MAINBOARDDIR is implicitly main() for romstage
# because of the instruction sequen fall-through.
crt0s += $(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc
crt0s += $(src)/arch/x86/crt0_romcc_epilogue.inc
ifeq ($(CONFIG_MMX),y)
ifeq ($(CONFIG_SSE),y)
ROMCCFLAGS := -mcpu=p4 -O2 # MMX, SSE
else
ROMCCFLAGS := -mcpu=p2 -O2 # MMX, !SSE
endif
else
ROMCCFLAGS := -mcpu=i386 -O2 # !MMX, !SSE
endif
$(objcbfs)/romstage%.bin: $(objcbfs)/romstage%.elf
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
@printf " OBJCOPY $(subst $(obj)/,,$(@))\n"
$(OBJCOPY_romstage) -O binary $< $@
$(objcbfs)/romstage%.elf: $(objcbfs)/romstage%.debug
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
@printf " OBJCOPY $(subst $(obj)/,,$(@))\n"
cp $< $@.tmp
$(OBJCOPY_romstage) --strip-debug $@.tmp
$(OBJCOPY_romstage) --add-gnu-debuglink=$< $@.tmp
mv $@.tmp $@
$(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc: $(src)/mainboard/$(MAINBOARDDIR)/romstage.c $(objutil)/romcc/romcc $(OPTION_TABLE_H) $(obj)/build.h $(obj)/config.h
printf " ROMCC romstage.inc\n"
$(ROMCC) -c -S $(ROMCCFLAGS) -D__ROMSTAGE__ -D__PRE_RAM__ -I. $(CPPFLAGS_romstage) $< -o $@
endif
romstage-srcs += $(objgenerated)/crt0.S
romstage-libs ?=
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32),y)
romstage-oformat=elf32-i386
else
romstage-oformat=elf64-x86-64
endif
$(objcbfs)/romstage_null.debug: $$(romstage-objs) $(objgenerated)/romstage_null.ld $$(romstage-libs)
@printf " LINK $(subst $(obj)/,,$(@))\n"
$(LD_romstage) --gc-sections -nostdlib -nostartfiles -static -o $@ -L$(obj) $(COMPILER_RT_FLAGS_romstage) --whole-archive --start-group $(filter-out %.ld,$(romstage-objs)) $(romstage-libs) --no-whole-archive $(COMPILER_RT_romstage) --end-group -T $(objgenerated)/romstage_null.ld --oformat $(romstage-oformat)
LANG=C LC_ALL= $(OBJCOPY_romstage) --only-section .illegal_globals $(@) $(objcbfs)/romstage_null.offenders 2>&1 | \
grep -v "Empty loadable segment detected" && \
$(NM_romstage) $(objcbfs)/romstage_null.offenders | grep -q ""; if [ $$? -eq 0 ]; then \
echo "Forbidden global variables in romstage:"; \
$(NM_romstage) $(objcbfs)/romstage_null.offenders; false; \
else true; fi
$(objcbfs)/romstage.debug: $$(romstage-objs) $(objgenerated)/romstage.ld $$(romstage-libs)
@printf " LINK $(subst $(obj)/,,$(@))\n"
$(LD_romstage) --gc-sections -nostdlib -nostartfiles -static -o $@ -L$(obj) $(COMPILER_RT_FLAGS_romstage) --whole-archive --start-group $(filter-out %.ld,$(romstage-objs)) $(romstage-libs) --no-whole-archive $(COMPILER_RT_romstage) --end-group -T $(objgenerated)/romstage.ld --oformat $(romstage-oformat)
$(objgenerated)/romstage_null.ld: $$(filter %.ld,$$(romstage-objs))
@printf " GEN $(subst $(obj)/,,$(@))\n"
rm -f $@
printf "ROMSTAGE_BASE = 0x0;\n" > $@.tmp
cat $^ >> $@.tmp
mv $@.tmp $@
$(objgenerated)/romstage.ld: $(objgenerated)/romstage_null.ld $(objcbfs)/base_xip.txt
@printf " GEN $(subst $(obj)/,,$(@))\n"
rm -f $@
sed -e 's/^/ROMSTAGE_BASE = /g' -e 's/$$/;/g' $(objcbfs)/base_xip.txt > $@.tmp
sed -e '/^ROMSTAGE_BASE/d' $(objgenerated)/romstage_null.ld >> $@.tmp
mv $@.tmp $@
$(objcbfs)/base_xip.txt: $(obj)/coreboot.pre1 $(objcbfs)/romstage_null.bin
rm -f $@
$(CBFSTOOL) $(obj)/coreboot.pre1 locate -T -f $(objcbfs)/romstage_null.bin -n $(CONFIG_CBFS_PREFIX)/romstage -P $(CONFIG_XIP_ROM_SIZE) > $@.tmp \
|| { echo "The romstage is larger than XIP size. Please expand the CONFIG_XIP_ROM_SIZE" ; exit 1; }
mv $@.tmp $@
$(objgenerated)/crt0.S: $$(crt0s)
@printf " GEN $(subst $(obj)/,,$(@))\n"
printf '$(foreach crt0,$(crt0s),#include "$(crt0)"\n)' > $@
# Compiling crt0 with -g seems to trigger https://sourceware.org/bugzilla/show_bug.cgi?id=6428
romstage-S-ccopts += -I. -g0
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
endif # CONFIG_ARCH_ROMSTAGE_X86_32 / CONFIG_ARCH_ROMSTAGE_X86_64
###############################################################################
# ramstage
###############################################################################
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32)$(CONFIG_ARCH_RAMSTAGE_X86_64),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
ifeq ($(CONFIG_COMPILE_IN_DSDT),y)
ramstage-srcs += $(obj)/dsdt.aml
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32),y)
target-objcopy=-O elf32-i386 -B i386
endif
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_64),y)
target-objcopy=-O elf64-x86_64 -B x86_64
endif
define ramstage-objs_aml_template
$(call src-to-obj,ramstage,$(1).aml): $(1).aml
@printf " OBJCOPY $$(subst $$(obj)/,,$$(@))\n"
cd $$(dir $$@) && $$(OBJCOPY_ramstage) -I binary $$(target-objcopy) $$(notdir $$<) $$(notdir $$@)
endef
endif
ramstage-srcs += $(wildcard src/mainboard/$(MAINBOARDDIR)/mainboard.c)
ifeq ($(CONFIG_GENERATE_MP_TABLE),y)
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/mptable.c),)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/mptable.c
endif
endif
ifeq ($(CONFIG_GENERATE_PIRQ_TABLE),y)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/irq_tables.c
endif
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/reset.c),)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/reset.c
endif
ifeq ($(CONFIG_HAVE_ACPI_TABLES),y)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/acpi_tables.c
ifeq ($(CONFIG_COMPILE_IN_DSDT),y)
$(eval $(call asl_template,dsdt,n))
else
$(eval $(call asl_template,dsdt))
endif
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/fadt.c),)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/fadt.c
endif
endif # CONFIG_GENERATE_ACPI_TABLES
ifeq ($(CONFIG_HAVE_SMI_HANDLER),y)
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/smihandler.c),)
smm-srcs += src/mainboard/$(MAINBOARDDIR)/smihandler.c
endif
endif
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/get_bus_conf.c),)
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/get_bus_conf.c
endif
ramstage-libs ?=
ifeq ($(CONFIG_RELOCATABLE_RAMSTAGE),y)
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32),y)
$(eval $(call rmodule_link,$(objcbfs)/ramstage.debug, $(objgenerated)/ramstage.o, $(CONFIG_HEAP_SIZE),x86_32))
else
$(eval $(call rmodule_link,$(objcbfs)/ramstage.debug, $(objgenerated)/ramstage.o, $(CONFIG_HEAP_SIZE),x86_64))
endif
# The rmodule_link defintion creates an elf file with .rmod extension.
$(objcbfs)/ramstage.elf: $(objcbfs)/ramstage.debug.rmod
cp $< $@
else
ramstage-srcs += $(src)/arch/x86/ramstage.ld
$(objcbfs)/ramstage.debug: $(objgenerated)/ramstage.o $(obj)/arch/x86/ramstage.ramstage.ld
@printf " CC $(subst $(obj)/,,$(@))\n"
New mechanism to define SRAM/memory map with automatic bounds checking This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-08-21 00:29:56 +02:00
$(LD_ramstage) $(CPPFLAGS) --gc-sections -o $@ -L$(obj) $< -T $(obj)/arch/x86/ramstage.ramstage.ld
endif
$(objgenerated)/ramstage.o: $$(ramstage-objs) $(COMPILER_RT_ramstage) $$(ramstage-libs)
@printf " CC $(subst $(obj)/,,$(@))\n"
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32),y)
$(LD_ramstage) -m elf_i386 -r -o $@ $(COMPILER_RT_FLAGS_ramstage) --whole-archive --start-group $(filter-out %.ld,$(ramstage-objs)) $(ramstage-libs) --no-whole-archive $(COMPILER_RT_ramstage) --end-group
else
$(LD_ramstage) -m elf_x86_64 -r -o $@ $(COMPILER_RT_FLAGS_ramstage) --whole-archive --start-group $(filter-out %.ld,$(ramstage-objs)) $(ramstage-libs) --no-whole-archive $(COMPILER_RT_ramstage) --end-group
endif
endif # CONFIG_ARCH_RAMSTAGE_X86_32 / CONFIG_ARCH_RAMSTAGE_X86_64
ifeq ($(CONFIG_ARCH_ROMSTAGE_X86_32)$(CONFIG_ARCH_ROMSTAGE_X86_64),y)
romstage-y += cbmem.c
romstage-y += boot.c
romstage-y += cbfs_and_run.c
romstage-$(CONFIG_ARCH_RAMSTAGE_X86_32) += cpu_common.c
romstage-y += memset.c
romstage-y += memcpy.c
romstage-y += memmove.c
romstage-y += mmap_boot.c
romstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c
endif # CONFIG_ARCH_ROMSTAGE_X86_32 / CONFIG_ARCH_ROMSTAGE_X86_64
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32)$(CONFIG_ARCH_RAMSTAGE_X86_64),y)
ramstage-y += boot.c
ramstage-y += gdt.c
ramstage-y += tables.c
ramstage-y += cbmem.c
ramstage-$(CONFIG_GENERATE_MP_TABLE) += mpspec.c
ramstage-$(CONFIG_GENERATE_PIRQ_TABLE) += pirq_routing.c
ramstage-$(CONFIG_HAVE_ACPI_TABLES) += acpi.c
ramstage-$(CONFIG_GENERATE_SMBIOS_TABLES) += smbios.c
ramstage-$(CONFIG_HAVE_ACPI_TABLES) += acpigen.c
ramstage-$(CONFIG_HAVE_ACPI_RESUME) += wakeup.S
ramstage-y += c_start.S
ramstage-y += cpu.c
ramstage-y += cpu_common.c
ramstage-y += pci_ops_conf1.c
ramstage-$(CONFIG_MMCONF_SUPPORT) += pci_ops_mmconf.c
ramstage-y += exception.c
ramstage-$(CONFIG_IOAPIC) += ioapic.c
ramstage-y += memset.c
ramstage-y += memcpy.c
ramstage-y += memmove.c
ramstage-y += ebda.c
ramstage-y += mmap_boot.c
ramstage-$(CONFIG_COOP_MULTITASKING) += thread.c
ramstage-$(CONFIG_COOP_MULTITASKING) += thread_switch.S
ramstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c
smm-y += memset.c
smm-y += memcpy.c
smm-y += memmove.c
smm-y += mmap_boot.c
ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32),y)
rmodules_x86_32-y += memset.c
rmodules_x86_32-y += memcpy.c
rmodules_x86_32-y += memmove.c
else
rmodules_x86_64-y += memset.c
rmodules_x86_64-y += memcpy.c
rmodules_x86_64-y += memmove.c
endif
endif # CONFIG_ARCH_RAMSTAGE_X86_32 / CONFIG_ARCH_RAMSTAGE_X86_64