In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using x86 RDRAND instruction, two functions are supplied to
generate a 32bit or 64bit number.
One potential usage is the sealing key generation for SGX.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve to generate a 64bit random number.
Change-Id: I50cbeda4de17ccf2fc5efc1fe04f6b1a31ec268c
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-on: https://review.coreboot.org/18362
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, the only supported DSM type is I2C
HID(3CDFF6F7-4267-4555-AD05-B30A3D8938DE). This provides the required
callbacks for generating ACPI AML codes for different function
identifiers for I2C HID.
BUG=chrome-os-partner:57846
Change-Id: Ia403e11f7ce4824956e3c879547ec927478db7b1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The console_init(), MTRR printing, and loading ramstage
logic was previously all in assembly. Move that logic
into C code so that future features can more easily be
added into the postcar boot flow.
BUG=chrome-os-partner:57513
Change-Id: I332140f569caf0803570fd635d894295de8c0018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16618
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
postcar_loader.c has a useful library of funtions for
setting up stack and MTRRs. Make it available in romstage
irrespective of CONFIG_POSTCAR_STAGE for use in stack setup
after Dram init.
The final step of moving the used and max MTRRs on to stack
is moved to a new function, that can be used outside of
postcar phase.
Change-Id: I322b12577d74268d03fe42a9744648763693cddd
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Quark does not support the rdmsr and wrmsr instructions. Use SOC
specific routines to configure the MTRRs on Quark based platforms.
Add cpu_common.c as a build dependency to provide access to the routine
cpu_phys_address_size.
TEST=Build and run on Galileo Gen2
Change-Id: I43b7067c66c5c55b42097937e862078adf17fb19
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15846
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Place a map file for the postcar stage and place it into
build/cbfs/fallback.
TEST=Build and run on Galileo Gen2
Change-Id: I349c06e3c610db5b3f2511083208db27110c34d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15845
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the ramstage files to the beginning of the section. Eliminate
duplicate conditionals.
TEST=Build and run on Galileo Gen2
Change-Id: I461a5b78a76bd0d2643b85973fd0a70bc5e89581
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15892
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the postcar commands to in between romstage and ramstage. Add the
stage header.
TEST=Build and run on Galileo Gen2
Change-Id: I530da6afd8ccbcea217995ddd27066df6d45de22
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15844
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some of the support functions will be built for romstage
once HIGH_MEMORY_SAVE is removed.
Change-Id: I43ed9067cf6b2152a354088c1dcb02d374eb6efe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When CONFIG_C_ENVIRONMENT_BOOTBLOCK is employed there's no need for
a chipset specific verstage entry point because cache-as-ram has
already been initialized. Therefore, provide a default entry point
for verstage in that environment.
Change-Id: Idd8f45bd58d3e5b251d1e38cca7ae794b8b77a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14971
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "\_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /* device */
acpigen_pop_len(); /* scope */
Will produce this ACPI code:
Scope (\_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14840
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
timestamp.c was not included in bootblock and postcar. This means that
these two stages would use the weak implementation in lib/timestamp.c
instead of the arch-specific implementation based on rdtsc.
This resulted in using timer_monotonic_get() which resets the
timestamps from 0. timer_monotonic_get() only provides per-stage
incrementing semantics on x86 because lapic implementation has
counting down values. A globally incrementing counter like rdtsc
provides the semantics like every other non-x86.
On the test configuration, the weak implementation of timestamp_get()
returned zero, resulting in wrong timestamps coming from the bootblock,
while romstage and ramstage used the arch implementation and returned
correct timestamps.
This is a great example of why weak functions are dangerous, and how
easy it is to miss subtle yet strong interactions between subsystems
and the coreboot buildsystem.
Change-Id: I656f9bd58a6fc179d9dbbc496c5b684ea9288eb5
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14860
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This option is no longer needed, as FMAP support has been
fully integrated in coreboot
Change-Id: I6121b31bf946532717ba15e12f5c63d2baa95ab2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For C_ENVIRONMENT_BOOTBLOCK, memlayout.ld is added by call to
early_x86_stage. Remove redundant addition of memlayout.ld in this
case.
Change-Id: Ibb5ce690ac4e63f7ff5063d5bd04daeeb731e4d7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/13777
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On certain platforms, the boot media is either not memory-mapped, or
not mapped at the top of 4G. This makes the default mmap_boot
implementation unsuitable. Add an option to allow such platforms to
define their own mapping implementation.
Change-Id: I8293126fd9cc1fd3d75072f7811e659765348e4a
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/13319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some newer x86 systems can boot from non-memory-mapped boot media
(e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or
other memory, similar to how most ARM chipsets work. In such cases, we
may not have enough code space for romstage very early on. This means
that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to
be implemented within the limited amount memory of storage available.
Since the reset vector has to be contained in this early code memory,
the bootblock is the best place to implement loading of other stages.
Implement a bootblock which does the minimal initialization, up to,
and including switch to protected mode. This then transfers control
to platform-specific code. No stack is needed, and control is
transferred via a "jmp" such that no stack operations are involved.
Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/13485
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
bootblock.S was used strictly for setting up the system so that the
assembly generated by ROMCC could be executed. Since the
infrastructure now exists to run a bootblock wihtout ROMCC, rename
this file accordingly. this is done to prevent any future confusion.
Change-Id: Icbf5804b66b9517f9ceb352bed86978dcf92228f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/11784
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When C_ENVIRONMENT_BOOTBLOCK is selected link bootblock using the
memlayout.ld scripts and infrastructure. This allows bootblock on
x86 to utilize all the other coreboot infrastructure without
relying romcc.
Change-Id: Ie3e077d553360853bf33f30cf8a347ba1df1e389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13069
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
This provides symbols needed by CBFS and FMAP APIs, and allows running
run_romstage() in an x86 bootblock. Note that console-related files
are not added in this patch, as they are not essential for the
functinality on an x86 environment bootbock.
Change-Id: I36558b672a926ab22bc9018cd51aee32213792c2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/12880
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Trivial fix for syntax highlighting in editors. Some get confused by
the double quote that doesn't have a close quote and stop highlighting
at that point. This comment closes the quote and the paren pair so
that they can recover.
Change-Id: I2bdb7c953a86905fc302d77eb9ad1200958800b7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was breaking the build on OS X, but also wasn't working correctly
under linux anymore either. It wouldn't print the illegal symbols
when it failed.
- Split the generation of the offenders file from the actual check for
offending symbols and just send all output to /dev/null.
- Rewrite the check for offending symbols in a way that works with OS X.
Tested by adding a global variable to romstage and verifying the
failure is shown correctly. Verified that it works correctly with no
illegal variables.
Change-Id: I5b3ac32448851884d78c3b3449508ffe014119ab
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13018
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
$(objgenerated)/empty would touch files before the directory
is created on parallel builds.
Thanks to reproducible-builds.org for hitting this bug.
Change-Id: I7565e9fe130b4e9deaf1c7b9d568ff90b00dda52
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/12717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
verstage, romstage, and payload can be added through infrastructure now.
Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of having to have an ifeq() all across the code base,
use $(target-objcopy). And correct target-objcopy to a value
that objcopy actually understands.
Change-Id: Id5dea6420bee02a044dc488b5086d109e806d605
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11090
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since we now have more freedom in the bootblock linking step it no
longer makes sense to use a monolithic bootblock.S. Code segments must
still be included as the order in bootblock.S determines code flow.
However, non-code flow related assembly stubs don't need to be directly
included in bootblock.S
Change-Id: I08e86e92d82bd2138194ed42652f268b0764aa54
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11792
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code flow doesn't fall through to walkcbfs, as it does in the rest
of bootblock.S. Instead, walkcbfs is called (albeit via a jmp). The
linker cannot know this when walkcbfs.S is included directly.
When we use a CAR bootblock, we lose several hundred bytes because
walkcbfs is not garbage-collected, yet it isn't used. This problem
is solved by assembling walkcbfs.S separately, and linking it.
Change-Id: Ib3a976db09b9ff270b7677cb4f9db80b0b025e22
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11785
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As part of preparing for systems with non-memory-mapped media, we want
to be able to call into C code. This change allows us to link C code
directly into the bootblock. The steps of going from bootblock main()
to CAR setup to C code will be implemented in subsequent patches.
Note that a few files selected with bootblock-y will now be compiled
for the bootblock as well, but since we enabled garbage collection,
they will not be included in the final binary.
Change-Id: I5ca6dcaf176f5469c6a3bb925859399123493bc6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11783
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The only difference between the ifeq/else/endif guarded rules is the
linker flags specific to x86. Add those flags to LDFLAGS_bootblock,
and only use one rule for bootblock.debug.
Change-Id: I986a93e0418f05fb273512d7efe0573052493332
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11782
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to support verstage on x86 one needs to link verstage
like romstage since it needs all the cache-as-ram goodies. Therefore,
provide a macro that one can invoke that provides the necessary
recipes for linking that particular stage in such an environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I12f4872df09fff6715829de68fc374e230350c2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11739
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The output of command below,
# i386-elf-nm build/cbfs/fallback/romstage_null.offenders | \
grep -q "" ; echo $?
has different result on MacOS, OS X Mavericks, which outputs 0.
On linux, it outputs 1.
I assume it is misleading to search an empty string in a empty
string. Change it to testing if the string is empty.
Change-Id: Ie4b8fe1fb26df092e2985937251a49feadc61eb0
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that cbfstool supports XIP for romstage utilize it.
This removes the double link steps with the cbfstool
locate and add-stage sandwich.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I1ec555f523a94dd4b15fe8186cbe530520c622c0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11670
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To reduce file clutter merge romstage.ld and ramstage.ld
into a single memlayout.ld. The naming is consistent with
other architectures and chipsets for their linker script
names. The cache-as-ram linking rules are put into a separate
file such that other rules can be applied for future verstage
support.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and dmp/vortex86ex.
Change-Id: I1e8982a6a28027566ddd42a71b7e24e2397e68d2
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current way the XIP address of romstage is calculated is by
doing a 'cbfstool locate' using a bin file of romstage linked
at address 0. That address is then used for re-linking romstage at
the address spit out by cbfstool. Currently, the linker actually
sets minimum alignment on the text sections as 32 bytes, but it
doesn't actually honor that value. Instead, provide a minimum
alignment for romstage so as not to fight the linker.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built asus/kfsn4-dre. Confirmed ROMSTAGE_BASE == gdtptr.
Change-Id: Id6ec65d257df9ede78c720b0d7d4b56acfbb3f15
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
