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

126 lines
4.0 KiB
PHP
Raw Normal View History

src/lib/Makefile.inc: Add license header Change-Id: If8bce4ebde9101ac9087fcbd43adc0e08c26352d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/1957 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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
GPLv2 notice: Unify all files to just use one space in »MA 02110-1301« In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-23 18:37:27 +01:00
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
src/lib/Makefile.inc: Add license header Change-Id: If8bce4ebde9101ac9087fcbd43adc0e08c26352d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/1957 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30 21:19:59 +01:00
#
coreboot: infrastructure for different ramstage loaders There are 2 methods currently available in coreboot to load ramstage from romstage: cbfs and vboot. The vboot path had to be explicitly enabled and code needed to be added to each chipset to support both. Additionally, many of the paths were duplicated between the two. An additional complication is the presence of having a relocatable ramstage which creates another path with duplication. To rectify this situation provide a common API through the use of a callback to load the ramstage. The rest of the existing logic to handle all the various cases is put in a common place. Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5087 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-01-31 00:19:46 +01:00
subdirs-y += loaders
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
armv7: Add 'bootblock' build class. For ARM platform, the bootblock may need more C source files to initialize UART / SPI for loading romstage. To preventing making complex and implicit dependency by using #include inside bootblock.c, we should add a new build class "bootblock". Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled for boot block. For x86, the bootblock is limited to fewer assembly files so it's not using this class. (Some files shared by x86 and arm in top level or lib are also changed but nothing should be changed in x86 build process.) Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2252 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-01-31 18:09:24 +01:00
bootblock-y += cbfs.c
bootblock-y += memchr.c
bootblock-y += memcmp.c
Add an implementation for the memchr library function Change-Id: Icded479d246f7cce8a3d2154c69f75178fa513e1 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/708 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Mathias Krause <minipli@googlemail.com>
2011-09-16 11:18:56 +02:00
romstage-y += memchr.c
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
romstage-y += memcmp.c
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
$(foreach arch,$(ARCH_SUPPORTED),\
$(eval rmodules_$(arch)-y += memcmp.c))
delay: Have mdelay() / delay() available in romstage, too Some drivers (like the I2C TPM driver) call mdelay instead of udelay. While it's a shame that these chips are so slow, the overhead of having those functions available in romstage is minimal. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792 Reviewed-on: https://chromium-review.googlesource.com/167542 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 7083b6b843d803bd4ddbd8a5aaf9c5c05bad2044) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6531 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-30 01:01:05 +02:00
romstage-$(CONFIG_I2C_TPM) += delay.c
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
romstage-y += cbfs.c
Don't include LZMA in romstage if ramstage is not compressed. If ramstage is not compressed, the CBFS module in romstage doesn't need to support LZMA. Removing the LZMA module in this case can save about 3000 bytes in romstage. Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3878 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-19 05:43:36 +02:00
romstage-$(CONFIG_COMPRESS_RAMSTAGE) += lzma.c
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
#romstage-y += lzmadecode.c
romstage-$(CONFIG_CACHE_AS_RAM) += ramtest.c
spkmodem console Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2987 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-30 02:02:13 +01:00
Revert "CBMEM: Always have early initialisation" This reverts commit de1fe7f655c549e8dce5b34218221890fa5ccc34. While things appeared to work, there were actually invalid references to CAR storage after CAR was torn down on boards without EARLY_CBMEM_INIT. It was discussed use of CAR_GLOBAL should be restricted to boards that handle CAR migration properly. Change-Id: I9969d2ea79c334a7f95a0dbb7c78065720e6ccae Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3968 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-10-11 21:08:02 +02:00
ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
dynamic cbmem: fix memconsole and timestamps There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM rely on EARLY_CBMEM_INIT. This isn't true in the face of DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT. Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem implementation when COLLECT_TIMESTAMPS is selected. Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2895 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 06:00:54 +01:00
romstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c
ROMCC boards: Fix builds with CBMEM console, timestamps or usbdebug These features depend on CAR_GLOBAL region, which is not available when romstage is built with ROMCC. Exclude these from romstage, keep them available for ramstage. A follow-up patch will fix the dependencies and allows enabling these features in menuconfig. Change-Id: I9de5ad41ea733655a3fbdc734646f818e39cc471 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3919 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-10 12:50:32 +02:00
romstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
endif
Dynamic cbmem: don't compile src/lib/cbmem.c when dynamic cbmem is selected. src/lib/cbmem.c is for the static cbmem. Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode: <adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled [...] <adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y) <adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c <adurbin> +endif <adurbin> +endif Without that fix we have: src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes] src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes] src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes] This commit was tested on qemu-i440fx with the following commit: qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM ( http://review.coreboot.org/#/c/3504/ ). Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3503 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-06-20 16:24:14 +02:00
Use fast memset in SMM mode, too ... and always include IP checksumming in romstage. It's generally useful and our upcoming port needs it. Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/827 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-31 01:28:20 +02:00
romstage-y += compute_ip_checksum.c
build: Drop libgcc runtime wrapper in Clang builds This GCC specific workaround of wrapping of libgcc runtime symbols with gcc.c is not nessary with libcompiler-rt linkage. Change-Id: I50a2bc99d97f68a2ad2b51a92ea0e7086bab35fe Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5812 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-22 17:29:00 +02:00
ifneq ($(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
romstage-$(CONFIG_ARCH_ROMSTAGE_X86_32) += gcc.c
build: Drop libgcc runtime wrapper in Clang builds This GCC specific workaround of wrapping of libgcc runtime symbols with gcc.c is not nessary with libcompiler-rt linkage. Change-Id: I50a2bc99d97f68a2ad2b51a92ea0e7086bab35fe Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5812 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-22 17:29:00 +02:00
ramstage-$(CONFIG_ARCH_RAMSTAGE_X86_32) += gcc.c
endif
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
Drop boot directory It only has two files, move them to src/lib Change-Id: I17943db4c455aa3a934db1cf56e56e89c009679f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1959 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-11-30 21:23:45 +01:00
ramstage-y += hardwaremain.c
ramstage-y += selfboot.c
Unify coreboot table generation coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-20 22:08:04 +01:00
ramstage-y += coreboot_table.c
coreboot: introduce notion of bootmem for memory map at boot The write_coreboot_table() in coreboot_table.c was already using struct memrange for managing and building up the entries that eventually go into the lb_memory table. Abstract that concept out to a bootmem memory map. The bootmem concept can then be used as a basis for loading payloads, for example. Change-Id: I7edbbca6bbd0568f658fde39ca93b126cab88367 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5302 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-02-19 04:55:02 +01:00
ramstage-y += bootmem.c
Add an implementation for the memchr library function Change-Id: Icded479d246f7cce8a3d2154c69f75178fa513e1 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/708 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Mathias Krause <minipli@googlemail.com>
2011-09-16 11:18:56 +02:00
ramstage-y += memchr.c
Rename build system variables to be more intuitive, and at the same time let the user specify sources instead of object files: - objs becomes ramstage-srcs - initobjs becomes romstage-srcs - driver becomes driver-srcs - smmobj becomes smm-srcs The user servicable parts are named accordingly: ramstage-y, romstage-y, driver-y, smm-y Also, the object file names are properly renamed now, using .ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently. Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't easily fit in the build system and aren't useful anyway. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coreystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-09-30 18:55:02 +02:00
ramstage-y += memcmp.c
ramstage-y += malloc.c
SMM: Add support for malloc in SMM if using TSEG This is used by the SPI driver and ELOG. It requires SMM TSEG and a _heap/_eheap region defined in the linker script. The first time malloc is called in SMM the start and end pointers to the heap region will be relocated for the TSEG region. Enable SPI flash and ELOG in SMM and successfully allocate memory. The allocated addresses are verified to be sure they are within the TSEG heap region: smm.elf:00014000 B _eheap smm.elf:00010000 B _heap TSEG base is 0xad000000 Memory allocated in ELOG: ELOG: MEM @0xad018030 Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1312 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-06-23 22:33:32 +02:00
smm-$(CONFIG_SMM_TSEG) += malloc.c
Rename build system variables to be more intuitive, and at the same time let the user specify sources instead of object files: - objs becomes ramstage-srcs - initobjs becomes romstage-srcs - driver becomes driver-srcs - smmobj becomes smm-srcs The user servicable parts are named accordingly: ramstage-y, romstage-y, driver-y, smm-y Also, the object file names are properly renamed now, using .ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently. Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't easily fit in the build system and aren't useful anyway. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coreystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-09-30 18:55:02 +02:00
ramstage-y += delay.c
ramstage-y += fallback_boot.c
ramstage-y += compute_ip_checksum.c
ramstage-y += version.c
ramstage-y += cbfs.c
ramstage-y += lzma.c
#ramstage-y += lzmadecode.c
Implement stack overflow checking for the BSP Previous patches implemented stack overflow checking for the APs. This patch builds on the BSP stack poisoning patch to implement stack overflow checking for the BSP, and also prints out maximum stack usage. It reveals that our 32K stack is ridiculously oversized, especially now that the lzma decoder doesn't use a giant 16K on-stack array. Break the stack checking out into a separate function, which we will later use for the APs. CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 To test failure, change the DEADBEEF stack poison value in c_start.S to something else. Then we should get an error like this: Stack overrun on BSP.Increase stack from current 32768 bytes CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000 Separate the act of loading from the act of starting the payload. This allows us better error management and reporting of stack use. Now we see: CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 Tested for both success and failure on Link. At the same time, feel free to carefully check my manipulation of _estack. Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1286 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-06-13 01:29:32 +02:00
ramstage-y += stack.c
drop half an uart8250 implementation from smiutil and use the common code for that instead. This also allows using non-uart8250 consoles for smi debugging. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-15 00:28:00 +02:00
ramstage-y += clog2.c
lib: Make log2() available in romstage on ARM, not just x86 On x86, log2() is defined as an inline function in arch/io.h. This is a remnant of ROMCC, and forced us to not include clog2.c in romstage. As a result, romstage on ARM has no log2(). Use the inline log2 only with ROMCC, but otherwise, use the one in clog2.c. Change-Id: Ifef2aa0a7b5a1db071a66f2eec0be421b8b2a56d Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/4681 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-12 22:42:58 +01:00
romstage-y += clog2.c
CBMEM CONSOLE: Enable coreboot CBMEM console. The appropriate Makefiles are modified to include the required source code in compilation. Change-Id: I91842b1ba0f89d611d3249b63c020a2713a9124f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/722 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-09-30 21:02:18 +02:00
ramstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c
Rename build system variables to be more intuitive, and at the same time let the user specify sources instead of object files: - objs becomes ramstage-srcs - initobjs becomes romstage-srcs - driver becomes driver-srcs - smmobj becomes smm-srcs The user servicable parts are named accordingly: ramstage-y, romstage-y, driver-y, smm-y Also, the object file names are properly renamed now, using .ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently. Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't easily fit in the build system and aren't useful anyway. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coreystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-09-30 18:55:02 +02:00
ramstage-$(CONFIG_BOOTSPLASH) += jpeg.c
Add support for the tracing infastructure in coreboot. The compiler is forced to emmit special functions on every entry/exit of the function. Add a compile time option to support it. Function entries will be printed in the console. The CONFIG_TRACE has more documentation. Patch for userspace tools will follow. Change-Id: I2cbeb3f104892b034c8756f86ed05bf71187c3f3 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/178 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-09-02 23:23:41 +02:00
ramstage-$(CONFIG_TRACE) += trace.c
Add timestamp collecting to coreboot. This patch adds code to initialize the time stamp collection facility in coreboot. It adds a table in the CBMEM section, which provides the base timer reading value (all other readings are offsets of this one) and an array of timestamp id/timestamp value pairs. Just two values are being added now, this will have to be used more extensively and also integrated into payloads to provide more comprehensive boot process time measurements. Also, since the CBMEM area could already contain a section (from the previous run, before reset), when processing a section addition request we should check if a section already exists and return its address, if so. Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/713 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
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
link/graphics: Add support for EDID This code is taken from an EDID reader written at Red Hat. The key function is int decode_edid(unsigned char *edid, int size, struct edid *out) Which takes a pointer to an EDID blob, and a size, and decodes it into a machine-independent format in out, which may be used for driving chipsets. The EDID blob might come for IO, or a compiled-in EDID BLOB, or CBFS. Also included are the changes needed to use the EDID code on Link. Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-13 22:35:01 +01:00
ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += edid.c
lib: add memrange infrastructure The memrange infrastructure allows for keeping track of the machine's physical address space. Each memory_range entry in a memory_ranges structure can be tagged with an arbitrary value. It supports merging and deleting ranges as well as filling in holes in the address space with a particular tag. The memrange infrastructure will serve as a shared implementation for address tracking by the MTRR and coreboot mem table code. Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 02:44:46 +01:00
ramstage-y += memrange.c
coreboot: add thread cooperative multitasking The cooperative multitasking support allows the boot state machine to be ran cooperatively with other threads of work. The main thread still continues to run the boot state machine (src/lib/hardwaremain.c). All callbacks from the state machine are still ran synchronously from within the main thread's context. Without any other code added the only change to the boot sequence when cooperative multitasking is enabled is the queueing of an idlle thread. The idle thread is responsible for ensuring progress is made by calling timer callbacks. The main thread can yield to any other threads in the system. That means that anyone that spins up a thread must ensure no shared resources are used from 2 or more execution contexts. The support is originally intentioned to allow for long work itesm with busy loops to occur in parallel during a boot. Note that the intention on when to yield a thread will be on calls to udelay(). Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3206 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-06 19:20:52 +02:00
ramstage-$(CONFIG_COOP_MULTITASKING) += thread.c
coreboot: add timer queue implementation A timer queue provides the mechanism for calling functions in the future by way of a callback. It utilizes the MONOTONIC_TIMER to track time through the boot. The implementation is a min-heap for keeping track of the next-to-expire callback. Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3158 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30 16:58:12 +02:00
ramstage-$(CONFIG_TIMER_QUEUE) += timer_queue.c
YABEL update - drop x86emu + old biosemu in favor of YABEL - Add YABEL_DIRECTHW to get the old biosemu behavior - add support for vesa console using YABEL - add coreboot table entry with console information - add bootsplash support (reads /bootsplash.jpg from CBFS) Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Pattrick Hueper <phueper@hueper.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5135 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-02-22 05:33:13 +01:00
cbmem: dynamic cbmem support This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13 18:41:44 +01:00
# The CBMEM implementations are chosen based on CONFIG_DYNAMIC_CBMEM.
ifeq ($(CONFIG_DYNAMIC_CBMEM),y)
ramstage-y += dynamic_cbmem.c
romstage-y += dynamic_cbmem.c
else
ramstage-y += cbmem.c
Revert "CBMEM: Always have early initialisation" This reverts commit de1fe7f655c549e8dce5b34218221890fa5ccc34. While things appeared to work, there were actually invalid references to CAR storage after CAR was torn down on boards without EARLY_CBMEM_INIT. It was discussed use of CAR_GLOBAL should be restricted to boards that handle CAR migration properly. Change-Id: I9969d2ea79c334a7f95a0dbb7c78065720e6ccae Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3968 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-10-11 21:08:02 +02:00
romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c
Static CBMEM / CAR: Flag boards with BROKEN_CAR_MIGRATE Use of CAR_GLOBAL is not safe after CAR is torn down, unless the board properly implements EARLY_CBMEM_INIT. Flag vulnerable boards that only do cbmem_recovery() in romstage on S3 resume and implementation with Intel FSP that invalidates cache before we have a chance to copy the contents. Change-Id: Iecd10dee9b73ab3f1f66826950fa0945675ff39f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5419 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-03-28 22:46:45 +01:00
romstage-$(CONFIG_BROKEN_CAR_MIGRATE) += cbmem.c
cbmem: dynamic cbmem support This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13 18:41:44 +01:00
endif # CONFIG_DYNAMIC_CBMEM
ramstage-y += cbmem_info.c
Add simple hexdump function - prints hex and ascii - detects duplicate all zero lines Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/62655 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/4392 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-07-19 01:24:08 +02:00
ramstage-y += hexdump.c
romstage-y += hexdump.c
reg_script: include in romstage The new broadwell support uses the reg_script functions in romstage. Change-Id: Ic040bf947d35854711f4c1547858b0e4378ef759 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7003 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-10-01 19:50:20 +02:00
romstage-$(CONFIG_REG_SCRIPT) += reg_script.c
Add a generic register script handler This is based on the RCBA configuration setup from haswell. It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF. I did not extend it to handle MSR yet but that would be another potential register type. There are a number of approaches to this kind of thing, but in the end they have a lot of switch statements and a mass of #defines. I'm not particularly set on any of the details so comments welcome. BUG=chrome-os-partner:23635 BRANCH=rambi TEST=emerge-rambi chromeos-coreboot-rambi Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175206 Commit-Queue: Aaron Durbin <adurbin@chromium.org> Tested-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4923 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-31 16:26:23 +01:00
ramstage-$(CONFIG_REG_SCRIPT) += reg_script.c
coreboot: config to cache ramstage outside CBMEM Haswell was the original chipset to store the cache in another area besides CBMEM. However, it was specific to the implementation. Instead, provide a generic way to obtain the location of the ramstage cache. This option is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM Kconfig option. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built and booted with baytrail support. Also built for falco successfully. Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172602 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4876 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-11 03:37:04 +02:00
romstage-$(CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM) += ramstage_cache.c
Use fast memset in SMM mode, too ... and always include IP checksumming in romstage. It's generally useful and our upcoming port needs it. Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/827 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-31 01:28:20 +02:00
smm-y += cbfs.c memcmp.c
lib/Makefile.inc: Stop gcc.c getting into SMM clang builds The libgcc runtime workarounds found in gcc.c are not needed for compiler-rt used by the Clang toolchain. Stop gcc.c from sneaking into Clang builds while processing boards that use SMM code. Change-Id: I51e8d517784721d28b4d951bd0bebc8b52682a8e Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6121 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-06-26 10:12:11 +02:00
smm-$(CONFIG_COMPILER_GCC) += gcc.c
This patch fixes build.h dependencies in coreboot again. -include was dropped, the files in question do an #include <build.h> already. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5310 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-29 15:04:13 +02:00
Rename build system variables to be more intuitive, and at the same time let the user specify sources instead of object files: - objs becomes ramstage-srcs - initobjs becomes romstage-srcs - driver becomes driver-srcs - smmobj becomes smm-srcs The user servicable parts are named accordingly: ramstage-y, romstage-y, driver-y, smm-y Also, the object file names are properly renamed now, using .ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently. Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't easily fit in the build system and aren't useful anyway. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coreystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-09-30 18:55:02 +02:00
$(obj)/lib/version.ramstage.o : $(obj)/build.h
Fix compilation with CONFIG_USE_OPTION_TABLE enabled Change-Id: I6c5d973442bc1770702180a8964f1bf6ed6062ed Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/696 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-07-30 00:34:14 +02:00
Declare recovery and developer modes outside ChromeOS Move the implementation for recovery and developer modes from vendorcode/google/chromes to lib/. Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4308 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-11-28 17:11:49 +01:00
romstage-y += bootmode.c
ramstage-y += bootmode.c
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
ifeq ($(CONFIG_RELOCATABLE_MODULES),y)
ramstage-y += rmodule.c
coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGE This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-02-09 00:28:04 +01:00
romstage-$(CONFIG_RELOCATABLE_RAMSTAGE) += rmodule.c
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
RMODULE_LDSCRIPT := $(src)/lib/rmodule.ld
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
RMODULE_LDFLAGS := -nostartfiles -Wl,--emit-relocs -Wl,-z,defs -Wl,-Bsymbolic -Wl,-T,$(RMODULE_LDSCRIPT)
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
# (4) arch for which the rmodules are to be linked
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
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
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
define rmodule_link
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
$(strip $(1)): $(strip $(2)) $$(RMODULE_LDSCRIPT) $$(obj)/ldoptions $$(RMODTOOL)
coreboot classes: Add dynamic classes to coreboot Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-07-31 18:28:55 +02:00
$$(CC_rmodules_$(4)) $$(CFLAGS_rmodules_$(4)) $$(RMODULE_LDFLAGS) -Wl,--defsym=__heap_size=$(strip $(3)) -o $$@ -Wl,--start-group $(strip $(2)) $$(LIBGCC_FILE_NAME_rmodules_$(4)) -Wl,--end-group
$$(NM_rmodules_$(4)) -n $$@ > $$(basename $$@).map
rmodules: use rmodtool to create rmodules Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-10 22:13:58 +01:00
$(strip $(1)).rmod: $(strip $(1))
$$(RMODTOOL) -i $$^ -o $$@
lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-24 21:28:37 +01:00
endef
endif