Intermediate linking may distort linker behavior (in particular related to
weak symbols). The idea is that archives are closer to 'just a list of
object files', and ideally makes the linker more predictable.
Using --whole-archive, the linker doesn't optimize out object files just
because their symbols were already provided by weak versions. However it
shouldn't be used for libgcc, because that one has some unexpected side-effects.
Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10139
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Fill out functions to get the offset and size for both
regions and region_devices. Additionally add a helper for
memory mapping an entire region_device.
Change-Id: I8896eaf5b29e4a67470f4adc6f5b541566cb93b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10215
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to facilitate platforms which need a buffer cache
for performing boot device operations provide infrastructure
to share the logic in managing the buffer and operations.
Change-Id: I45dd9f213029706ff92a3e5a2c9edd5e8b541e27
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide common code for using memory-backed region devices.
This allows in-memory buffers to act as a region device.
Change-Id: I266cd07bbfa16a427c2b31c512e7c87b77f47718
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9131
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The memory pool infrastructure provides an allocator with
very simple free()ing semantics: only the most recent allocation
can be freed from the pool. However, it can be reset and when
not used any longer providing the entire region for future
allocations.
Change-Id: I5ae9ab35bb769d78bbc2866c5ae3b5ce2cdce5fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9129
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The region infrastructure provides a means of abstracting
access to different types of storage such as SPI flash, MMC,
or just plain memory. The regions are represented by
region devices which can be chained together forming subregions
of the larger region. This allows the call sites to be agnostic
about the implementations behind the regions. Additionally, this
prepares for a cleaner API for CBFS accesses.
Change-Id: I803f97567ef0505691a69975c282fde1215ea6da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
verstage previously lacked serial console support.
Add the necessary objects and macro checks to allow
verstage to include the serial console.
Change-Id: Ibe911ad347cac0b089f5bc0d4263956f44f3d116
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10196
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Add support to allocate a region just below CBMEM root. This region is
reserved for FSP 1.1 to use for its stack and variables.
BRANCH=none
BUG=None
TEST=Build and run on Braswell
Change-Id: I1d4b36ab366e6f8e036335c56c1756f2dfaab3f5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10148
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As previously done the vboot loader can be optionally
inserted in the stage loading logic in order to
decide the source of each stage. This current patch
allows for verstage to be loaded and interrogated
for the source of all subsequent stages. Additionally,
it's also possible to build this logic directly into
one of the additional stages.
Note that this patch does not allow x86 to work.
Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10154
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
If the limit of the large starting region was set with
a NULL pointer then the limit field will be 0. If the
limit is zero then no attempt to recover is necessary
as there is no region to recover.
This prevented an early call cbmem_find() from hanging a
rambi device. The config was with vboot enabled and was
way before memory init in the sequence.
Change-Id: I7163d93c31ecef2c108a6dde0206dc0b6f158b5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10175
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
secmon is referring to uart's default_baudrate() and
various coreboot version strings.
Change-Id: I40a8d1979146058409a814d94ea24de83ee4d634
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In linking ramstage a single object file is created before linking
with the linker script. Though there is a weak timestamp_get() symbol
in timestamp.c any of its dependent symbols need to be available
during the incremental link. As not all platforms have
HAVE_MONOTONIC_TIMER enabled this will create a linking error.
Fix this by providing a hint to the compiler to remove dead code
and thus the dependent symbols causing linking errors in the presence
of !HAVE_MONOTONIC_TIMER.
Change-Id: Ib8a5dca2c12c2edac7605f403ed91b793823c8a3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10138
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
And we don't support lzma compressed data in verstage.
Change-Id: I3d8d3290f147871c49e9440e9b54bbf2742aaa9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10103
Tested-by: build bot (Jenkins)
The timestamp code's restriction to run only on the BSP
is for AMD systems. No need to run it everywhere, so
tighten the test (and only run boot_cpu() when required).
Change-Id: I800e817cc89e8688a671672961cab15c7f788ba8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
That function will be used by the vboot loader.
Change-Id: I204c6cd5eede3645750b50fe3ed30d77c22dbf43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10101
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a way for a loader to indicate if it is active. Such users
of this callback would be vboot which can indicate to the rest
of the system that it isn't active. is_loader_active() also
gives vboot a chance to perform the necessary work to make
said decision.
Change-Id: I6679ac75b19bb1bfff9c2b709da5591986f752ff
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10022
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no need to have the VBOOT2_VERIFY_FIRMWARE
distinction because it's the only game in town.
Change-Id: I82aab665934c27829e1a04115bf499ae527a91aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Otherwise it won't build.
Change-Id: If9e1435b0dc8bfe220b3a257976e928373fbc9a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10003
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The new function can be compiled in only when serial console is
disabled.
When invoked, this function initializes the serial interface and dumps
the contents of the CBMEM console buffer to serial output.
BRANCH=none
BUG=chromium:475347
TEST=compiled for different platforms with and without serial console
enabled. No actual test of this function yet.
Change-Id: Ia8d16649dc9d09798fa6970f2cfd893438e00dc5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a38a8254dd788ad188ba2509b9ae117d6f699579
Original-Change-Id: Ib85759a2727e31ba1ca21da7e6c346e434f83b52
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265293
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9984
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It returns TPM_E_NO_DEVICE for all calls.
BRANCH=None
BUG=None
TEST=manual MOCK_TPM=1 emerge-foster coreboot, and
coreboot can boot to kernel
Change-Id: Id7e79b58fabeac929b874385064b2417db49a708
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a9a91a65af115657e7317754eda931120750c56d
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Change-Id: I8dcf0db14cf2bc76c67a3bd7f06114e70e08764d
Original-Reviewed-on: https://chromium-review.googlesource.com/264946
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9983
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In commit b0d8f5e9 I moved the call to cbmem_initialize()
in the CONFIG_EARLY_CBMEM_INIT case to the very beginning of
ramstage. However, that caused an issue in the ordering of the
cbmem console driver in that it expects cbmemc_init() to be
called prior to cbmemc_reinit(). Therefore, ensure console
is called as the first thing even if some time is lost w.r.t.
timestamp tracking.
Change-Id: I42137d28116e0bccb9235f4e3f394d4fd8b84e37
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9933
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Kconfig options pertaining cbmem console in the preram
environment no longer make sense with the linker script
changes. Remove them and their usage within cbmem_console.
Change-Id: Ibf61645ca2331e4851e748e4e7aa5059e1192ed7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9851
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This enables its _size variable (a macro) to work even when
the console has no location assigned to it in the chip/board's
memlayout.ld.
Since _size == 0, the code will do the right thing.
Change-Id: I6b42ed0c5c3aaa613603680728b61cbdb24c4b61
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9973
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
By design, the imd library still provdes dynamic growth so that
feature is consistent. The imd-based cbmem packs small allocations
into a larger entry using a tiered imd. The following examples show
the reduced fragmentation and reduced memory usage.
Before with dynamic cbmem:
CBMEM ROOT 0. 023ff000 00001000
aaaabbbb 1. 023fe000 00001000
aaaabbbc 2. 023fd000 00001000
aaaabbbe 3. 023fc000 00001000
aaaacccc 4. 023fa000 00002000
aaaacccd 5. 023f9000 00001000
ROMSTAGE 6. 023f8000 00001000
CONSOLE 7. 023d8000 00020000
COREBOOT 8. 023d6000 00002000
After with tiered imd:
IMD ROOT 0. 023ff000 00001000
IMD SMALL 1. 023fe000 00001000
aaaacccc 2. 023fc000 00001060
aaaacccd 3. 023fb000 000007cf
CONSOLE 4. 023db000 00020000
COREBOOT 5. 023d9000 00002000
IMD small region:
IMD ROOT 0. 023fec00 00000400
aaaabbbb 1. 023febe0 00000020
aaaabbbc 2. 023feba0 00000040
aaaabbbe 3. 023feb20 00000080
ROMSTAGE 4. 023feb00 00000004
Side note: this CL provides a basis for what hoops one needs to
jump through when there are not writeable global variables on
a particular platform in the early stages.
Change-Id: If770246caa64b274819e45a26e100b62b9f8d2db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9169
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Many chipsets were using a stage cache for reference code
or when using a relocatable ramstage. Provide a common
API for the chipsets to use while reducing code duplication.
Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8625
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
A tiered imd allows for both small and large allocations. The
small allocations are packed into a large region. Utilizing a
tiered imd reduces internal fragmentation within the imd.
Change-Id: I0bcd6473aacbc714844815b24d77cb5c542abdd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The imd (internal memory database) library provides a way to
track memory regions by assigning ids to each region. The implementation
is a direct descendant of dynamic cbmem. The intent is to replace
the existing mechanisms which do similar things: dynamic cbmem, stage
cache, etc.
Differences between dynamic cbmem and imd:
- All structures/objects are relative to one another. There
are no absolute pointers serialized to memory.
- Allow limiting the size of the idm. i.e. provide a maximum
memory usage.
- Allow setting the size of the root structure which allows
control of the number of allocations to track.
Change-Id: Id7438cff80d396a594d6a7330d09b45bb4fedf2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8621
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Instead of always loading romstage from cbfs provide a
way, similar to ramstage and payload, for other
program loaders to intervene. For now, only the cbfs
loader is consulted.
TEST=Booted to end of ramstage on qemu-armv7
Change-Id: I87c3e2e566d7a0723e775aa427de58af745ecdd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9934
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch adds manual board id support to coreboot and
selects manual board ids vs automatic (ie strap based)
where appropriate in the mainboards.
CQ-DEPEND=CL:262935
BRANCH=none
BUG=chrome-os-partner:37593
TEST=emerge-urara coreboot, see no board_id file
emerge-buranku coreboot, see board_id file
Change-Id: Ia04e5498a01f35c5418698ecaf3197f56415e789
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3bdb1fa092005be24de9fc68998053982648da85
Original-Change-Id: I4f0820233a485bf92598a739b81be2076d4e6ae7
Original-Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262745
Original-Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: http://review.coreboot.org/9905
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It became necessary to decode base64 data retrieved from VPD and
convert it into binary for inclusion in the device tree.
The patch introduces the decoder function based on the description
found in http://en.wikipedia.org/wiki/Base64.
An open source implementation from http://base64.sourceforge.net was
considered, in the end the only thing borrowed from it is the table to
translate base64 ascii characters into numbers in 0..63 range.
BRANCH=none
BUG=chromium:450169
TEST=created a test harness generating random contents of random size
(in 8 to 32766 bytes range), then converting the contents into
base64 using the Linux utility, and then converting it back to
binary using this function and comparing the results.
It succeeded 1700 iterations before it was stopped.
Change-Id: I502f2c9494c99ba95ece37a7220c0c70c4755be2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6609f76e1559d3cdd402276055c99e0de7da27c8
Original-Change-Id: I5ed68af3a4daead50c44ae0f0c63d836f4b66851
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262945
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the absolute offset value to the CBFS log, to make it easier to
understand which particular CBFS section the file is loaded from.
BRANCH=storm
BUG=none
TEST=rebooted a Whirlwind device, observed an empty line before the
ramstage section of the log and absolute offsets reported by
CBFS.
Change-Id: Ifcb79ab386629446b98625a5416dfa5850a105f6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ecc4d1df7c51a263230c45ecac5981d53bdd44b1
Original-Change-Id: I5cc727127374d6e55b8ff6f45b250ef97125a8ec
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9827
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:244542
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Original-Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245119
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I549de8c07353683633fbf73e4ee62ba0ed72ff89
Reviewed-on: http://review.coreboot.org/9706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch introduces a new option (CONFIG_MULTIPLE_CBFS_INSTANCES) to
allow multiple CBFS instances in the bootrom.
When the new option is enabled, the code running on the target
controls which CBFS instance is used. Since all other then header CBFS
structures use relative addressing, the only value which needs
explicit setting is the offset of the CBFS header in the bootrom.
This patch adds a facility to set the CBFS header offset. The offset
value of zero means default. i.e. the CBFS initialization code still
discovers the offset through the value saved at the top of the ROM.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest patches in, storm target successfully boots from RW
section A.
Change-Id: Id8333c9373e61597f0c653c727dcee4ef6a58cd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e57a3a15bba7cdcca4a5d684ed78f8ac6dbbc95e
Original-Change-Id: I4c026389ec4fbaa19bd11b2160202282d2f9283c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237569
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I30b742146069450941164afb04641b967a214d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9738
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A payload may want to run erase operations on SPI NOR flash without
re-probing the device to get its properties. This patch passes up
three properties of flash to achieve that:
- The size of the flash device
- The sector size, i.e., the granularity of erase
- The command used for erase
The patch sends the parameters through coreboot and then libpayload.
The patch also includes a minor refactoring of the flash erase code.
Parameters are sent up for just one flash device. If multiple SPI
flash devices are probed, the second one will "win" and its
parameters will be sent up to the payload.
TEST=Observed parameters to be passed up to depthcharge through
libpayload and be used to correctly initialize flash and do an erase.
TEST=Winbond and Gigadevices spi flash drivers compile with the changes;
others don't, for seemingly unrelated reasons.
BRANCH=none
BUG=chromium:446377
Change-Id: Ib8be86494b5a3d1cfe1d23d3492e3b5cba5f99c6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126
Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239570
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a 10us delay in between (re-)configuring and reading
GPIOs in gpio_base2_value() to give the values stored some time
to update.
As far as I know this hasn't bitten us since the function was
added, but adding a short delay here seems like the right thing
to do.
BUG=none
BRANCH=none
TEST=built and booted on Brain
Change-Id: I869cf375680435ad87729f93d29a623bdf09dfbc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2484900fc9ceba87220a293de8ef20c3b9b20cfd
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I79616a09d8d2ce4e416ffc94e35798dd25a6250d
Original-Reviewed-on: https://chromium-review.googlesource.com/240854
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9725
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
checkstack() runs at the end of ramstage to warn about stack overflows,
and it assumes that CONFIG_STACK_SIZE is always the size of the stack to
check. This is only true for systems that bring up multiprocessing in
ramstage and assign a separate stack for each core, like x86 and ARM64.
Other architectures like ARM and MIPS (for now) don't touch secondary
CPUs at all and currently don't look like they'll ever need to, so they
generally stay on the same (SRAM-based) stack they have been on since
their bootblock.
This patch tries to model that difference by making these architectures
explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to
assume the whole (_estack - _stack) area in checkstack() instead. Also
adds a BUG() to the stack overflow check, since that is currently just
as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM
HALTED" output) but a little more easy to spot. Such a serious failure
should not drown out in all the normal random pieces of lower case boot
spam (also, I was intending to eventually have a look at assert() and
BUG() to hopefully make them a little more useful/noticeable if I ever
find the time for it).
BRANCH=None
BUG=None
TEST=Booted Pinky, noticed it no longer complains about stack overflows.
Built Falco, Ryu and Urara.
Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4
Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235894
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9610
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233051
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904
Reviewed-on: http://review.coreboot.org/9446
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
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)
Since gpio.c is more generic now and will be used in various
stages (ie for board_id()), compile it for all stages.
BUG=none
BRANCH=none
TEST=compiled for peppy and veyron_pinky
Change-Id: Ib5c73f68db92791dd6b42369f681f9159b7e1c22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ef4e40ccf6510d63c4a54451bdfea8da695e387e
Original-Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228325
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9414
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
This adds gpio_base2_value() which reads an array of 2-state
GPIOs and returns a base-2 value, where gpio[0] represents the
least significant bit.
BUG=none
BRANCH=none
TEST=tested with follow-up patches for pinky
Change-Id: I0d6bfac369da0d68079a38de0988c7b59d269a97
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 27873b7a9ea237d13f0cbafd10033a8d0f821cbe
Original-Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228323
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9412
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Patrick Georgi