Age | Commit message (Collapse) | Author |
|
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that the users of cbmem_set_top() always provide a consistent
cbmem_top() value there's no need to have cbmem_set_top() around.
Therefore, delete it.
Change-Id: I0c96e2b8b829eddbeb1fdf755ed59c51ea689d1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10314
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
On S3 resume, CBMEM_ID_CONSOLE from previous boot is found in ramstage,
even when romstage did not create it. So buffer did not get cleared
on S3 resume path.
Also do not allocate for preram_cbmem_console in CAR when there
are no means to back it up to ram.
Change-Id: I175cebbb938adf2a7414703fefffb8da796e9fa9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
With LATE_CBMEM_INIT, do not search for the initial collection from
CBMEM in ramstage. On S3 resume this would find the non-empty
collection from previous run of ramstage. Start with an empty table
instead.
Remove a spurious error message as the stamps get stashed and
will be copied to CBMEM later.
Change-Id: Ib94049531c0ac23af25407bd2ca7644ee0163d69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10300
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Implementation for cbmem_find() did not work for boards without
EARLY_CBMEM_INIT in romstage.
This is required for S3 resume to work on AGESA plaforms.
First broken with commit 0dff57d
cbmem: switch over to imd-based cbmem
Change-Id: I9c1a4f6839f5d90f825787baad2a3824a04b5bdc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10299
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The __console attribute as well as linker binding
was dropped at some point. Kill of the dead code and
infrastructure.
Change-Id: I15e1fb4468fffe2e148ec9ac8539dfd958551807
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10279
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
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>
|
|
Add necessary checks and objects for secmon serial console.
Change-Id: Ibafa19061255ef6847a424922565a866328ff34c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10197
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
Change-Id: I2e7f17a686f6af3426c9d68cd9394e9a88dbf358
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10104
Tested-by: build bot (Jenkins)
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>
|