2012-07-20 07:11:21 +02:00
|
|
|
################################################################################
|
2010-08-14 22:38:17 +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>
|
2010-08-14 22:38:17 +02:00
|
|
|
## 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
|
2013-02-23 18:37:27 +01:00
|
|
|
## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
2010-08-14 22:38:17 +02:00
|
|
|
##
|
2014-04-23 01:33:22 +02:00
|
|
|
###############################################################################
|
2009-08-12 17:00:51 +02:00
|
|
|
# Take care of subdirectories
|
2014-04-23 01:33:22 +02:00
|
|
|
###############################################################################
|
2009-08-12 17:00:51 +02:00
|
|
|
subdirs-y += boot
|
2010-01-30 10:47:18 +01:00
|
|
|
# subdirs-y += init
|
2009-08-12 17:00:51 +02:00
|
|
|
subdirs-y += lib
|
|
|
|
|
subdirs-y += smp
|
|
|
|
|
|
2014-01-18 16:26:11 +01:00
|
|
|
ifeq ($(CONFIG_COMPILER_GCC),y)
|
2014-05-19 09:23:57 +02:00
|
|
|
DISASSEMBLY=-Wa,-acdlns
|
2014-01-18 16:26:11 +01:00
|
|
|
else
|
2014-05-22 17:32:44 +02:00
|
|
|
DISASSEMBLY=-Wa,--divide
|
2014-01-18 16:26:11 +01:00
|
|
|
endif
|
|
|
|
|
|
2010-09-30 18:55:02 +02:00
|
|
|
OPTION_TABLE_H:=
|
|
|
|
|
ifeq ($(CONFIG_HAVE_OPTION_TABLE),y)
|
2011-01-30 17:31:15 +01:00
|
|
|
cbfs-files-y += cmos_layout.bin
|
|
|
|
|
cmos_layout.bin-file = $(obj)/cmos_layout.bin
|
|
|
|
|
cmos_layout.bin-type = 0x01aa
|
2011-01-18 14:56:36 +01:00
|
|
|
|
2010-09-30 18:55:02 +02:00
|
|
|
OPTION_TABLE_H:=$(obj)/option_table.h
|
|
|
|
|
endif
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2011-01-30 17:37:39 +01:00
|
|
|
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
|
|
|
|
|
|
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_ARCH_ROMSTAGE_X86_32),y)
|
2014-04-23 01:33:22 +02:00
|
|
|
CBFSTOOL_PRE1_OPTS = -m x86 -o $$(( $(CONFIG_ROM_SIZE) - $(CONFIG_CBFS_SIZE) ))
|
|
|
|
|
CBFSTOOL_PRE_OPTS = -b $(shell cat $(objcbfs)/base_xip.txt)
|
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
|
2011-01-30 17:37:39 +01:00
|
|
|
|
2012-07-20 07:11:21 +02:00
|
|
|
################################################################################
|
2009-08-12 17:00:51 +02:00
|
|
|
# i386 specific tools
|
2012-04-14 11:55:13 +02:00
|
|
|
NVRAMTOOL:=$(objutil)/nvramtool/nvramtool
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2012-04-14 11:55:13 +02:00
|
|
|
$(OPTION_TABLE_H): $(NVRAMTOOL) $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout
|
2009-10-28 18:10:51 +01:00
|
|
|
@printf " OPTION $(subst $(obj)/,,$(@))\n"
|
2012-04-14 11:55:13 +02:00
|
|
|
$(NVRAMTOOL) -y $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout -H $@
|
2010-04-15 16:32:17 +02:00
|
|
|
|
2012-04-14 11:55:13 +02:00
|
|
|
$(obj)/cmos_layout.bin: $(NVRAMTOOL) $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout
|
2010-04-15 16:32:17 +02:00
|
|
|
@printf " OPTION $(subst $(obj)/,,$(@))\n"
|
2012-04-14 11:55:13 +02:00
|
|
|
$(NVRAMTOOL) -y $(top)/src/mainboard/$(MAINBOARDDIR)/cmos.layout -L $@
|
2009-08-12 17:00:51 +02:00
|
|
|
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
###############################################################################
|
|
|
|
|
# bootblock
|
|
|
|
|
###############################################################################
|
2011-11-01 18:55:59 +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
|
|
|
ifeq ($(CONFIG_ARCH_BOOTBLOCK_X86_32),y)
|
|
|
|
|
|
2011-11-01 18:55:59 +01:00
|
|
|
bootblock_lds = $(src)/arch/x86/init/ldscript_failover.lb
|
|
|
|
|
bootblock_lds += $(src)/cpu/x86/16bit/entry16.lds
|
|
|
|
|
bootblock_lds += $(src)/cpu/x86/16bit/reset16.lds
|
|
|
|
|
bootblock_lds += $(src)/arch/x86/lib/id.lds
|
|
|
|
|
bootblock_lds += $(chipset_bootblock_lds)
|
2012-12-03 23:17:40 +01:00
|
|
|
ifeq ($(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE),y)
|
|
|
|
|
bootblock_lds += $(src)/cpu/intel/fit/fit.lds
|
|
|
|
|
endif
|
2011-11-01 18:55:59 +01:00
|
|
|
|
|
|
|
|
bootblock_inc = $(src)/arch/x86/init/prologue.inc
|
|
|
|
|
bootblock_inc += $(src)/cpu/x86/16bit/entry16.inc
|
|
|
|
|
bootblock_inc += $(src)/cpu/x86/16bit/reset16.inc
|
|
|
|
|
bootblock_inc += $(src)/cpu/x86/32bit/entry32.inc
|
|
|
|
|
bootblock_inc += $(src)/arch/x86/lib/id.inc
|
2012-12-03 23:17:40 +01:00
|
|
|
ifeq ($(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE),y)
|
|
|
|
|
bootblock_inc += $(src)/cpu/intel/fit/fit.inc
|
|
|
|
|
endif
|
2011-11-01 18:55:59 +01:00
|
|
|
bootblock_inc += $(chipset_bootblock_inc)
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_SSE),y)
|
|
|
|
|
bootblock_inc += $(src)/cpu/x86/sse_enable.inc
|
|
|
|
|
endif
|
2012-04-19 11:14:53 +02:00
|
|
|
bootblock_inc += $(objgenerated)/bootblock.inc
|
2011-11-01 18:55:59 +01:00
|
|
|
bootblock_inc += $(src)/arch/x86/lib/walkcbfs.S
|
|
|
|
|
|
2014-02-26 14:19:04 +01:00
|
|
|
bootblock_romccflags := -mcpu=i386 -O2 -D__PRE_RAM__ -D__BOOT_BLOCK__
|
2011-11-01 18:55:59 +01:00
|
|
|
ifeq ($(CONFIG_SSE),y)
|
2014-02-26 14:19:04 +01:00
|
|
|
bootblock_romccflags := -mcpu=k7 -msse -O2 -D__PRE_RAM__ -D__BOOT_BLOCK__
|
2011-11-01 18:55:59 +01:00
|
|
|
endif
|
|
|
|
|
|
2012-04-19 11:14:53 +02:00
|
|
|
$(objgenerated)/bootblock.ld: $$(bootblock_lds) $(obj)/ldoptions
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " GEN $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
printf '$(foreach ldscript,ldoptions $(bootblock_lds),INCLUDE "$(ldscript)"\n)' > $@
|
|
|
|
|
|
2012-05-15 00:20:26 +02:00
|
|
|
$(objgenerated)/bootblock_inc.S: $$(bootblock_inc)
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " GEN $(subst $(obj)/,,$(@))\n"
|
2012-01-17 13:13:59 +01:00
|
|
|
printf '$(foreach crt0,$(bootblock_inc),#include "$(crt0)"\n)' > $@
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-04-19 11:14:53 +02:00
|
|
|
$(objgenerated)/bootblock.o: $(objgenerated)/bootblock.s
|
2014-08-02 13:45:17 +02:00
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_bootblock) $(CFLAGS_x86_32) $(DISASSEMBLY) -c -o $@ $< > $(basename $@).disasm
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-05-15 00:20:26 +02:00
|
|
|
$(objgenerated)/bootblock.s: $(objgenerated)/bootblock_inc.S $(obj)/config.h $(obj)/build.h
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
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_bootblock) -MMD -x assembler-with-cpp -E -I$(src)/include -I$(src)/arch/x86/include -I$(obj) -include $(obj)/build.h -include $(obj)/config.h -I. -I$(src) $< -o $@
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-04-19 11:14:53 +02:00
|
|
|
$(objgenerated)/bootblock.inc: $(src)/arch/x86/init/$(subst ",,$(CONFIG_BOOTBLOCK_SOURCE)) $(objutil)/romcc/romcc $(OPTION_TABLE_H)
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " ROMCC $(subst $(obj)/,,$(@))\n"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_bootblock) $(CPPFLAGS_bootblock) -MM -MT$(objgenerated)/bootblock.inc \
|
2012-04-19 11:14:53 +02:00
|
|
|
$< > $(objgenerated)/bootblock.inc.d
|
2014-05-19 09:23:57 +02:00
|
|
|
$(ROMCC) -c -S $(bootblock_romccflags) -I. $(CPPFLAGS_bootblock) $< -o $@
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-04-19 11:14:53 +02:00
|
|
|
$(objcbfs)/bootblock.debug: $(objgenerated)/bootblock.o $(objgenerated)/bootblock.ld
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " LINK $(subst $(obj)/,,$(@))\n"
|
2012-03-11 20:15:21 +01:00
|
|
|
ifeq ($(CONFIG_COMPILER_LLVM_CLANG),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
|
|
|
$(LD_bootblock) -m elf_i386 -static -o $@ -L$(obj) $< -T $(objgenerated)/bootblock.ld
|
2012-03-11 20:15:21 +01:00
|
|
|
else
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_bootblock) $(CFLAGS_bootblock) -nostdlib -nostartfiles -static -o $@ -L$(obj) -T $(objgenerated)/bootblock.ld $<
|
2012-03-11 20:15:21 +01:00
|
|
|
endif
|
2011-11-01 18:55:59 +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
|
|
|
|
|
|
|
|
endif # CONFIG_ARCH_BOOTBLOCK_X86_32
|
|
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
###############################################################################
|
|
|
|
|
# romstage
|
|
|
|
|
###############################################################################
|
|
|
|
|
|
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_ARCH_ROMSTAGE_X86_32),y)
|
|
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
crt0s = $(src)/arch/x86/init/prologue.inc
|
|
|
|
|
ldscripts =
|
|
|
|
|
ldscripts += $(src)/arch/x86/init/romstage.ld
|
|
|
|
|
crt0s += $(src)/cpu/x86/32bit/entry32.inc
|
|
|
|
|
ldscripts += $(src)/cpu/x86/32bit/entry32.lds
|
|
|
|
|
|
|
|
|
|
crt0s += $(src)/cpu/x86/fpu_enable.inc
|
|
|
|
|
ifeq ($(CONFIG_SSE),y)
|
|
|
|
|
crt0s += $(src)/cpu/x86/sse_enable.inc
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
crt0s += $(cpu_incs)
|
|
|
|
|
crt0s += $(cpu_incs-y)
|
|
|
|
|
|
|
|
|
|
crt0s += $(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_ROMCC),y)
|
|
|
|
|
crt0s += $(src)/arch/x86/init/crt0_romcc_epilogue.inc
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_ROMCC),y)
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
$(objcbfs)/romstage_%.bin: $(objcbfs)/romstage_%.elf
|
|
|
|
|
@printf " OBJCOPY $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
$(OBJCOPY_romstage) -O binary $< $@
|
|
|
|
|
|
|
|
|
|
$(objcbfs)/romstage_%.elf: $(objcbfs)/romstage_%.debug
|
|
|
|
|
@printf " OBJCOPY $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
cp $< $@.tmp
|
|
|
|
|
$(OBJCOPY_romstage) --strip-debug $@.tmp
|
|
|
|
|
$(OBJCOPY_romstage) --add-gnu-debuglink=$< $@.tmp
|
|
|
|
|
mv $@.tmp $@
|
|
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
$(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"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(ROMCC) -c -S $(ROMCCFLAGS) -D__PRE_RAM__ -I. $(CPPFLAGS_romstage) $< -o $@
|
2014-04-23 01:33:22 +02:00
|
|
|
else
|
|
|
|
|
|
|
|
|
|
$(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc: $(src)/mainboard/$(MAINBOARDDIR)/romstage.c $(OPTION_TABLE_H) $(obj)/build.h $(obj)/config.h
|
|
|
|
|
@printf " CC romstage.inc\n"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_romstage) $(CPPFLAGS_romstage) $(CFLAGS_romstage) -MMD -D__PRE_RAM__ -I$(src) -I. -I$(obj) -c -S $< -o $@
|
2014-04-23 01:33:22 +02:00
|
|
|
|
|
|
|
|
$(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc: $(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc
|
|
|
|
|
@printf " POST romstage.inc\n"
|
|
|
|
|
sed -e 's/\.rodata/.rom.data/g' -e 's/\^\.text/.section .rom.text/g' \
|
|
|
|
|
-e 's/\^\.section \.text/.section .rom.text/g' $^ > $@.tmp
|
|
|
|
|
mv $@.tmp $@
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
romstage-srcs += $(objgenerated)/crt0.s
|
2012-03-31 09:21:29 +02:00
|
|
|
|
2014-03-29 19:01:11 +01:00
|
|
|
romstage-libs ?=
|
|
|
|
|
|
|
|
|
|
$(objcbfs)/romstage_null.debug: $$(romstage-objs) $(objgenerated)/romstage_null.ld $$(romstage-libs)
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " LINK $(subst $(obj)/,,$(@))\n"
|
2012-03-11 20:15:21 +01:00
|
|
|
ifeq ($(CONFIG_COMPILER_LLVM_CLANG),y)
|
2014-05-22 17:29:00 +02:00
|
|
|
$(LD_romstage) -nostdlib -nostartfiles -static -o $@ -L$(obj) --start-group $(romstage-objs) $(romstage-libs) $(LIBGCC_FILE_NAME_romstage) --end-group -T $(objgenerated)/romstage_null.ld
|
2012-03-11 20:15:21 +01:00
|
|
|
else
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_romstage) $(CFLAGS_romstage) -nostdlib -nostartfiles -static -o $@ -L$(obj) -T $(objgenerated)/romstage_null.ld -Wl,--wrap,__divdi3 -Wl,--wrap,__udivdi3 -Wl,--wrap,__moddi3 -Wl,--wrap,__umoddi3 -Wl,--start-group $(romstage-objs) $(romstage-libs) $(LIBGCC_FILE_NAME_romstage) -Wl,--end-group
|
2012-03-11 20:15:21 +01:00
|
|
|
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
|
|
|
$(NM_romstage) $@ | grep -q " [DdBb] "; if [ $$? -eq 0 ]; then \
|
2012-07-31 23:52:04 +02:00
|
|
|
echo "Forbidden global variables in romstage:"; \
|
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
|
|
|
$(NM_romstage) $@ | grep " [DdBb] "; test "$(CONFIG_CPU_AMD_AGESA)" = y; \
|
2012-07-31 23:52:04 +02:00
|
|
|
else true; fi
|
2012-03-31 09:21:29 +02:00
|
|
|
|
2014-03-29 19:01:11 +01:00
|
|
|
$(objcbfs)/romstage_xip.debug: $$(romstage-objs) $(objgenerated)/romstage_xip.ld $$(romstage-libs)
|
2012-03-31 09:21:29 +02:00
|
|
|
@printf " LINK $(subst $(obj)/,,$(@))\n"
|
2012-03-11 20:15:21 +01:00
|
|
|
ifeq ($(CONFIG_COMPILER_LLVM_CLANG),y)
|
2014-05-22 17:29:00 +02:00
|
|
|
$(LD_romstage) -nostdlib -nostartfiles -static -o $@ -L$(obj) --start-group $(romstage-objs) $(romstage-libs) $(LIBGCC_FILE_NAME_romstage) --end-group -T $(objgenerated)/romstage_xip.ld
|
2012-03-11 20:15:21 +01:00
|
|
|
else
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_romstage) $(CFLAGS_romstage) -nostdlib -nostartfiles -static -o $@ -L$(obj) -T $(objgenerated)/romstage_xip.ld -Wl,--wrap,__divdi3 -Wl,--wrap,__udivdi3 -Wl,--wrap,__moddi3 -Wl,--wrap,__umoddi3 -Wl,--start-group $(romstage-objs) $(romstage-libs) $(LIBGCC_FILE_NAME_romstage) -Wl,--end-group
|
2012-03-11 20:15:21 +01:00
|
|
|
endif
|
2012-04-19 13:43:47 +02:00
|
|
|
|
|
|
|
|
$(objgenerated)/romstage_null.ld: $$(ldscripts) $(obj)/ldoptions
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " GEN $(subst $(obj)/,,$(@))\n"
|
2012-03-31 09:21:29 +02:00
|
|
|
rm -f $@
|
|
|
|
|
printf "ROMSTAGE_BASE = 0x0;\n" > $@.tmp
|
|
|
|
|
printf '$(foreach ldscript,ldoptions $(ldscripts),INCLUDE "$(ldscript:$(obj)/%=%)"\n)' >> $@.tmp
|
|
|
|
|
mv $@.tmp $@
|
|
|
|
|
|
2012-04-19 13:43:47 +02:00
|
|
|
$(objgenerated)/romstage_xip.ld: $(objgenerated)/romstage_null.ld $(objcbfs)/base_xip.txt
|
2012-03-31 09:21:29 +02:00
|
|
|
@printf " GEN $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
rm -f $@
|
2012-04-19 13:43:47 +02:00
|
|
|
sed -e 's/^/ROMSTAGE_BASE = /g' -e 's/$$/;/g' $(objcbfs)/base_xip.txt > $@.tmp
|
|
|
|
|
sed -e '/ROMSTAGE_BASE/d' $(objgenerated)/romstage_null.ld >> $@.tmp
|
2012-03-31 09:21:29 +02:00
|
|
|
mv $@.tmp $@
|
|
|
|
|
|
2012-04-19 13:43:47 +02:00
|
|
|
$(objcbfs)/base_xip.txt: $(obj)/coreboot.pre1 $(objcbfs)/romstage_null.bin
|
2012-03-31 09:21:29 +02:00
|
|
|
rm -f $@
|
2013-03-19 05:17:12 +01:00
|
|
|
$(CBFSTOOL) $(obj)/coreboot.pre1 locate -T -f $(objcbfs)/romstage_null.bin -n $(CONFIG_CBFS_PREFIX)/romstage -P $(CONFIG_XIP_ROM_SIZE) > $@.tmp \
|
2012-03-31 09:21:29 +02:00
|
|
|
|| { echo "The romstage is larger than XIP size. Please expand the CONFIG_XIP_ROM_SIZE" ; exit 1; }
|
2013-01-28 16:00:47 +01:00
|
|
|
mv $@.tmp $@
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-05-15 00:20:26 +02:00
|
|
|
$(objgenerated)/crt0.romstage.S: $$(crt0s)
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " GEN $(subst $(obj)/,,$(@))\n"
|
2012-01-17 13:13:59 +01:00
|
|
|
printf '$(foreach crt0,$(crt0s),#include "$(crt0:$(obj)/%=%)"\n)' > $@
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-04-19 13:43:47 +02:00
|
|
|
$(objgenerated)/crt0.romstage.o: $(objgenerated)/crt0.s
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_romstage) $(CFLAGS_x86_32) $(DISASSEMBLY) -c -o $@ $< > $(basename $@).disasm
|
2011-11-01 18:55:59 +01:00
|
|
|
|
2012-05-15 00:20:26 +02:00
|
|
|
$(objgenerated)/crt0.s: $(objgenerated)/crt0.romstage.S $(obj)/config.h $(obj)/build.h
|
2011-11-01 18:55:59 +01:00
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_romstage) $(CPPFLAGS_romstage) -MMD -x assembler-with-cpp -E -I$(src)/include -I$(src)/arch/x86/include -I$(obj) -include $(obj)/config.h -include $(obj)/build.h -I. -I$(src) $< -o $@
|
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
|
2010-12-30 18:39:50 +01:00
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
###############################################################################
|
|
|
|
|
# ramstage
|
|
|
|
|
###############################################################################
|
|
|
|
|
|
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_ARCH_RAMSTAGE_X86_32),y)
|
|
|
|
|
|
2014-04-23 01:33:22 +02:00
|
|
|
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_GENERATE_ACPI_TABLES),y)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/acpi_tables.c
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/dsdt.asl
|
|
|
|
|
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/ssdt2.asl),)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/ssdt2.asl
|
|
|
|
|
endif
|
|
|
|
|
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/ssdt3.asl),)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/ssdt3.asl
|
|
|
|
|
endif
|
|
|
|
|
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/ssdt4.asl),)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/ssdt4.asl
|
|
|
|
|
endif
|
|
|
|
|
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/ssdt5.asl),)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/ssdt5.asl
|
|
|
|
|
endif
|
|
|
|
|
ifneq ($(wildcard src/mainboard/$(MAINBOARDDIR)/fadt.c),)
|
|
|
|
|
ramstage-srcs += src/mainboard/$(MAINBOARDDIR)/fadt.c
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
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)
|
|
|
|
|
|
2014-07-31 18:28:55 +02:00
|
|
|
$(eval $(call rmodule_link,$(objcbfs)/ramstage.debug, $(objgenerated)/ramstage.o, $(CONFIG_HEAP_SIZE),x86_32))
|
2014-04-23 01:33:22 +02:00
|
|
|
|
|
|
|
|
# The rmodule_link defintion creates an elf file with .rmod extension.
|
|
|
|
|
$(objcbfs)/ramstage.elf: $(objcbfs)/ramstage.debug.rmod
|
|
|
|
|
cp $< $@
|
|
|
|
|
|
|
|
|
|
else
|
|
|
|
|
|
|
|
|
|
$(objcbfs)/ramstage.debug: $(objgenerated)/ramstage.o $(src)/arch/x86/ramstage.ld
|
|
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
ifeq ($(CONFIG_COMPILER_LLVM_CLANG),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
|
|
|
$(LD_ramstage) -m elf_i386 -o $@ -L$(obj) $< -T $(src)/arch/x86/ramstage.ld
|
2014-04-23 01:33:22 +02:00
|
|
|
else
|
2014-05-19 09:23:57 +02:00
|
|
|
$(CC_ramstage) $(CFLAGS_ramstage) -nostdlib -nostartfiles -static -o $@ -L$(obj) -T $(src)/arch/x86/ramstage.ld $<
|
2014-04-23 01:33:22 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
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
|
|
|
$(objgenerated)/ramstage.o: $$(ramstage-objs) $(LIBGCC_FILE_NAME_ramstage) $$(ramstage-libs)
|
2014-04-23 01:33:22 +02:00
|
|
|
@printf " CC $(subst $(obj)/,,$(@))\n"
|
|
|
|
|
ifeq ($(CONFIG_COMPILER_LLVM_CLANG),y)
|
2014-05-22 17:29:00 +02:00
|
|
|
$(LD_ramstage) -m elf_i386 -r -o $@ --start-group $(ramstage-objs) $(ramstage-libs) $(LIBGCC_FILE_NAME_ramstage) --end-group
|
2014-04-23 01:33:22 +02:00
|
|
|
else
|
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_ramstage) $(CFLAGS_ramstage) -nostdlib -r -o $@ -Wl,--wrap,__divdi3 -Wl,--wrap,__udivdi3 -Wl,--wrap,__moddi3 -Wl,--wrap,__umoddi3 -Wl,--start-group $(ramstage-objs) $(ramstage-libs) $(LIBGCC_FILE_NAME_ramstage) -Wl,--end-group
|
2014-04-23 01:33:22 +02:00
|
|
|
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_RAMSTAGE_X86_32
|
2014-04-23 01:33:22 +02:00
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2010-12-30 18:39:50 +01:00
|
|
|
seabios:
|
|
|
|
|
$(MAKE) -C payloads/external/SeaBIOS -f Makefile.inc \
|
2011-02-07 21:16:40 +01:00
|
|
|
HOSTCC="$(HOSTCC)" \
|
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="$(CC_x86_32)" LD="$(LD_x86_32)" OBJDUMP="$(OBJDUMP_x86_32)" \
|
|
|
|
|
OBJCOPY="$(OBJCOPY_x86_32)" STRIP="$(STRIP_x86_32)" \
|
2014-05-10 14:21:38 +02:00
|
|
|
AS="$(AS_x86_32)" \
|
2010-12-30 18:39:50 +01:00
|
|
|
CONFIG_SEABIOS_MASTER=$(CONFIG_SEABIOS_MASTER) \
|
2012-01-21 19:34:22 +01:00
|
|
|
CONFIG_SEABIOS_STABLE=$(CONFIG_SEABIOS_STABLE) \
|
2014-04-02 00:47:33 +02:00
|
|
|
CONFIG_SEABIOS_THREAD_OPTIONROMS=$(CONFIG_SEABIOS_THREAD_OPTIONROMS) \
|
2014-09-12 19:43:49 +02:00
|
|
|
CONFIG_SEABIOS_VGA_COREBOOT=$(CONFIG_SEABIOS_VGA_COREBOOT) \
|
2014-07-25 22:33:49 +02:00
|
|
|
CONFIG_CONSOLE_SERIAL=$(CONFIG_CONSOLE_SERIAL) \
|
|
|
|
|
CONFIG_TTYS0_BASE=$(CONFIG_TTYS0_BASE) \
|
2014-07-25 22:39:05 +02:00
|
|
|
CONFIG_SEABIOS_MALLOC_UPPERMEMORY=$(CONFIG_SEABIOS_MALLOC_UPPERMEMORY) \
|
2012-05-15 05:06:10 +02:00
|
|
|
OUT=$(abspath $(obj)) IASL="$(IASL)"
|
2012-01-21 19:34:22 +01:00
|
|
|
|
2011-04-15 05:34:05 +02:00
|
|
|
filo:
|
|
|
|
|
$(MAKE) -C payloads/external/FILO -f Makefile.inc \
|
|
|
|
|
HOSTCC="$(HOSTCC)" \
|
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="$(CC_x86_32)" LD="$(LD_x86_32)" OBJDUMP="$(OBJDUMP_x86_32)" \
|
|
|
|
|
OBJCOPY="$(OBJCOPY_x86_32)" STRIP="$(STRIP_x86_32)" \
|
2011-04-15 05:34:05 +02:00
|
|
|
CONFIG_FILO_MASTER=$(CONFIG_FILO_MASTER) \
|
|
|
|
|
CONFIG_FILO_STABLE=$(CONFIG_FILO_STABLE)
|
2010-12-30 18:39:50 +01:00
|
|
|
|
2013-11-14 12:10:08 +01:00
|
|
|
|
|
|
|
|
grub2:
|
|
|
|
|
$(MAKE) -C payloads/external/GRUB2 -f Makefile.inc \
|
|
|
|
|
HOSTCC="$(HOSTCC)" \
|
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="$(CC_x86_32)" LD="$(LD_x86_32)" OBJDUMP="$(OBJDUMP_x86_32)" \
|
|
|
|
|
OBJCOPY="$(OBJCOPY_x86_32)" STRIP="$(STRIP_x86_32)" \
|
2013-11-14 12:10:08 +01:00
|
|
|
CONFIG_GRUB2_MASTER=$(CONFIG_GRUB2_MASTER)
|
