Rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names (bootblock, romstage) and to allow any
Makefile rule generalization, required for patches to be submitted later.
Change-Id: Ib66e43b7e17b9c48b2d099670ba7e7d857673386
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5567
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Other toolchains just don't cut it.
Change-Id: I7a0bdf60d89b5166c9a22c9e9f3f326b28f777b8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4584
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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)
Refactor Makefile build system as decompartmentalise armv7a and i386
targets from crossgcc.
Change-Id: If93f62050810ba594c9925a9eb8ba9d04bc76459
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4008
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4847
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On newer Intel systems, the flash ROM is shared between the host
processor (BIOS), it's Management Engine (ME) and an integrated ethernet
controller (GbE). The layout of the flash ROM (and other information) is
kept in the so called Intel Firmware Descriptor (IFD). If we only want
to build coreboot to update the BIOS section, all we need is the flash
layout.
This patch adds the option to specify the flash layout in the
mainboard's Kconfig, and thus, to build without the real IFD. However,
with such a build, one has to make sure that the IFD section on the
flash ROM won't be written over (nor any other section that hasn't been
included by coreboot). A patch to write selected sections of a flash ROM
with IFD has been sent to the flashrom mailing list [1].
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
Change-Id: Ia23e439a00a197fb54852263f8e206f16c3e8851
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3524
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add an rmodules class so that there are default rules for compiling
files that will be linked by the rmodule linker. Also, add a new type
for SIPI vectors.
Change-Id: Ided9e15577b34aff34dc23e5e16791c607caf399
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2751
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add support for SMM modules by leveraging the RMODULE lib. This allows
for easier dynamic SMM handler placement. The SMM module support
consists of a common stub which puts the executing CPU into protected
mode and calls into a pre-defined handler. This stub can then be used
for SMM relocation as well as the real SMM handler. For the relocation
one can call back into coreboot ramstage code to perform relocation in
C code.
The handler is essentially a copy of smihandler.c, but it drops the TSEG
differences. It also doesn't rely on the SMM revision as the cpu code
should know what processor it is supported.
Ideally the CONFIG_SMM_TSEG option could be removed once the existing
users of that option transitioned away from tseg_relocate() and
smi_get_tseg_base().
The generic SMI callbacks are now not marked as weak in the
declaration so that there aren't unlinked references. The handler
has default implementations of the generic SMI callbacks which are
marked as weak. If an external compilation module has a strong symbol
the linker will use that instead of the link one.
Additionally, the parameters to the generic callbacks are dropped as
they don't seem to be used directly. The SMM runtime can provide the
necessary support if needed.
Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2693
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The 'git describe' command is used to obtain the source tree status
information when building coreboot. As used this command expects git
tags to be defined, so it can report the discrepancy between the
current state of the tree and the latest tag.
The problem is that the coreboot source tree does not have any git
tags defined, so when 'git describe' is invoked, it reports "fatal: No
names found, cannot describe anything.". This scary message can be
seen on the console during coreboot builds.
The solution is to add --always to the `git describe' invocation,
which causes it to report the discrepancy with the latest sha1, if
any, which is better than nothing.
$ rm -rf /tmp/li && mkdir /tmp/li
$ cp configs/config.link .config
$ make obj=/tmp/li oldconfig
$ make obj=/tmp/li
$ grep COREBOOT_VERSION /tmp/li/build.h
#define COREBOOT_VERSION "1623c06"
$ echo '#' >> Makefile.inc
$ grep COREBOOT_VERSION /tmp/li/build.h
$ make obj=/tmp/li
#define COREBOOT_VERSION "1623c06-dirty"
$ git checkout Makefile.inc
Change-Id: Ia77428b7cd765cbbd59bdbf8251b7bef489d47a5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/2637
Tested-by: build bot (Jenkins)
REQUIRES_BLOB assumes that all blob files come from the 3rdparty directory,
builds failed when all files were configured to point to other sources.
This change modifies the blob mechanism so that cbfs-files can be tagged as
"required" with some specification what is missing.
If the configured files can't be found (wrong path, missing file), the build
system returns a list of descriptions, then aborts.
Change-Id: Icc128e3afcee8acf49bff9409b93af7769db3517
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2418
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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)
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>
It's too easy to forget this and it's kind of important, so Just Add It.
Change-Id: Ic7ab7658425a98d5d435bfef46f89cc6a56c7284
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2096
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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)
After collecting dependencies for ramstage, add an intermediate step
in which object files are linked per directory. The results are then
linked into the final binary.
This reduces the maximum command line length and might also help with
future use of LTO linking.
Also adapt the lint test for build dir handling, since printall
doesn't provide individual object files for ramstage anymore.
Change-Id: Ie40febd8c1eaf4609944eedeab46d870639e53df
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1911
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
With this change the the xcompile script now creates environment variables
for more than one architecture.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Change-Id: I349a1fd1d865ef16979f1dfd6aeca12b1ee2eed6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1915
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
If they come from the build system, file names might be guarded in
quotes, which confuses make. Drop them here.
Change-Id: Ice0d3c4bc2c45a3f121a85e1b9f5f6420c5761d5
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Right now coreboot's build process produces images that are
not booting on actual hardware because they are smaller than
the actual flash device and also don't have an IFD nor an ME
firmware in them. In order to produce bootable images, you
needed a wrapper script / extra step until now. With this
change, the resulting coreboot.rom is actually bootable.
Change-Id: I82714069fb004d4badc41698747a704bd9fed4da
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1771
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Adding more and more optional and non-optional parameters
bloated cbfstool and made the code hard to read with a lot
of parsing in the actual cbfs handling functions. This change
switches over to use getopt style options for everything but
command and cbfs file name.
- This allows us to simplify the coreboot Makefiles a bit
- Also, add guards to include files
- Fix some 80+ character lines
- Add more detailed error reporting
- Free memory we're allocating
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7
Reviewed-on: http://review.coreboot.org/1800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
http://netbsd.gw.com/cgi-bin/man-cgi?date++NetBSD-current
The NetBSD manual tells us the date in NetBSD doesn't take any flags
to enable or disable padding in the format.
By default, date pads numeric fields with zeroes. This will convert the
number to octal one. So add "0x" to convert it to BCD directly.
Change-Id: Icd44312acf01b8232f1da1fbaa70630d09007b40
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1804
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The range of weekday in CMOS is 01-07, while the Sunday is 1, and
Saturday is 7. The comand date in coreutils defines
%u day of week (1..7); 1 is Monday
%w day of week (0..6); 0 is Sunday
There are 1 day offset for each week day. So we use "%w" and plus 1
before we update the weekday in CMOS.
Change-Id: I3fab4e95f04924ff0ba10a7012b57da1d3f0d1a5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1802
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Otherwise object paths will look like build/cbfs/"fallback"/...
Change-Id: I3e60f90f7490e71b0da075d3ea8fc847abc07938
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1700
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
When a power failure happens on the RTC rail, the CMOS memory (including
the RTC registers) is filled with garbage.
So, we erase the full first bank (112 bytes) and we reset the RTC date
to the build date.
To test, disconnect the CMOS battery to produce an RTC power
failure, then boot the machine and observe the RTC date is the build
date using "cat /sys/class/rtc/rtc0/date"
Change-Id: I684bb3ad5079f96825555d4ed84dc0f7914e9884
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1697
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Change-Id: Id5564bf7a12b3ea9a5e60bd9522466157ace8c65
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1601
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In some cases we request mktemp to create a temporary file in
$(obj)/mainboard/... before it exists.
Let's make sure the directory exists
Change-Id: I51f0065c30b1f25eb501a6fd5edefb3f4c15d0ab
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1532
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Cygwin's hostname comes from coreutils, which does not support all
the options that some other hostname implementations provide.
Change-Id: Ia6bd9157c351f440ad225046638a6bf3f9cfba11
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1546
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Change-Id: I86cecf6aee1fcb682cb32bd0f03e014fd1afe594
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1549
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Change-Id: Ie77e8e1628d34f1a9e7a57e994bf2882c5e55e25
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1452
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Old rev (1.6.6, in my case) git-describe doesn't take the --dirty and says error.
Remove the --dirty at second try.
Change-Id: Id6c6f9889ab20fb7c2b238f8c0bbe20134757369
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1261
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Determine if xargs -P works. If yes, use that to build multiple
boards in parallel, instead of relying on make -j X, when doing
a full abuild run (instead of single boards).
make -j X isn't able to make use of several cores at various
serialization points in our build process, so this change results
in a >25% speed up for a full abuild run in my tests.
Change-Id: Id484a4211c84a3a24115278e0fbe92345f346596
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/409
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change is taken from Linux. It allows to check for Kconfig
definitions in the preprocessor and source code using the same
idiom.
Long term plan is to remove our Kconfig hack to #define values to 0,
and this helps.
This includes a tiny modification to the macros to fix romcc support.
Change-Id: I0fddbea8c8ca215cf226acf39cb329b0ba0445a5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1005
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
One option to allow using the repo (defaults to no),
one to let boards state that they require it in the
current configuration.
The build system checks out the repo if allowed, and
fails if the repo is requested by the configuration
but not desired by the user.
Change-Id: If71d80b329cf528aa467fcb0b4d9d7c7434aab27
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/957
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
There is no reason for this to be a top level directory.
Some stuff from lib/ should also be moved to drivers/
Change-Id: I3c2d2e127f7215eadead029cfc7442c22b26814a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/939
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Final build results (.elf, .debug, .map) are to be placed under
directory $(objcbfs), the default is:
$(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/
Intermediate build results (.o, .s, .S, .inc, .ld) that do not have
a clear one-to-one relation to a file under src/ are to be placed
under directory $(objgenerated), the default is:
$(obj)/generated
Also defines implicit rules for final build results:
.debug -> .elf and .map
.elf -> .bin
Change-Id: I448c6b7c9a952e54170df42091d7db438025a795
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/858
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Traditionally coreboot's SMM handler runs in ASEG (0xa0000),
"behind" the graphics memory. This approach has two issues:
- It limits the possible size of the SMM handler (and the
number of CPUs supported in a system)
- It's not considered a supported path anymore in newer CPUs.
Change-Id: I9f2877e46873ab2ea8f1157ead4bc644a50be19e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Acked-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/842
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
It's now possible to generate files that are about to be added to
CBFS by specifying "sourcefile:method" as real file name.
This makes the build system use the cbfs-files-preprocessor-$(method)
function to create a file from sourcefile. That generated file is
then added to CBFS.
The first method to be defined is "nvramtool". It expects a plain text
specification of the CMOS configuration and emits the binary format
suitable for cmos.default.
Change-Id: I33a142718fc7238eaf5317b0ed62b4726d9b48f2
Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/847
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This way we can depend on it during build.
Change-Id: I7e773c6a029e376e3d70d0a8c9e96ffe0c2cf82e
Signed-off-by: Patrick Georgi <Patrick.Georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/845
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Google's ChromeOS can be booted super fast and safely
using coreboot. This adds the ChromeOS specific code that
is required by all ChromeBooks to do this.
Change-Id: Ic03ff090a569a27acbd798ce1e5f89a34897a2f2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/817
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The coreboot makefile didn't pass the OUT and CC variables to seabios,
so the clean didn't clean anything.
Change-Id: Ieaf0c417d6e5dfb9e0a11df70b03d6313919578b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/801
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Makefile.inc uses $( ) syntax on the shell. That's isn't as universal
as one would like.
Change-Id: I9a8fd511eef7fefc1458d5bae2cd7ef5475b7392
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/777
Tested-by: build bot (Jenkins)
Reviewed-by: Bernhard Urban <lewurm@gmail.com>
Furquan Shaikh