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>
acpigen_write_uuid() will generate a ToUUID() 128-bit buffer object for a
common universally unique identifier that is passed as a string. The
resulting buffer is the UUID in byte format with a specific order of the
bytes as described in the ACPI specification:
ToUUID (uuid)
Compiles to:
Buffer (16) { uuid[3], uuid[2], uuid[1], uuid[0], uuid[5], uuid[4],
uuid[7], uuid[6], uuid[8], uuid[9], uuid[10], uuid[11],
uuid[12], uuid[13], uuid[14], uuid[15] }
Change-Id: Ibbeff926883532dd78477aaa2d26ffffb6ef30c0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14838
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>
strlen(string) was on the "negative" side of the selection operator, the
side where string is NULL.
Change-Id: Ic421a5406ef788c504e30089daeba61a195457ae
Reported-by: Coverity Scan (CID 1355263)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14867
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Add helper functions for generating some common objects:
acpigen_write_STA(status) will generate a status method that will
indicate the device status as provided:
Method (_STA) { Return (status) }
Full status byte configuration is possible and macros are provided for
the common status bytes used for generated code:
ACPI_STATUS_DEVICE_ALL_OFF = 0x0
ACPI_STATUS_DEVICE_ALL_ON = 0xF
acpigen_write_PRW() will generate a Power Resoruce for Wake that describes
the GPE that will wake a particular device:
Name (_PRW, Package (2) { wake, level }
Change-Id: I10277f0f3820d272d3975abf34b9a8de577782e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to produce smaller AML and not rely on the caller to size the
output type appropriately add a helper function that will output an
appropriately sized integer.
To complete this also add helper functions for outputting the single
OpCode for Zero and One and Ones.
And finally add "name" variants of the helpers that will output a
complete sequence like "Name (_UID, Zero)".
Change-Id: I7ee4bc0a6347d15b8d49df357845a8bc2e517407
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add helper function to emit a string into the SSDT AML bytestream with a
NULL terminator. Also add a helper function to emit the string OpCode
followed by the string itself.
acpigen_emit_string(string) /* Raw string output */
acpigen_write_string(string) /* OpCode followed by raw string */
Change-Id: I4a3a8728066e0c41d7ad6429fad983e6ae6962fe
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14793
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add helpers for writing word and dword values in acpigen and use them
throughout the file to clean things up:
acpigen_emit_word - write raw word
acpigen_emit_dword - write raw dword
acpigen_write_word - write word opcode and value
Change-Id: Ia758d4dd25d0ae5b31be7d51b33866dddd96a473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The skylake-based Chromebooks use a separate verstage which runs
just after bootblock and prior to romstage. The normal path for
romstage would be to reload the gdt, however in the previously
described scenario has verstage performing that work. Therefore,
provide that path under those conditions. The only difference
from the C_ENVIRONMENT_BOOTBLOCK scenario is that the stack
should not be reloaded since there's no way to know the top
of the stack.
Change-Id: Ic39ab52a856233d3042ac02a15ae4816ddfe07c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14548
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
The path that just clears CAR_GLOBAL variables and jumps
to the stage entry point needs another condition for
separate verstage just after bootblock. However, the
current conditional is a negative conditional so
swap the logic around to make it easier to extend.
Change-Id: Iab6682498054715a6eaa0476390da6355238b9bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14547
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Stefan and others have discussed their interest in only
including options in Kconfig that are directly associated
with building a coreboot image. There are variables that
are architecture dependent that are utilized in the
coreboot infrastructure. To meet that goal, introduce
<arch/cbconfig.h> header file which defines variables
for the coreboot infrastructure that are architecture
dependent but utilized in common infrastructure.
Change-Id: Ic4cb9e81bab042797539dce004db0f7ee8526ea6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14454
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
C_ENVIRONMENT_BOOTBLOCK on x86 is like romstage and uses cache-as-ram
separately. It does not use any data/bss sections.
Change-Id: I8957f467f01e754fa2d95783466a01daa6c4e51a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In addition to being consistent with all other architectures,
all chipsets support cbmem so the low coreboot table path is
stale and never taken. Also it's important to note the memory
written in to that low area of memory wasn't automatically
reserved unless that path was taken. To that end remove
low coreboot table support for x86.
Change-Id: Ib96338cf3024e3aa34931c53a7318f40185be34c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There were quite a number of #if/#endif guards in the
write_tables() code. Clean up that function by splitting
up the subcomponents into their own individual functions.
The same ordering and logic is kept maintained.
The changes also benefit the goal of using a common core
write_tables() logic so that other architectures don't
duplicate large swaths of code.
Change-Id: I93f6775d698500f25f72793cbe3fd4eb9d01a20c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14431
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Each arch was calling cbmem_list() in their own write_tables()
function. Consolidate that call and place it in common code
in write_coreboot_table().
Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14430
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of hard coding a #define in each architecture's
tables.c for the coreboot table size in cbmem use a Kconfig
varible. This aids in aligning on a common write_tables()
implementation instead of duplicating the code for each
architecture.
Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14429
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to not muddle arch vs chipset implementations provide
a generic prog_segment_loaded() which calls platform_segment_loaded()
and arch_segment_loaded() in that order. This allows the arch variants
to live in src/arch while the chipset/platform code can implement
their own.
Change-Id: I17b6497219ec904d92bd286f18c9ec96b2b7af25
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14214
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
While rmodule_load() calls arch_segment_loaded() when it's done
loading any pieces of code which further modify it, like changing
parameters within the program itself, need to notify the rest of
the system.
Change-Id: Ia3374b58488120ba6279592a77d7f9c6217f1215
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14213
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
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)
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>
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>
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>
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)
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>
