It's been decided to only support ARM Trusted Firmware for
any EL3 monitor. That means any SoC that requires PSCI
needs to add its support for ATF otherwise multi-processor
bring up won't work.
Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11897
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with
bootblock-y) breaks building of x86 boards with
`CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection
enabled.
Aaron Durbin explained as below [1] and provided this patch to fix it.
> That change actually processes bootblock-objs where before it never did
> such a thing. I'm sure this isn’t the only issue lurking. bootblock on
> x86 implied romcc and thus all the bootblock-y += rules that other
> architectures use worked, but now all the implied assumptions are no
> longer true on x86.
>
> timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're
> seeing. In order to compile timestamp.c for bootblock under these
> conditions will mean there needs to be some more Makefile guarding.
[1] http://review.coreboot.org/11864
Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09
Fix-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11875
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of having separate <stage>.ld files in src/lib
one file can be used: program.ld. There's now only one
touch point for stage layout.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This should probably be moved out of lib and to arch/x86,
since it does not even apply on x86-64, and ARM has its
own copy of libgcc.
Change-Id: I4fca1323927f8d37128472ed60d059f7a459fc71
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11110
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
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>
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)
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)
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>
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 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>
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>
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>
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>
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>
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>
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 patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.
BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm
Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f
Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228324
Reviewed-on: http://review.coreboot.org/9411
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>
In commit ec5e5e0d the rmodules linking flags were dropped.
This resulted in relocations being removed from the ELF file.
The relocation information is quite valuable when needing to
perform relocations at runtime.
Change-Id: I699477eb023fc6132e03699992dcf81a311d2d48
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9374
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This allows combining and simplifying linker scripts.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.
Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Two weak functions were added so that architecture specific operations
on each segment of payload or stage can be performed.
Each architecture must define its own operations, otherwise the
behavior will default to do-nothing functions.
This patch has been updated by to fit more in line with
how program loading is currently being done. The API is the
same as the original, but all call sites to stages/payloads
have been updated. This is known to break any archs that use
rmodule loading that needs cache maintenance. That will be fixed
in a forthcoming patch. Also, the vboot paths are left as is
for easier upstreaming of the rest of the vboot patches.
Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239881
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7
Reviewed-on: http://review.coreboot.org/8837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@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>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579
Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8772
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
Aaron Durbin