As a follow up to Change-Id: I1fb3fc139e0a813acf9d70f14386a9603c9f9ede,
use as builtin compiler hint instead of inline assembly to allow the
compiler to generate more efficient code.
Change-Id: I690514ac6d8988a6494ad3a77690709d932802b0
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12083
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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>
The previous implementation assumed the CPU physical address size to
be 40 which is not true of all platforms. Use an existing function to
obtain the correct CPU physical address to report in the DMAR ACPI
table.
Change-Id: Ia79e9dadecc3f5f6a86ce3789b213222bef482b3
Signed-off-by: Jacob Laska <jlaska91@gmail.com>
Reviewed-on: https://review.coreboot.org/14102
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Different DIMM modules give different SMBIOS type 17 lengths, so we
can't use `meminfo->dimm_cnt*len' for entry struct size, otherwise
it'll give a wrong SMBIOS size when two or more different DIMMs are
installed on the machine.
Change-Id: I0e33853f6aa4b30da547eb433839a397d451a8cf
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/14008
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to
statically allocate the different memory regions it needs and guarantees
at build time that there are no dangerous overlaps between them. At the
end of its (ramstage) execution, however, it usually loads a payload
(and possibly other platform-specific components) that is not integrated
into the coreboot build system and therefore cannot provide the same
overlap guarantees through memlayout.ld. This creates a dangerous memory
hazard where a new component could be loaded over memory areas that are
still in use by the code-loading ramstage and lead to arbitrary memory
corruption bugs.
This patch fills this gap in our build-time correctness guarantees by
adding the necessary checks as a new intermediate Makefile target on
route to assembling the final image. It will parse the memory footprint
information of the payload (and other platform-specific post-ramstage
components) from CBFS and compare it to a list of memory areas known to
be still in use during late ramstage, generating a build failure in case
of a possible hazard.
BUG=chrome-os-partner:48008
TEST=Built Oak while moving critical regions in the way of BL31 or the
payload, observing the desired build-time errors. Built Nyan, Jerry and
Falco without issues for good measure.
Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13949
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a few assembly lines that are generic enough to be shared
between romstage and verstage that are ran in CAR. The GDT reload
is bypassed and the stack is reloaded with the CAR stack defined
in car.ld. The entry point for all those stages is car_stage_entry().
Change-Id: Ie7ef6a02f62627f29a109126d08c68176075bd67
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13861
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Attempt to better document the symbol usage in car.ld for
cache-as-ram usage. Additionally, add _car_region_[start|end]
that completely covers the entire cache-as-ram region. The
_car_data_[start|end] symbols were renamed to
_car_relocatable_data_[start|end] in the hopes of making it
clearer that objects within there move. Lastly, all these
symbols were added to arch/symbols.h.
Change-Id: I1f1af4983804dc8521d0427f43381bde6d23a060
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13804
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Those options have no effect or lead to compile error on ARM due
to fundamental incompatibilities. Add proper "depends on" clauses
to hide them.
Change-Id: I860fbd331439c25efd8aa92023195fda3add2e2c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of keeping track of all the combinations of entry points
depending on the stage and other options just use _start. That way,
there's no need to update the arch/header.ld for complicated cases
as _start is always the entry point for a stage.
Change-Id: I7795a5ee1caba92ab533bdb8c3ad80294901a48b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13882
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
In order to align the entry points for the various stages
on x86 to _start one needs to rename the reset_vector symbol.
The section is the same; it's just a symbol change.
Change-Id: I0e6bbf1da04a6e248781a9c222a146725c34268a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13881
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Until recently x86 romstage used to be linked at some default
address. The address itself is not meaningful because the code
was normally relocated at address calculated during insertion
in CBFS. Since some newer SoC run romstage at CAR it became
useful to link romstage code at some address in CAR and avoid
relocation during build/run time altogether.
Change-Id: I11bec142ab204633da0000a63792de7057e2eeaf
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13860
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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)
Only i386 has code to support bounce buffer. For others coreboot
would silently discard part of binary which doesn't work and is a hell to debug.
Instead just die.
Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13750
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This builds and produces an image.
The next step is to get a 'halt' instruction into the boot block and then attach with qemu.
I can't get the powerpc64le-linux-gnu-ld.bfd to recognize any output arch but
powerpc. That makes no sense to me.
Change-Id: Ia2a5fe07a1457e7b6974ab1473539c7447d7a449
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/13704
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The 8254 (Programmable Interrupt Timer) is becoming optional
on x86 platforms -- either from saving power or not including it
at all. To allow a payload to still use a TSC without doing
calibration provide the TSC frequency information in the coreboot
tables. That data is provided by code/logic already employed
by platform. If tsc_freq_mhz() returns 0 or
CONFIG_TSC_CONSTANT_RATE is not selected the coreboot table
record isn't created.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed TSC is picked up in
libpayload.
Change-Id: Iaeadb85c2648587debcf55f4fa5351d0c287e971
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13670
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Add lb_arch_add_records() to allow the architecture code to
generically hook into the coreboot table generation.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed lb_arch_add_records() is
called when a strong symbol is provided.
Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13669
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Update ATF codebase to a version that supports passing a timestamp and
fix the format to what it accepts now (including quotes).
This provides reproducible builds.
Change-Id: I12a0a2ba1ee7921ad93a3a877ea50309136ab1ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13726
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Certain platforms may need to limit their bootblock size to within
a given size because specific constraints. Allow the size to be
provided by the mainboard or chipset by way of the arch Kconfig
being processed after those.
Change-Id: I46cc6315918cde575070fa2d3e2514f28008f575
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13691
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is silly to have a single header to declare the main()
symbol, however some of the arches provided it while
lib/bootblock.c relied on the arch headers to declare it. Just
move the declaration into its own header file and utilize it.
Change-Id: I743b4c286956ae047c17fe46241b699feca73628
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13681
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
jmp_to_elf_entry() is not defined anywhere. Remove it.
Change-Id: I68f996a735f2ef3dd60cf69f9b72c3f1481cbb55
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently x86s select BOOTBLOCK_CUSTOM by default. With this
change BOOTBLOCK_CUSTOM is selected only if C bootblock isn't.
Change-Id: I218f3b4044175b89697790c82c384b0f85a27ade
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13642
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Since cbmem is not initialized in bootblock, CAR_GLOBAL variables
can only be accessed directly similar to verstage.
Change-Id: Ifc705016290807c49dc8c49b581864cac2ad3f80
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13641
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Some platforms may want to use C code in bootblock so they need
writable memory and CAR can be used for it. This change reserves
memory in CAR that can be used by bootblock and other CAR stages.
Change-Id: I8dec768cf8763dbe235f0ba1339079ebc49cbd9a
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13640
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The PSTATE mask bits for Debug exceptions, external Aborts, Interrupts
and Fast interrupts are usually best left unset: under normal
circumstances none of those exceptions should occur in firmware, and if
they do it's better to get a crash close to the code that caused it
(rather than much later when the kernel first unmasks them). For this
reason arm64_cpu_init unmasks them right after boot. However, the EL2
payload was still running with all mask bits set, which this patch
fixes.
BL31, on the other hand, explicitly wants to be entered with all masks
set (see calling convention in docs/firmware-design.md), which we had
previously not been doing. It doesn't seem to make a difference at the
moment, but since it's explicitly specified we should probably comply.
BRANCH=None
BUG=None
TEST=Booted Oak, confirmed with raw_read_daif() in payload that mask
bits are now cleared.
Change-Id: I04406da4c435ae7d44e2592c41f9807934bbc802
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ba55bc23fbde962d91c87dc0f982437572a69a8
Original-Change-Id: Ic5fbdd4e1cd7933c8b0c7c5fe72eac2022c9553c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325056
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13596
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On ARM64, the memory type for accessing page table descriptors during
address translation is governed by the Translation Control Register
(TCR). When the MMU code accesses the same descriptors to change page
mappings, it uses the standard memory type rules (defined by the page
table descriptor for the page that contains that table, or 'device' if
the MMU is off).
Accessing the same memory with different memory types can lead to all
kinds of fun and hard to debug effects. In particular, if the TCR says
"cacheable" and the page tables say "uncacheable", page table walks will
pull stale entries into the cache and later mmu_config_range() calls
will write directly to memory, bypassing those cache lines. This means
the translations will not get updated even after a TLB flush, and later
cache flushes/evictions may write the stale entries back to memory.
Since page table configuration is currently always done from SoC code,
we can't generally ensure that the TTB is always mapped as cacheable.
We can however save developers of future SoCs a lot of headaches and
time by spot checking the attributes when the MMU gets enabled, as this
patch does.
BRANCH=None
BUG=None
TEST=Booted Oak. Manually tested get_pte() with a few addresses.
Change-Id: I3afd29dece848c4b5f759ce2f00ca2b7433374da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f3947f4bb0abf4466006d5e3a962bbcb8919b12d
Original-Change-Id: I1008883e5ed4cc37d30cae5777a60287d3d01af0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323862
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13595
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of instructing users to edit xcompile when they want to build
a quark platform, give the build a way to set -march=586 so that
the quark code will build correctly. The Quark processor does not
support the instructions introduced with the Pentium 6 architecture.
Change-Id: I0ed69aadc515f86f76800180e0e33bcd75feac5a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13552
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
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>
If coreboot's build process is reproducible (eg. using the latest git
timestamp as source), bl31 is, too.
This requires an arm-trusted-firmware side merge first (in progress) and
an update of our reference commit for the submodule, but it also doesn't
hurt anything because it merely sets a variable that currently goes
unused.
Change-Id: If139538a2fab5b3a70c67f4625aa2596532308f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13497
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Instead of tagging object files with .<class>, move them to a <class>
directory below $(obj)/. This way we can keep a 1:1 mapping between
source- and object-file names.
The 1:1 mapping is a prerequisite for Ada, where the compiler refuses
any other object-file name.
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: Idb7a8abec4ea0a37021d9fc24cc8583c4d3bf67c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13181
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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>
It's unused, so get rid of it.
Change-Id: I28c6dc0208686edc3aabaf624773ea70350c1c8f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13177
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the coreboot license header, we want to use two paragraphs.
See the section 'Common License Header' in the coreboot wiki
for more details.
Change-Id: I4a43f3573364a17b5d7f63b1f83b8ae424981b18
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13118
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It ended up in .data, and that doesn't seem to be actually necessary.
Change-Id: Ib17d6f9870379d1b7ad7bbd3f16a0839b28f72c8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.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>
Replace with the more familiar AT&T syntax.
Tested by sha1sum(1)ing the object files, and checking the objdump that
the code in question was actually compiled.
Change-Id: Ie85b8ee5dad1794864c18683427e32f055745221
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13132
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add more code to verstage
[pg: split downstream commit into multiple commits]
Change-Id: I578a69a1e43aad8c90c3914efd09d556920f728e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2827aa08ff8712c0245a22378f3ddb0ca054255d
Original-Change-Id: I94a9ee2c00e25a37a92133f813d0cd11a3503656
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292662
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12612
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.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>
Instead of depending BOOTBLOCK_CONSOLE on a set of architectures,
allow the arch or platform to specify whether it can provide a C
environment. This simplifies the selection logic.
Change-Id: Ia3e41796d9aea197cee0a073acce63761823c3aa
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This header is only used for the bootblock compiled with ROMCC. As the
follow-on patches introduce a bootblock which does not make use of
ROMCC, rename this header to prevent confusion.
Change-Id: Id29c5bc6928c11cc7cb922fcfac71e5a3dcd113c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/12867
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>
Paul Kocialkowski