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: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the RAM config code to the coreboot tables. The purpose is
to expose this information to software running at higher levels, e.g.
to print the RAM config coreboot is using as part of factory tests.
The prototype for ram_code() is in boardid.h since they are closely
related and will likely have common code.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=tested w/ follow-up CLs on pinky
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400
Original-Reviewed-on: https://chromium-review.googlesource.com/227248
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 77dd5fb9347b53bb8a64ad22341257fb3be0c106)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibe7044cafe0a61214ac2d7fea5f7255b2c11829b
Reviewed-on: http://review.coreboot.org/9438
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e
Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228322
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9413
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With kconfig understanding wildcards, we don't need
Kconfig files that just include other Kconfig files
anymore.
Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9298
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also gives ARM64 its
own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech off the ARM one
(currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: I3e8bb3dfbb2c4edada621ce16d130bd7387d4eb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5528aa9252cdf711af3c160da387c6a7bebe9e76
Original-Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9235
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These boards are supposed to be able to determine the board ID at run
time based on GPIO settings.
BUG=chrome-os-partner:30489
TEST=verified that all boards build. Checked that storm proto0 reports
board ID of 0 on the console
Original-Change-Id: Iadd758a799d69e1e34579d7d495378856b64c45b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210119
(cherry picked from commit f4d41ddf906c1bf0d10da38011998fa0a630c332)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d5f94d3428157a70f0a9d711b57432e3f796733
Reviewed-on: http://review.coreboot.org/8722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb
Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210116
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8719
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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: I027902d8408e419b626d0aab7768bc564bd49047
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcc0d934d7223922c878b1f87021cb5c2d7e6f21
Original-Change-Id: If4f99554463bd3760fc142477440326fd16c67cc
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207972
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8760
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Under certain conditions, e.g. automated testing, it is useful
to have the payload (e.g. Linux) reset the reboot_bits CMOS
value. This allows automated recovery in the case of coreboot
starting properly but the payload failing to start due to bad
configuration data provided by the coreboot image under test.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Change-Id: Ifc8f565f8292941d90b2e520cc9c5993b41e9cdd
Reviewed-on: http://review.coreboot.org/8698
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
In specific configurations, such as homogeneous supercomputing systems,
changeable NVRAM parameters are more of a liability than a useful tool.
This patch allows a coreboot image to be compiled that will always set
the NVRAM parameters to their default values, reducing maintainance
overhead on large clusters.
Change-Id: Ic03e34211d4a58cd60740f2d9a6b50e11fe85822
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8446
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
SeaVGABIOS supports both the coreboot linear framebuffer and native EGA
text mode. To use SeaBIOS interactively on standard VGA hardware a VBIOS
is needed; SeaVGABIOS is one such option.
TEST: Booted KFSN4-DRE with XGI Volari Z9s and SeaVGABIOS. Was able to
interact with SeaBIOS and comboot menu, then booted Linux successfully.
VGA display was continuously usable from power on to Linux login.
Change-Id: Id4bd4cb5cece9114457633832c5f0e5280c02b47
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8368
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can now create CBMEM with dynamic allocation even if CBMEM
location is resolved late in ramstage.
Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7861
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Move the CAR migration call to arch -specific part of CBMEM init,
it is truly a x86 specific thing.
Change-Id: I715417e54f197b8745e0670d6b900a5660178141
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7860
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
In preparation to remove the static CBMEM allocator, tag the chipsets
that still do not implement get_top_of_ram() for romstage.
LATE_CBMEM_INIT also implies BROKEN_CAR_MIGRATE.
Change-Id: Iad359db2e65ac15c54ff6e9635429628e4db6fde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7850
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I9210241c902ad8a88980a7c9cdb0d52c460b2541
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/8025
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197800
Original-Tested-by: Vadim Bendebury <vbendeb@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41
Reviewed-on: http://review.coreboot.org/7932
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Always build CBMEM for romstage, even for boards that will not use it.
We further restrict car_migrate_variables() runs to non-ROMCC boards without
BROKEN_CAR_MIGRATE.
This fixes regression of commit 71b21455 that broke CBMEM console support
for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME.
Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7877
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Its scope is limited to a single mainboard and is only to go through ifdef.
Kill it and move the value to the code.
Change-Id: I76a87e2790d57dee8f37b51e33d0689fffd3a59d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7135
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Works in the RISCV version of QEMU.
Note that the lzmadecode is so unclean that it needs a lot of work.
A cleanup is in progress.
We decided in Prague to do this as one thing, because it forms a nice case study
of the bare minimum you need to add to get a new architecture going in qemu.
Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7584
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
There are no reasons to not load ramstage @ 0x100000.
Boards with HAVE_ACPI_RESUME enabled have performance penalty in using
excessive RAMTOP. For these boards, this change releases 11 MiB of RAM from CBMEM allocation to OS.
Change-Id: Ib71995aba5e9332d0ec1626b3eb3b4ef6a506d1c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7094
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Only one setting actually works (exact value depends on board). So
no need to show it.
Change-Id: I2a85719264bbac07791ef6a9279590ba768c309e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7359
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Currently clang/llvm builds are not fully supported. As such,
let us tone down treating errors as warnings until we actually
build the entire tree.
Change-Id: If7f90f9887e27250f5e6d73d1692505676be9d47
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7230
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The reg_script functionality is only used by specific chipsets so have
it selected instead of defaulting to y for ARCH_X86.
Change-Id: I8fb9466e148eed7896ca8ed80755c77ba1190583
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move generic options to the "General Setup" menu.
Move device specific options to the "Devices" menu.
Change-Id: I514a021305d43f026b24fd3016477300700ed401
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/7089
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As currently many systems would be barely functional without ACPI,
always generate ACPI tables if supported.
Change-Id: I372dbd03101030c904dab153552a1291f3b63518
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
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.
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>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)
This patch is essentially a squash of aarch64 changes made by
these patches:
d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support
The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the option to coreboot to set the SeaBIOS buffers below 0xC0000.
This is a requirement on the Intel Rangeley processor
because it is designed so that only the processor can write
the higher memory areas. This prevents USB and SATA from bus-mastering
into the buffers when they're set in the typical 0xE0000 area.
This will be set to Y unless defaulted to N by the mainboard or
chipset.
Push the SeaBIOS buffers down to 0x90000 segment for Mohon Peak
Change-Id: I15638605d1c66a2277d4b852796db89978551a34
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6364
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
This approach avoids having same basic tables 150-lines mantra over 100 times
in codebase.
Change-Id: I76fb2fbcb9ca0654f2e5fd5d90bd62392165777c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6801
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Stop polluting first screen of all boards.
Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Move SeaBIOS' build directory out of build/
This allows the user to delete build/ in the top dir
and keep the built binary in payloads/external/SeaBIOS/seabios/out/
Change-Id: Ia7d515cd7e349beebcd9b62c9d956137acb73c82
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/6460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
On ARM platforms the TPM is not attached through LPC but through I2C.
This patch adds an I2C TPM driver that supports the following chips:
* Infineon SLB9635
* Infineon SLB9645
In order to select the correct TPM implementation cleanly, CONFIG_TPM
is moved to src/Kconfig and does the correct choice.
Old-Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/167543
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit b4049a0e96f6335a93877e1e884f9a440487c421)
i2c tpm: Remove mostly useless delay code/tables.
I assume from the code in the TPM driver that the TPM spec defines
different types of delays and timeouts which each have a particular
duration, and that the TPM can tell you how long each type is if you ask
it. There was a large table, some members of a data structure, and a
function or two which managed the timeouts and figured their value for
different operations. The timeout values for the various "ordinals"
were never set in the vendor specific data structure, however, and
always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d
were never overridden from their defaults. This change gets rid of all
the timeout management code and makes the "ordinal" timeout 2 minutes
and the a, b, c, and d timeouts 2 seconds, the larger of the two default
values.
This is a port from depthcharge to coreboot, original change:
https://chromium-review.googlesource.com/#/c/168363/
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Old-Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf
Reviewed-on: https://chromium-review.googlesource.com/168583
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit b22395a73f361c38626911808332a3706b2334fe)
TPM: Stop requesting/releasing the TPM locality.
The locality is requested when the TPM is initialized and released when
it's cleaned up. There's no reason to set it to the same thing again and
restore it back to the same value before and after every transaction.
forward ported from https://chromium-review.googlesource.com/#/c/168400
Old-Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168584
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit cc866c20c6f936f349d2f1773dd492dca9bbf0c1)
Squashed three commits for the i2c tpm driver.
Change-Id: Ie7a50c50fda8ee986c02de7fe27551666998229d
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6519
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
After commit
2ca2afe ACPI S3 support: Add acpi_s3_resume_allowed()
ACPISCRATCH region in CBMEM was no longer allocated, causing
AGESA platforms to fail S3 resume.
IS_ENABLED() did not evaluate true here with non-zero parameter.
Also avoid multiple defined defaults for HIGH_SCRATCH_MEMORY_SIZE.
Change-Id: Id99e4bee91581b8ac3d1ec44763b2d792b721832
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6093
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
SeaBIOS 1.7.4 was released in December 2013 [1] and, besides other
things, supports writing debug messages to CBMEM console.
The new SeaBIOS Kconfig option `DEBUG_COREBOOT` has to be added to the
SeaBIOS configuration file `.config` as otherwise the SeaBIOS build
from within coreboot (`PAYLOAD_SEABIOS`) is interrupted as it is
detected as a new option.
This option was already added and enabled in commit 7c1a49bc [1]
SeaBIOS: have coreboot pass the choice to run optionroms in parallel
so SeaBIOS messages are now written to the CBMEM console.
Successfully tested on the Asus M2V-MX SE.
[1] http://seabios.org/Releases
[2] http://review.coreboot.org/5443
Change-Id: I675a50532735b4921a664e4b24d98be17b9a1002
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5093
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This drops the scan-build related Kconfig options
since it's now possible to simply run
scan-build [-o outdir] make
and get coreboot built with its report.
There's also no inner make process anymore, and the way
things work should be clearer now.
Also adapt abuild to this new reality.
Change-Id: I03e03334761ec83f718b3235ebf811834cd2e3e3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5774
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Remove arch-level Kconfig menu option as it shows all available architectures in
make menuconfig. Instead pull the bootblock options for choice and update image
to top-level Kconfig since it is already present for both x86 and arm.
Change-Id: Iab9c4539f05cd54a7f751565fefcaf7b6f0edc86
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5673
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Move the non chipset-specific fsp pieces out of the chipset into a
shared area. This is used by northbridge / southbrige / SOC code. It
pulls in pieces from Kconfig, Makefile and FSP specific code.
- Enabled in the CPU code with a Kconfig "select PLATFORM_USES_FSP"
Change-Id: I7ffa934c1df09b71d48a876a56e3b888685870b8
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5635
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Julius Werner