This patch adds definition FREQ_LIMIT_RATIO MSR. FREQ_LIMIT_RATIO
register allows to determine the ratio limits to be used to limit
frequency.
BUG=chrome-os-partner:58158
BRANCH=None
Change-Id: I50a792accbaab1bff313fd00574814d7dbba1f6b
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/17211
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
There's no need to keep the snprintf() declaration hidden
for early stages. romcc is the entity that has issues. Therefore,
be explicit about when to guard snprintf().
BUG=chromium:663243
Change-Id: Ib4d0879e52c3f73c6ca61ab75f672f0003fca71f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17289
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Adjust the names to match AMD's convention for family and model.
This patch is relevant for:
Trinity & Richland: Family 15h Models 00h-0Fh
Carrizo: Family 15h Models 60h-6Fh
Mullins & Steppe Eagle: Family 16h Models 30h-3Fh
Change-Id: I613b84ed438fb70269d789c9901f1928b5500757
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/17169
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Martin Roth <martinroth@google.com>
Log when the MRC cache is attempted to be updated with status
of success or failure. Just one slot is supported currently
which is deemed 'normal'. This is because there are more slots
anticipated in the future.
BUG=chrome-os-partner:59395
Change-Id: I0f81458325697aff9924cc359a4173e0d35da5da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17231
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Some events were added in other places, but coreboot's
elog namespace wasn't updated. As such there's a collision
with the thermtrip event. This change at least updates the
elog information to reflect potential event type uage.
BUG=chrome-os-partner:59395
Change-Id: Ib82e2b65ef7d34e260b7d7450174aee7537b69f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17230
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
If selected, libgnat will be linked into ramstage. And, to support Ada
package intializations, we have to call ramstage_adainit().
Change-Id: I11417db21f16bf3007739a097d63fd592344bce3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16944
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the D18F0 device ID for the Stoney APU.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
(cherry picked from commit c0fd7f70527c273bcbdce5655a21ca4de4854428)
Change-Id: Ib599fc6119a3cef53f4f179c2fcd0e45905d81a4
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17141
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Monitor/Mwait is broken on APL. So, it needs to be disabled.
BUG=chrome-os-partner:56922
BRANCH=None
Change-Id: I12cd4280de62e0a639b43538171660ee4c0a0265
Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-on: https://review.coreboot.org/17200
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
All current implementations of ramstage_cache_invalid() were just
resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE
Kconfig option. Move that behavior to a single implementation
within prog_loaders.c which removes duplication.
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17184
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload,
entering main() with no supporting assembly code for startup. The Harvey port
is not complete so it just panics but ... it gets started.
We provide a standard payload function that takes a pointer argument
and makes the jump from machine to supervisor mode;
the days of kernels running in machine mode are over.
We do some small tweaks to the virtual memory code. We temporarily
disable two functions that won't work on some targets as register
numbers changed between 1.7 and 1.9. Once lowrisc catches up
we'll reenable them.
We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual
memory setup code.
We now use the _stack and _estack from memlayout so we know where things are.
As time goes on maybe we can kill all the magic numbers.
Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17058
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
There is no code which uses the backup space in TPM created for vboot
nvram.
All chromebooks currently supported at the trunk store vboot nvram
in flash directly or as a backup.
BUG=chrome-os-partner:47915
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: I9445dfd822826d668b3bfed8ca50dc9386f2b2b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5cee2d54c96ad7952af2a2c1f773ba09c5248f41
Original-Change-Id: Ied0cec0ed489df3b39f6b9afd3941f804557944f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/395507
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://review.coreboot.org/16997
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
cpu/amd/model_fxx.
Change-Id: Iac7571956ed2fb927a6b8cc88514e533f40490d0
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16437
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Implement postcar stage cbmem console support. The postcar stage
is more like ramstage in that RAM is already up. Therefore, in
order to make the cbmem console reinit flow work one needs the cbmem
init hook infrastructure in place and the cbmem recovery called.
This call is added to x86/postcar.c to achieve that. Additionally,
one needs to provide postcar stage cbmem init hook callbacks for
the cbmem console library to use. A few other places need to
become postcar stage aware so that the code paths are taken.
Lastly, since postcar is backed by ram indicate that to the
cbmem backing store.
BUG=chrome-os-partner:57513
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The declarations for console_init() were unconditionally
exposed even though there is a Kconfig option. Correct this
by honoring the CONFIG_POSTCAR_CONSOLE condition.
BUG=chrome-os-partner:57513
Change-Id: Id45ae3d7c05a9f4ebcf85c446fc68a709513bb0f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16617
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This change adds armv7-r support for all stages.
armv7-r is an ARM processor based on the Cortex-R series.
Currently, there is support for armv7-a and armv7-m and
armv7-a files has been modfied to accommodate armv7-r by
adding ENV_ARMV7_A, ENV_ARMV7_R and ENV_ARMV7_M constants
to src/include/rules.h.
armv7-r exceptions support will added in a later time.
Change-Id: If94415d07fd6bd96c43d087374f609a2211f1885
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15335
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change the argument to #ifdef from __PRE_RAM__ to __SIMPLE_DEVICE__
in order to account for the coreboot stages that do not define device_t
and are not __PRE_RAM__ (i.e. smm) device_t
Change-Id: Ic6e9b504803622b60b5217c9432ce57caefc5065
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16369
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current CBMEM code contains an optimization that maintains the
structure with information about the CBMEM backing store in a global
variable, so that we don't have to recover it from cbmem_top() again
every single time we access CBMEM. However, due to the problems with
using globals in x86 romstage, this optimization has only been enabled
in ramstage.
However, all non-x86 platforms are SRAM-based (at least for now) and
can use globals perfectly fine in earlier stages. Therefore, this patch
extends the optimization on those platforms to all stages. This also
allows us to remove the requirement that cbmem_top() needs to return
NULL before its backing store has been initialized from those boards,
since the CBMEM code can now keep track of whether it has been
initialized by itself.
Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16273
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The timestamp code asserts that the _timestamp region (allocated in
memlayout for pre-RAM stages) is large enough for the assumptions it
makes. This is good, except that we often initialize timestamps
extremely early in the bootblock, even before console output. Debugging
a BUG() that hits before console_init() is no fun.
This patch adds a link-time assertion for the size of the _timestamp
region in memlayout to prevent people from accidentally running into
this issue.
Change-Id: Ibe4301fb89c47fde28e883fd11647d6b62a66fb0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Explicitly provide a RW view of an FMAP region. This is required
for platforms which have separate implementations of a RO boot
device and a RW boot device.
BUG=chrome-os-partner:56151
Change-Id: Ibafa3dc534f53a3d90487f3190c0f8a2e82858c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16203
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The current boot device usage assumes read-only semantics to
the boot device. Any time someone wants to write to the
boot device a device-specific API is invoked such as SPI flash.
Instead, provide a mechanism to retrieve an object that can
be used to perform writes to the boot device. On systems where
the implementations are symmetric these devices can be treated
one-in-the-same. However, for x86 systems with memory mapped SPI
the read-only boot device provides different operations.
BUG=chrome-os-partner:55932
Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16194
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Replace a token that is not used anymore.
Change-Id: I36fffd1b713ae46be972803279fc993254bb5806
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16240
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
Change the code guard for do_printk_va_list() accordingly, since it's
used by vboot (not Chrome OS) code.
Change-Id: I44e868d2fd8e1368eeda2f10a35d0a2bd7259759
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16230
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add write line routine which is called indirectly by FSP.
TEST=Build and run on Galileo Gen2.
Change-Id: Idefb6e9ebe5a2b614055dabddc1882bfa3bba673
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16127
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of relying on global state to determine if an error
occurred provide the ability to know if an add or shrink
operation is successful. Now the call chains report the
error back up the stack and out to the callers.
BUG=chrome-os-partner:55932
Change-Id: Id4ed4d93e331f1bf16e038df69ef067446d00102
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16104
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
There is no need to add guards around boot_count_* functions since the
static definition of boot_count_read is anyways unused.
BUG=chrome-os-partner:55473
Change-Id: I553277cdc09a8af420ecf7caefcb59bc3dcb28f1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15997
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a Kconfig value to enable the console during postcar. Add a call
to console_init at the beginning of the postcar stage in exit_car.S.
TEST=Build and run on Galileo Gen2
Change-Id: I66e2ec83344129ede2c7d6e5627c8062e28f50ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This removes the newlines from all files found by the new
int-015-final-newlines script.
Change-Id: I65b6d5b403fe3fa30b7ac11958cc0f9880704ed7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15975
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Build the UART drivers for the postcar stage.
TEST=Build and run on Galileo Gen2
Change-Id: I8bf51135ab7e62fa4bc3e8d45583f2feac56942f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15843
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some Intel SoC may need preparation before reset can be properly
handled. Add callback that chip/soc code can implement.
BUG=chrome-os-partner:55055
Change-Id: I45857838e1a306dbcb9ed262b55e7db88a8944e5
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15720
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a function to power off the system within the halt.h header.
BUG=chrome-os-partner:54977
Change-Id: I21ca9de38d4ca67c77272031cc20f3f1d015f8fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15684
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I52aa8db95b908488ec4cf0843afeb6310dc7f38b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2f859335dfccfeea900f15bbb8c6cb3fd5ec8c77
Original-Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
CAS latency = 2 support added for DDR2.
Change-Id: I08d72a61c27ff0eab19e500a2f547a5e946de2f0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15439
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Original-Commit-Id: 5f082d6a9b095c3efc283b7a49eac9b4f2bcb6ec
Original-Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353916
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
squashed:
mock tpm: drop unused functions
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Original-Commit-Id: c6d7824f52534ecd3b02172cb9078f03e318cb2b
Original-Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356291
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb686c5f9129067eb4bb3ea10bbb85a075b29955
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15571
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This is the first approximation of implementing TPM2 support in
coreboot. It is very clearly incomplete, some of the larger missing
pieces being:
- PCR(s) modification
- protection NVRAM spaces from unauthorized deletion/modification.
- resume handling
- cr50 specific factory initialization
The existing TPM1.2 firmware API is being implemented for TPM2. Some
functions are not required at all, some do not map fully, but the API
is not yet being changed, many functions are just stubs.
An addition to the API is the new tlcl_define_space() function. It
abstracts TMP internals allowing the caller to specify the privilege
level of the space to be defined. Two privilege levels are defined,
higher for the RO firmware and lower for RW firmware, they determine
who can write into the spaces.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied Kevin/Gru devices can
initialize and use firmware and kernel spaces
Change-Id: Ife3301cf161ce38d61f11e4b60f1b43cab9a4eba
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bcc8e62604c705798ca106e7995a0960b92b3f35
Original-Change-Id: Ib340fa8e7db51c10e5080973c16a19b0ebbb61e6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353914
Original-Commit-Ready: Martin Roth <martinroth@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15569
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Provide common implementations for gpio_base2_value() variants
which configure the gpio for internal pullups and pulldowns.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
Change-Id: I9be8813328e99d28eb4145501450caab25d51f37
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15557
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
That function is no longer used. All users have been updated to
use the ulzman() function which specifies lengths for the input
and output buffers.
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15526
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The nhlt_soc_add_endpoint() is no longer used. Drop its declaration.
Change-Id: I3b68471650a43c5faae44bde523abca7ba250a34
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15489
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to ease the porting of supporting NHLT endpoints
introduce a nhlt_endpoint_descriptor structure as well as
corresponding helper functions.
Change-Id: I68edaf681b4e60502f6ddbbd04de21d8aa072296
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15486
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Add functions to convert between seconds and a struct rtc_time. Also
add a function that can display the time on the console.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits and after setting RTC on the EC:
boot on gru into linux shell, check firmware log:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:44
Then reboot ~10 seconds and check again:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:54
Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b02dbcd7d9023ce0acabebcf904e70007428d27
Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351782
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Correct the definitions for 16b and 32b SO-DIMM modules.
Regarding JEDEC Standard No. 21-C
Annex K: Serial Presence Detect for DDR3 SDRAM Modules (2014),
the hex values used for 16b-SO-DIMM is 0x0c
and for 32b-SO-DIMM module type is 0x0d
Change-Id: I9210ac3409a4aaf55a0f6411d5960cfdca05068d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15262
Tested-by: build bot (Jenkins)
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This file is pulled for x86 bootblock builds using ROMCC,
which would choke on struct bus.
Change-Id: Ie3566cd5cfc4b4e0e910b47785449de81a07b9ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15274
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Enable uses of a common bootblock_pre_c_entry routine. Pass in TSC
value as a uint64_t value.
TEST=Build for amenia and Galileo Gen2
Change-Id: I8be2e079ababb2cf1f9b7e6293f93e7c778761a1
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15124
Tested-by: build bot (Jenkins)
Reviewed-by: Lee Leahy <lpleahyjr@gmail.com>
Add asmlinkage to bootblock_main_with_timestamp so that it may be called
directly from the assembly code.
TEST=Build for Amenia and Galileo Gen2
Change-Id: Iefb8e5c1ddce2ec495b9272966b595d5adcebc1c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15125
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to support doing bus operations on an I2C device that is
described in the devicetree there needs to be some linkage of the
device and the existing opaque I2C controller bus number.
This is provided in a similar fashion to the existing SMBUS operations
but modified to fit within the existing I2C infrastructure.
Variants of the existing I2C helper functions are provided that will
obtain the bus number that corresponds to this device by looking for
the SOC-provided I2C bus operation structure to provide a function
that will make that translation.
For example an SOC using a PCI I2C controller at 0:15.0 could use:
soc/intel/.../i2c.c:
static int i2c_dev_to_bus(struct device *dev)
{
if (dev->path.pci.devfn == PCI_DEVFN(0x15, 0))
return 0;
return -1;
}
static struct i2c_bus_operation i2c_bus_ops = {
.dev_to_bus = &i2c_dev_to_bus
}
static struct device_operations i2c_dev_ops = {
.ops_i2c_bus = &i2c_bus_ops
...
}
With an I2C device on that bus at address 0x1a described in the tree:
devicetree.cb:
device pci 15.0 on # I2C0
chip drivers/i2c/sample
device i2c 1a.0 on end
end
end
That driver can then do I2C transactions with the device object
without needing to know that the SOC-specific bus number that this
I2C device lives on is "0".
For example it could read a version value from register address 0
with a byte transaction:
drivers/i2c/sample/sample.c:
static void i2c_sample_enable(struct device *dev)
{
uint8_t ver;
if (!i2c_dev_readb(dev, 0x00, &ver))
printk(BIOS_INFO, "I2C %s version 0x02x\n", dev_path(dev), ver);
}
Change-Id: I6c41c8e0d10caabe01cc41da96382074de40e91e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15100
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Leave it for the platform to fill in the string.
Change-Id: I7b4fe585f8d1efc8c9743f0d8b38de1f98124aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14996
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Export the WRDD spec revision and WiFi domain type in the header
file so it can be used to generate ACPI tables by wifi drivers.
Change-Id: I3222eca723c52fe74a004aa7bac7167264249fd1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15018
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add required definitions to describe an ACPI I2C bus and a method to
write the I2cSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their I2C resources to
the OS. The devicetree i2c device can supply the address and 7 or 10
bit mode as well as indicate the GPIO controller device, and the bus
speed can be fixed or configured by the driver.
chip.h:
struct drivers_i2c_generic_config {
enum i2c_speed bus_speed;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
struct acpi_i2c i2c = {
.address = dev->path->i2c.device,
.mode_10bit = dev->path.i2c.mode_10bit,
.speed = config->bus_speed ? : I2C_SPEED_FAST,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_i2c(&i2c);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
device i2c 10.0 on end
end
end
SSDT.dsl:
I2cSerialBus (0x10, ControllerInitiated, 400000, AddressingMode7Bit,
"\\_SB.PCI0.I2C0", 0, ResourceConsumer)
Change-Id: I598401ac81a92c72f19da0271af1e218580a6c49
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide default handler for some SMI events. Provide the framework for
extracting data from SMM Save State area for processors with SMM revision
30100 and 30101.
The SOC specific code should initialize southbridge_smi with event
handlers. For SMM Save state handling, SOC code should implement
get_smm_save_state_ops which initializes the SOC specific ops for SMM Save
State handling.
Change-Id: I0aefb6dbb2b1cac5961f9e43f4752b5929235df3
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/14615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new function "gpio_acpi_path()" that can be implemented by
SoC/board code to provide a mapping from a "gpio_t" pin to a
controller by returning the ACPI path for the controller that owns
this particular GPIO.
This is implemented separately from the "acpi_name" handler as many
SOCs do not have a specific device that handles GPIOs (or may have
many devices and the only way to know which is the opaque gpio_t)
and the current GPIO library does not have any association with the
device tree.
If not implemented (many SoCs do not implement the GPIO library
abstraction at all in coreboot) then the default handler will return
NULL and the caller knows it cannot determine this reliably.
Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14842
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "\_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /* device */
acpigen_pop_len(); /* scope */
Will produce this ACPI code:
Scope (\_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14840
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function will turn a string of ASCII hex characters into an array
of bytes. It will ignore any non-ASCII-hex characters in the input
string and decode up to len bytes of data from it.
This can be used for turning MAC addresses or UUID strings into binary
for storage or further processing.
Sample usage:
uint8_t buf[6];
hexstrtobin("00:0e:c6:81:72:01", buf, sizeof(buf));
acpigen_emit_stream(buf, sizeof(buf));
Change-Id: I2de9bd28ae8c42cdca09eec11a3bba497a52988c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14837
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is useful, for example, in the bootblock, when a timestamp is
available which predates the call to main() in lib/bootblock.c
Change-Id: I17bb0add9f2d8721504b2e534dd6904d1201989c
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add support for a basic generic device in the devicetree to bind to a
device that does not have a specific bus, but may need to be described
in tables for the operating system. For instance some chips may have
various GPIO connections that need described but do not fall under any
other device.
In order to support this export the basic 'scan_static_bus()' that can
be used in a device_operations->scan_bus() method to scan for the generic
devices.
It has been possible to get a semi-generic device by using a fake PNP
device, but that isn't really appropriate for many devices.
Also Re-generate the shipped files for sconfig. Use flex 2.6.0 to avoid
everything being rewritten. Clean up the local paths that leak into the
generated configs.
Change-Id: If45a5b18825bdb2cf1e4ba4297ee426cbd1678e3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14789
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Use the second token for an i2c device entry in devicetree.cb to
indicate if it should use 10-bit addressing or 7-bit. The default if
not provided is to use 7-bit addressing, but it can be changed to
10-bit addressing with the ".1" suffix. For example:
chip drivers/i2c/generic
device i2c 3a.1 on end
end
Change-Id: I1d81a7e154fbc040def4d99ad07966fac242a472
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14788
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow the platform to override the input clock divider by adding the
uart_input_clock_divider routine. This routine combines the baud-rate
oversample divider with any other input clock divider. The default
routine returns 16 which is the standard baud-rate oversampling value.
A platform may override this default "weak" routine by providing a new
routine and selecting UART_OVERRIDE_INPUT_CLOCK_DIVIDER. This works
around ROMCC not supporting weak routines.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing is successful when CorebootPayloadPkg is able to properly
initialize the serial port without using built-in values.
Change-Id: Ieb6453b045d84702b8f730988d0fed9f253f63e2
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
With all users converted to using the mp_ops callbacks there's
no need to expose that surface area. Therefore, keep it all
within the mp_init compilation unit.
Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14598
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the ability to enable the display of the script:
* Added REG_SCRIPT_COMMAND_DISPLAY to enable and disable display output
* Added context values to manage display support
* display_state - Updated by the command to enable or disable display
* display_features - May be updated by step routine to control what
the step displays for register and value
* display_prefix - Prefix to display before register data
* Added REG_SCRIPT_DISPLAY_ON and REG_SCRIPT_DISPLAY_OFF macros to
control the display from the register script
* Added REG_SCRIPT_DISPLAY_REGISTER and REG_SCRIPT_DISPLAY_VALUE as
two features of the common display. With these features enabled
the following is output:
* Write: <optional prefix> register <-- value
* Read: <optional prefix> register --> value
TEST=Build and run on Galileo Gen2
Change-Id: If0d4d61ed8ef48ec20082b327f358fd1987e3fb9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14553
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to reduce code duplication provide a common flow
through callback functions that performs the multiprocessor
and optionally SMM initialization. The existing MP flight
records are utilized but a common flow is provided such
that the chipset/cpu only needs to provide a mp_ops
structure which has callbacks to gather info and provide
hooks at certain points in the sequence.
All current users of the MP code can be switched over to
this flow since there haven't been any flight records that
are overly complicated and long. After the conversion
has taken place most of the surface area of the MP
API can be hidden away within the compilation unit proper.
Change-Id: I6f70969631012982126f0d0d76e5fac6880c24f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14557
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The SMM module loader code was guarded by CONFIG_SMM_TSEG,
however that's not necessary. It's up to the chipset to take
advantage of the SMM module loading. It'll get optimized out
if the code isn't used anyway so just expose the declarations.
Change-Id: I6ba1b91d0c84febd4f1a92737b3d7303ab61b343
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14560
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The BSP and AP callback declarations both had an optional argument
that could be passed. In practice that functionality was never used
so drop it.
Change-Id: I47fa814a593b6c2ee164c88d255178d3fb71e8ce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14556
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Remove the platform_bus_table routine and replace it with a link time
table. This allows the handlers to be spread across multiple modules
without any one module knowing about all of the handlers.
Establish number ranges for both the SOC and mainboard.
TEST=Build and run on Galileo Gen2
Change-Id: I0823d443d3352f31ba7fa20845bbf550b585c86f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14554
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add xor support which enables toggling of a bit:
* REG_SCRIPT_COMMAND_RXW enum value
* REG_*_RXW* macros to support using REG_SCRIPT_COMMAND_RXW
* REG_*_XOR* macros to support using REG_SCRIPT_COMMAND_RXW
* reg_script_rxw routine to perform and/xor operation
* case in reg_script_run_step to call reg_script_rxw
TEST=Build and run on Galileo Gen2
Change-Id: I50a492c7c2643df5dc2d2fa7113e3722c1e480c7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The x86 architecture needs to add a forwarding table to
the real coreboot table. Provide a helper function to do
this for aligning the architectures on a common
write_tables() implementation.
Change-Id: I9a2875507e6260679874a654ddf97b879222d44e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make
them pluggable.
Also, fix up the following driver subdirectories by switching
to the src/drivers/[X]/[Y]/ scheme as these are hard requirements
for the main change:
* drivers/intel
* drivers/pc80
* drivers/dec
Change-Id: I455d3089a317181d5b99bf658df759ec728a5f6b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14047
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As Aaron pointed out, the old definition made the compiler emit two
memory accesses, to 0 (for derefencing) and then reading at whatever
address could be read from there.
Change-Id: I5cdd53f5bd2d2397c43f09f3e5fa46be08744b01
Found-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14342
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our EDID code had always been aligning the framebuffer's
bytes_per_line (and x_resolution dependent on that) to 64. It turns out
that this is a controller-dependent parameter that seems to only really
be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper
function to calculate bits-per-pixel dependent values) probably actually
broke this for some other controllers by applying the alignment too
widely.
This patch makes it explicitly configurable and depends the default on
ARCH_X86 (which seems to be the simplest and least intrusive way to make
it fit most cases for now... boards where this doesn't apply can still
override it manually by calling edid_set_framebuffer_bits_per_pixel()
again).
Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14267
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A long time ago many Chrome OS boards had pages full of duplicated
boilerplate code for the fill_lb_gpios() function, and we spent a lot of
time bikeshedding a proper solution that passes a table of lb_gpio
structs which can be concisely written with a static struct initializer
in http://crosreview.com/234648. Unfortunately we never really finished
that patch and in the mean time a different solution using the
fill_lb_gpio() helper got standardized onto most boards.
Still, that solution is not quite as clean and concise as the one we had
already designed, and it also wasn't applied consistently to all recent
boards (causing more boards with bad code to get added afterwards). This
patch switches all boards newer than Link to the better solution and
also adds some nicer debug output for the GPIOs while I'm there.
If more boards need to be converted from fill_lb_gpio() to this model
later (e.g. from a branch), it's quite easy to do with:
s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/
Based on a patch by Furquan Shaikh <furquan@google.com>.
BUG=None
BRANCH=None
TEST=Booted on Oak. Ran abuild -x.
Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14226
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
