2012-11-30 21:19:59 +01:00
|
|
|
#
|
|
|
|
# This file is part of the coreboot project.
|
|
|
|
#
|
|
|
|
# Copyright (C) 2009 coresystems GmbH
|
|
|
|
#
|
|
|
|
# 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
|
2012-11-30 21:19:59 +01:00
|
|
|
#
|
2014-01-31 00:19:46 +01:00
|
|
|
subdirs-y += loaders
|
2011-04-15 00:28:00 +02:00
|
|
|
|
2015-03-20 21:55:08 +01:00
|
|
|
bootblock-y += prog_ops.c
|
2014-11-11 02:22:04 +01:00
|
|
|
bootblock-y += cbfs.c cbfs_core.c
|
2014-05-01 21:23:09 +02:00
|
|
|
bootblock-$(CONFIG_COMMON_CBFS_SPI_WRAPPER) += cbfs_spi.c
|
2014-11-07 00:22:10 +01:00
|
|
|
bootblock-$(CONFIG_GENERIC_GPIO_LIB) += gpio.c
|
2014-05-01 21:23:09 +02:00
|
|
|
|
2014-09-25 17:05:15 +02:00
|
|
|
bootblock-$(CONFIG_GENERIC_UDELAY) += timer.c
|
|
|
|
|
2014-12-21 07:55:47 +01:00
|
|
|
bootblock-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
|
2013-01-31 18:09:24 +01:00
|
|
|
bootblock-y += memchr.c
|
|
|
|
bootblock-y += memcmp.c
|
|
|
|
|
2015-03-20 21:55:08 +01:00
|
|
|
verstage-y += prog_ops.c
|
2014-06-20 04:16:24 +02:00
|
|
|
verstage-y += delay.c
|
|
|
|
verstage-y += cbfs.c
|
|
|
|
verstage-y += memcmp.c
|
|
|
|
verstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
|
2014-10-16 20:24:12 +02:00
|
|
|
verstage-$(CONFIG_COMMON_CBFS_SPI_WRAPPER) += cbfs_spi.c
|
|
|
|
verstage-y += tlcl.c
|
|
|
|
verstage-$(CONFIG_GENERIC_UDELAY) += timer.c
|
2014-11-07 00:22:10 +01:00
|
|
|
verstage-$(CONFIG_GENERIC_GPIO_LIB) += gpio.c
|
2014-06-20 04:16:24 +02:00
|
|
|
|
2015-03-20 21:55:08 +01:00
|
|
|
romstage-y += prog_ops.c
|
2011-09-16 11:18:56 +02:00
|
|
|
romstage-y += memchr.c
|
2011-04-15 00:28:00 +02:00
|
|
|
romstage-y += memcmp.c
|
2014-07-31 18:28:55 +02:00
|
|
|
$(foreach arch,$(ARCH_SUPPORTED),\
|
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
|
|
|
$(eval rmodules_$(arch)-y += memcmp.c) \
|
|
|
|
$(eval rmodules_$(arch)-y += rmodule.ld))
|
2014-07-31 18:28:55 +02:00
|
|
|
|
2013-08-30 01:01:05 +02:00
|
|
|
romstage-$(CONFIG_I2C_TPM) += delay.c
|
2014-11-11 02:22:04 +01:00
|
|
|
romstage-y += cbfs.c cbfs_core.c
|
2014-05-01 21:23:09 +02:00
|
|
|
romstage-$(CONFIG_COMMON_CBFS_SPI_WRAPPER) += cbfs_spi.c
|
2014-11-11 02:27:06 +01:00
|
|
|
romstage-$(CONFIG_COMPRESS_RAMSTAGE) += lzma.c lzmadecode.c
|
2014-02-13 22:07:50 +01:00
|
|
|
romstage-$(CONFIG_PRIMITIVE_MEMTEST) += primitive_memtest.c
|
|
|
|
ramstage-$(CONFIG_PRIMITIVE_MEMTEST) += primitive_memtest.c
|
2011-04-15 00:28:00 +02:00
|
|
|
romstage-$(CONFIG_CACHE_AS_RAM) += ramtest.c
|
2014-11-07 00:22:10 +01:00
|
|
|
romstage-$(CONFIG_GENERIC_GPIO_LIB) += gpio.c
|
2013-03-30 02:02:13 +01:00
|
|
|
|
2013-10-11 21:08:02 +02:00
|
|
|
ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
|
2013-03-23 06:00:54 +01:00
|
|
|
romstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c
|
2013-09-10 12:50:32 +02:00
|
|
|
romstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
|
|
|
|
endif
|
2013-06-20 16:24:14 +02:00
|
|
|
|
2012-03-31 01:28:20 +02:00
|
|
|
romstage-y += compute_ip_checksum.c
|
2014-11-29 11:32:12 +01:00
|
|
|
ifeq ($(CONFIG_COMPILER_GCC),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
|
|
|
romstage-$(CONFIG_ARCH_ROMSTAGE_X86_32) += gcc.c
|
2014-05-22 17:29:00 +02:00
|
|
|
ramstage-$(CONFIG_ARCH_RAMSTAGE_X86_32) += gcc.c
|
|
|
|
endif
|
2011-04-15 00:28:00 +02:00
|
|
|
|
2014-09-25 17:05:15 +02:00
|
|
|
romstage-$(CONFIG_GENERIC_UDELAY) += timer.c
|
|
|
|
|
2015-03-20 21:55:08 +01:00
|
|
|
ramstage-y += prog_ops.c
|
2012-11-30 21:23:45 +01:00
|
|
|
ramstage-y += hardwaremain.c
|
|
|
|
ramstage-y += selfboot.c
|
2013-03-20 22:08:04 +01:00
|
|
|
ramstage-y += coreboot_table.c
|
2014-02-19 04:55:02 +01:00
|
|
|
ramstage-y += bootmem.c
|
2011-09-16 11:18:56 +02:00
|
|
|
ramstage-y += memchr.c
|
2010-09-30 18:55:02 +02:00
|
|
|
ramstage-y += memcmp.c
|
|
|
|
ramstage-y += malloc.c
|
2012-06-23 22:33:32 +02:00
|
|
|
smm-$(CONFIG_SMM_TSEG) += malloc.c
|
2010-09-30 18:55:02 +02:00
|
|
|
ramstage-y += delay.c
|
|
|
|
ramstage-y += fallback_boot.c
|
|
|
|
ramstage-y += compute_ip_checksum.c
|
2014-11-11 02:22:04 +01:00
|
|
|
ramstage-y += cbfs.c cbfs_core.c
|
2014-05-01 21:23:09 +02:00
|
|
|
ramstage-$(CONFIG_COMMON_CBFS_SPI_WRAPPER) += cbfs_spi.c
|
2014-11-11 02:27:06 +01:00
|
|
|
ramstage-y += lzma.c lzmadecode.c
|
2012-06-13 01:29:32 +02:00
|
|
|
ramstage-y += stack.c
|
2011-04-15 00:28:00 +02:00
|
|
|
ramstage-y += clog2.c
|
2014-01-12 22:42:58 +01:00
|
|
|
romstage-y += clog2.c
|
2011-09-30 21:02:18 +02:00
|
|
|
ramstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
|
2010-09-30 18:55:02 +02:00
|
|
|
ramstage-$(CONFIG_BOOTSPLASH) += jpeg.c
|
2011-09-02 23:23:41 +02:00
|
|
|
ramstage-$(CONFIG_TRACE) += trace.c
|
2011-09-22 01:12:39 +02:00
|
|
|
ramstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c
|
Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
|
|
|
ramstage-$(CONFIG_COVERAGE) += libgcov.c
|
2013-03-13 22:35:01 +01:00
|
|
|
ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += edid.c
|
2013-03-23 02:44:46 +01:00
|
|
|
ramstage-y += memrange.c
|
2013-05-06 19:20:52 +02:00
|
|
|
ramstage-$(CONFIG_COOP_MULTITASKING) += thread.c
|
2013-04-30 16:58:12 +02:00
|
|
|
ramstage-$(CONFIG_TIMER_QUEUE) += timer_queue.c
|
2014-11-05 23:05:56 +01:00
|
|
|
ramstage-$(CONFIG_GENERIC_GPIO_LIB) += gpio.c
|
2014-09-25 17:05:15 +02:00
|
|
|
ramstage-$(CONFIG_GENERIC_UDELAY) += timer.c
|
2010-02-22 05:33:13 +01:00
|
|
|
|
2014-11-28 10:24:19 +01:00
|
|
|
romstage-y += cbmem_common.c dynamic_cbmem.c
|
|
|
|
ramstage-y += cbmem_common.c dynamic_cbmem.c
|
2013-03-13 18:41:44 +01:00
|
|
|
|
2013-07-19 01:24:08 +02:00
|
|
|
ramstage-y += hexdump.c
|
|
|
|
romstage-y += hexdump.c
|
|
|
|
|
2014-10-01 19:50:20 +02:00
|
|
|
romstage-$(CONFIG_REG_SCRIPT) += reg_script.c
|
2013-10-31 16:26:23 +01:00
|
|
|
ramstage-$(CONFIG_REG_SCRIPT) += reg_script.c
|
|
|
|
|
2014-12-26 12:28:35 +01:00
|
|
|
romstage-$(CONFIG_RELOCATABLE_RAMSTAGE) += ramstage_cache.c
|
2013-10-11 03:37:04 +02:00
|
|
|
|
2014-11-11 02:22:04 +01:00
|
|
|
smm-y += cbfs.c cbfs_core.c memcmp.c
|
2014-06-26 10:12:11 +02:00
|
|
|
smm-$(CONFIG_COMPILER_GCC) += gcc.c
|
2010-03-29 15:04:13 +02:00
|
|
|
|
2014-11-18 11:41:16 +01:00
|
|
|
bootblock-y += version.c
|
|
|
|
romstage-y += version.c
|
|
|
|
ramstage-y += version.c
|
|
|
|
smm-y += version.c
|
|
|
|
|
|
|
|
$(obj)/lib/version.bootblock.o : $(obj)/build.h
|
|
|
|
$(obj)/lib/version.romstage.o : $(obj)/build.h
|
2010-09-30 18:55:02 +02:00
|
|
|
$(obj)/lib/version.ramstage.o : $(obj)/build.h
|
2014-11-18 11:41:16 +01:00
|
|
|
$(obj)/lib/version.smm.o : $(obj)/build.h
|
2011-07-30 00:34:14 +02:00
|
|
|
|
2013-11-28 17:11:49 +01:00
|
|
|
romstage-y += bootmode.c
|
|
|
|
ramstage-y += bootmode.c
|
|
|
|
|
2014-11-28 22:00:22 +01:00
|
|
|
bootblock-y += halt.c
|
|
|
|
romstage-y += halt.c
|
|
|
|
ramstage-y += halt.c
|
|
|
|
smm-y += halt.c
|
2014-08-27 00:39:51 +02:00
|
|
|
secmon-y += halt.c
|
2014-11-28 22:00:22 +01:00
|
|
|
|
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
|
|
|
ifneq ($(CONFIG_ARCH_X86),y)
|
|
|
|
# X86 bootblock and romstage use custom ldscripts that are all glued together,
|
|
|
|
# so we need to exclude it here or it would pick these up as well
|
|
|
|
bootblock-y += bootblock.ld
|
|
|
|
romstage-y += romstage.ld
|
|
|
|
endif
|
|
|
|
ramstage-y += ramstage.ld
|
|
|
|
|
2012-12-24 21:28:37 +01:00
|
|
|
ifeq ($(CONFIG_RELOCATABLE_MODULES),y)
|
|
|
|
ramstage-y += rmodule.c
|
2013-02-09 00:28:04 +01:00
|
|
|
romstage-$(CONFIG_RELOCATABLE_RAMSTAGE) += rmodule.c
|
2012-12-24 21:28:37 +01:00
|
|
|
|
2015-04-07 22:44:52 +02:00
|
|
|
RMODULE_LDFLAGS := -nostartfiles --gc-sections --emit-relocs -z defs -Bsymbolic
|
2012-12-24 21:28:37 +01:00
|
|
|
|
|
|
|
# rmodule_link_rules is a function that should be called with:
|
|
|
|
# (1) the object name to link
|
|
|
|
# (2) the dependencies
|
|
|
|
# (3) heap size of the relocatable module
|
2014-07-31 18:28:55 +02:00
|
|
|
# (4) arch for which the rmodules are to be linked
|
2014-03-10 22:13:58 +01:00
|
|
|
# It will create the necessary Make rules to create a rmodule. The resulting
|
|
|
|
# rmdoule is named $(1).rmod
|
2012-12-24 21:28:37 +01:00
|
|
|
define rmodule_link
|
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
|
|
|
$(strip $(1)): $(strip $(2)) $$(COMPILER_RT_rmodules_$(4)) $(obj)/lib/rmodule.rmodules_$(4).ld | $$(RMODTOOL)
|
2015-04-07 22:44:52 +02:00
|
|
|
$$(LD_rmodules_$(4)) $(RMODULE_LDFLAGS) -T $(obj)/lib/rmodule.rmodules_$(4).ld --defsym=__heap_size=$(strip $(3)) -o $$@ --start-group $(filter-out %.ld,$(2)) --end-group
|
2014-07-31 18:28:55 +02:00
|
|
|
$$(NM_rmodules_$(4)) -n $$@ > $$(basename $$@).map
|
2014-03-10 22:13:58 +01:00
|
|
|
|
|
|
|
$(strip $(1)).rmod: $(strip $(1))
|
|
|
|
$$(RMODTOOL) -i $$^ -o $$@
|
2012-12-24 21:28:37 +01:00
|
|
|
endef
|
|
|
|
|
|
|
|
endif
|