Dependency tracking in incremental builds is currently broken for the
ramstage, due to the intermediate linking step into one ramstage.o file
per directory. The original xxx.ramstage.o files are removed from
ramstage-objs, so they don't end up in allobjs and won't get translated
into DEPENDENCIES. This patch explicitly adds them to DEPENDENCIES
beforehand to resolve the issue.
BRANCH=None
BUG=None
TEST=Built, ran 'touch src/include/cbmem.h' and built again
incrementally. Confirmed that objects dependent on the modified header
such as timestamp.ramstage.o get rebuilt correctly.
Change-Id: Ife529ad8f5c011456c1e0c380356f1b1bb5047cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233571
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229974
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These allow to define a kernel image, initrd and command line.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia07b08b4cf385b17dc85f779cc7583db354bf99b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3893
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/222624
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
With introduction of GDB support the GDB_DEBUG make parameter sounds
misleading. Let's change it to SOURCE_DEBUG. It is still quite useful
when debugging with GDB, but can be used with any debugger.
BUG=None
TEST=built coreboot with SOURCE_DEBUG in the environment, observed it
compiled as expected
Change-Id: Ia6cfddfa1764fb070f4d35f374ed4f35e38d38fe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221386
Reviewed-by: Julius Werner <jwerner@chromium.org>
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: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213370
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provided finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch started out as an attempt to run linker scripts through the
preprocessor. However, since that required some more infrastructure
changes, the build system is so intertwined, and there are so many other
small issues that turned up and are easier to fix (and get running, and
test thoroughly) in a single go, it turned out a little bigger. In order
of appearance, it:
- wraps direct linker invocations in a macro to avoid the widespread
ifeq($(CONFIG_COMPILER_LLVM_CLANG),y) duplication.
- introduces an $(generic-deps) (equivalent to $(<class>-deps)) variable
for targets that all files depend on
- makes the $(src-to-obj) function usable in multiple places as the
authoritative way to get an output file name (even if the respective
source file is also under build/), and makes it preserve extensions on
everything except %.c and %.S (e.g. %.ld and %.asl)
- replaces the old $(<class>-postprocess) with a single
$(postprocessors) variable. The old ramstage-postprocess was weird
because it contained unescaped $(eval ...)s, meaning it gets executed
as soon as the variable is first substituted (and the other
$(eval ...) in the toplevel Makefile does essentially nothing). The
new mechanism is just $(eval ...)ed directly after the recursive parse
with no further magic. Files can freely append their own (escaped)
content to it and access variables valid in the calling context (like
$(<class>-objs)) directly.
- enhances the existing $(<class>-<type>-ccopts) mechanism with
$(<class>-generic-ccopts) and $(generic-<type>-ccopts) to reduce
duplication.
- makes .ld a type that can be added like a normal class file, causing
it to be preprocessed with the correct #defines for the current class
(needed for a follow-up feature). Migrates all linker scripts to this
mechanism, which allows us to get rid of the weird $(ldoptions)
mechanism (Kconfigs are replaced by preprocessor and no longer need to
be defined as symbols).
- removes duplicate $(INCLUDES) from $(CFLAGS)
- repairs the crazy state of MIPS Makefiles, which seem to have been
copied together from X86 despite having absolutely nothing in common
with that architecture. They were using the same code to paste
assembly pieces and linker scripts together without really needing it
for anything, and even accidentally relied on a Kconfig default set
in the arch/x86 subdirectory (I wish I was kidding). Changed them to
work equivalent to the arm/arm64 Makefiles which are far closer
related (also being SRAM-based platforms).
- moves the x86-specifc $(OPTION_TABLES_H) into the x86 Makefile.inc and
fixes an rule that would've had an empty target if it wasn't defined
- removes the custom ldscript-gathering variables for x86 bootblock and
romstage. The Makefile simply combines all .ld files that have been
added to the respective class now.
- uses the normal class build system to replace some of the custom rules
for autogenerated bootblock/crt0 files on x86, and removes some
hardcoded flags by using the normal $(...-ccopts) variables.
- moves the handling of .asl files from the global Makefile.inc to x86.
Changed to reuse the generic template for the preprocessing and C
compilation steps.
- removed the extra <name>.o linking step before linking an rmodule for
modules that don't require special linker flags (most of them).
- removes the incorrect assumption that there was a global $(LDFLAGS)
from the SMM Makefile.inc (it was named $(LDFLAGFS in one place so it
couldn't have been all that important ;) ).
- allow -j flag for parallel builds to be properly passed through to
vboot child invocation by using special $(MAKE) variable.
BUG=None
TEST=Built for Falco, Nyan_Blaze, Stout, Rush_Ryu and Urara. Binary
diffed old and new coreboot.rom (and some manually uncompressed stages),
confirmed that images/stages are byte-for-byte identical except for some
embedded timestamps and commit hashes. (Addresses in Falco/Stout
ramstages shifting slightly due to different link order for ASL object
files within their directory. Some addresses in Urara ramstage .rodata
and some relocation entries in rmodules moved around due to linking them
in fewer steps.)
Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214371
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Reviewed-on: https://chromium-review.googlesource.com/212365
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new utility named bimgtool, a simple tool which generates boot
images in the BIMG format. This is the format the Danube boot ROM
expects the user supplied code to be wrapped in, it is described by
struct bimg_header in the code.
This utility will be used to wrap the coreboot bootblock when building
Danube targets.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I63b9f5e09cd1f12765317b38e2a0dd033cdd6d39
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207975
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the build infrastructure and basic architectural support required
to build for targets using the MIPS architecture. This is sufficient
to run on a simulator, but will require the addition of some cache
maintenance and timer setup in order to run on real hardware.
BUG=chrome-os-partner:31438, chromium:409082
TEST=none yet
Change-Id: If4f99554463bd3760fc142477440326fd16c67cc
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207972
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide functionality to create dynamic classes based on program name and the
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 and 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.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The ROMSTAGE_ELF variable is assigned based upon the architecture the
romstage is being built for. x86 uses a unique value but arm & arm64
both use the same value which MIPS will also share. Remove the
duplication of the assignment by special casing x86 only.
Change-Id: Id4307c30d91fde8dc48f89b2eb6f5b16b45e0c67
Suggested-by: Vadim Bendebury <vbendeb@google.com>
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/208932
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Reviewed-on: https://chromium-review.googlesource.com/204376
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
BUG=None
BRANCH=None
TEST=Compiled successfully for rush board with bootblock being armv4 and
romstage and ramstage being armv8
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Image booted
successfully on link, rambi and nyan.
Change-Id: I10d36ff950712756fb16dcb4d315924d177846b5
Reviewed-on: https://chromium-review.googlesource.com/195574
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Remove all the common Makefile rules like coreboot.pre, coreboot.pre1 and others
from arch level Makefile.inc to top level Makefile.inc.
Also, organize Makefile.inc at arch level into per-stage rules and variables.
BUG=None
BRANCH=None
TEST=Compiled successfully. Image booted successfully on link,nyan and rambi.
Change-Id: I22f5ef692b740f84d73071534732286e809f3bc4
Reviewed-on: https://chromium-review.googlesource.com/195446
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to 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)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
When preparing an image for source level debugging, it is convenient
to be able to compile some modules with -O0, which makes it much
easier to follow the execution flow.
This patch allows to do it by defining GDB_DEBUG=1 in the environment
before invoking make. Adding this feature as a common config flag is
problematic, because we don't want to compile the entire image with
-O0.
BUG=none
TEST=manual
. ran make with GDB_DEBUG=1 and observed the modified compiler
invocation line in the log.
Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196359
There are special rules which build the static.c files because they come from
$(obj) and not $(src) like most source files, and its apparently the most
straightforward way to fold them into the build. Those special copies of the
rules didn't have the $(class)-c-ccopts variables in them, though, so that
one file for each class would be compiled with different flags. This change
adds that variable in so the special version of the rules match the normal
version.
BUG=chrome-os-partner:23009
TEST=Built for pit, snow, nyan, link, and falco.
BRANCH=None
Change-Id: Ie637118d433a0a43a6a9d2c8b9ecb92155044546
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171339
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The class flags are more specific than the generic CFLAGS flags and should be
after them so that they have a chance to override them. The class specific
flags weren't really used on anything but ARM so this should be a fairly safe
change even in the x86 Makefiles.
BUG=None
TEST=Built for link. Built and booted on nyan.
BRANCH=None
Change-Id: I7a949efbb1d2841f9f0d28433772092d9f95db36
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171016
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This makes sure that GCC still finds assembler functions when
using link time optimization.
BRANCH=none
BUG=none
TEST=boot tested on pit and link
Change-Id: If9cb32abf19c17c09bb1f25ca496e963e4ce82f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168774
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
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>
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>
