The end of firmware notification is currently not being tracked
so it's hard to get good data on how long it takes. Update the
code to provide timestamp data as well as post codes.
BUG=chrome-os-partner:56656
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17373
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Change-Id: I74c1043f2e72d9d85b23a99b8253ac465f62a7f2
Reviewed-on: https://chromium-review.googlesource.com/411438
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain platforms have a poorly performing SPI prefetcher so even if
accessing MMIO BIOS once the fetch time can be impacted. Payload
loading is one example where it can be impacted. Therefore, add the
ability for a platform to reconfigure the currently running CPU's
variable MTRR settings for the duration of coreboot's execution.
The function mtrr_use_temp_range() is added which uses the previous
MTRR solution as a basis along with a new range and type to use.
A new solution is calculated with the updated settings and the
original solution is put back prior to exiting coreboot into the OS
or payload.
Using this patch on apollolake reduced depthcharge payload loading
by 75 ms.
BUG=chrome-os-partner:56656,chrome-os-partner:59682
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17371
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: If87ee6f88e0ab0a463eafa35f89a5f7a7ad0fb85
Reviewed-on: https://chromium-review.googlesource.com/411436
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have a common romstage.c file to prepare CAR stack guards.
MTRR setup around cbmem_top() is somewhat northbridge specific,
place stubs under northbridge for platrform that will move
to RELOCATABLE_RAMSTAGE.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15762
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I3d4fe4145894e83e5980dc2a7bbb8a91acecb3c6
Reviewed-on: https://chromium-review.googlesource.com/411427
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add a new index for recovery hash space in TPM - 0x100b
2. Add helper functions to read/write/lock recovery hash space in TPM
3. Add Kconfig option that can be selected by mainboards that want to
define this space.
4. Lock this new space while jumping from RO to RW.
BUG=chrome-os-partner:59355
BRANCH=None
TEST=Verified use of recovery hash space on reef.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17273
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1cacd54f0a896d0f2af32d4b7c9ae581a918f9bb
Reviewed-on: https://chromium-review.googlesource.com/410114
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Re-factor MRC cache driver to properly select RW_MRC_CACHE or
RECOVERY_MRC_CACHE based on the boot mode.
- If normal mode boot, use RW_MRC_CACHE, if available.
- If recovery mode boot:
- Retrain memory if RECOVERY_MRC_CACHE not present, or recovery is
requested explicity with retrain memory request.
- Use RECOVERY_MRC_CACHE otherwise.
2. Protect RW and RECOVERY mrc caches in recovery and non-recovery boot
modes. Check if both are present under one unified region and protect
that region as a whole. Else try protecting individual regions.
3. Update training data in appropriate cache:
- Use RW_MRC_CACHE if normal mode.
- Use RECOVERY_MRC_CACHE if present in recovery mode. Else use
RW_MRC_CACHE.
4. Add proper debug logs to indicate which training data cache is used
at any point.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=Verified that correct cache is used in both normal and recovery
mode on reef.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ie79737a1450bd1ff71543e44a5a3e16950e70fb3
Reviewed-on: https://chromium-review.googlesource.com/410099
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add new function vboot_recovery_mode_memory_retrain that indicates if
recovery mode requires memory retraining to be performed.
2. Add helper function get_recovery_mode_retrain_switch to read memory
retrain switch. This is provided as weak function which should be
implemented by mainboard just like {get,clear}_recovery_mode_switch.
BUG=chrome-os-partner:59352
BRANCH=None
TEST=Verified behavior of recovery mode with forced memory retraining on
reef
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17241
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I46c10fbf25bc100d9f562c36da3ac646c9dae7d1
Reviewed-on: https://chromium-review.googlesource.com/410098
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <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>
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Reviewed-on: https://chromium-review.googlesource.com/410076
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
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>
Change-Id: Ib4d0879e52c3f73c6ca61ab75f672f0003fca71f
Reviewed-on: https://chromium-review.googlesource.com/410073
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
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)
Change-Id: I0f81458325697aff9924cc359a4173e0d35da5da
Reviewed-on: https://chromium-review.googlesource.com/408264
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
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>
Change-Id: Ib82e2b65ef7d34e260b7d7450174aee7537b69f6
Reviewed-on: https://chromium-review.googlesource.com/408263
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Reviewed-on: https://chromium-review.googlesource.com/406946
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9
Reviewed-on: https://chromium-review.googlesource.com/402383
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: Ied0cec0ed489df3b39f6b9afd3941f804557944f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395507
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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
BRANCH=None
TEST=None
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>
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Reviewed-on: https://chromium-review.googlesource.com/386986
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
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>
Change-Id: Id45ae3d7c05a9f4ebcf85c446fc68a709513bb0f
Reviewed-on: https://chromium-review.googlesource.com/386275
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: If94415d07fd6bd96c43d087374f609a2211f1885
Reviewed-on: https://chromium-review.googlesource.com/384968
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Reviewed-on: https://chromium-review.googlesource.com/384964
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I2d60e5762f8377e43835558f76a3928156acb26c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376849
Commit-Ready: Simon Glass <sjg@google.com>
Tested-by: Simon Glass <sjg@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Bring in this useful function from Linux 4.7.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=build on gru
Change-Id: I37617e35b4784d6cdc51e6910aa91f566caf971d
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382320
Reviewed-by: Julius Werner <jwerner@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
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Ic6e9b504803622b60b5217c9432ce57caefc5065
Reviewed-on: https://chromium-review.googlesource.com/381665
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696
Reviewed-on: https://chromium-review.googlesource.com/377607
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Reviewed-on: https://chromium-review.googlesource.com/377606
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
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>
Change-Id: Ibe4301fb89c47fde28e883fd11647d6b62a66fb0
Reviewed-on: https://chromium-review.googlesource.com/374461
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
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
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16203
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibafa3dc534f53a3d90487f3190c0f8a2e82858c2
Reviewed-on: https://chromium-review.googlesource.com/373365
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16194
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004
Reviewed-on: https://chromium-review.googlesource.com/373238
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16230
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Change-Id: I44e868d2fd8e1368eeda2f10a35d0a2bd7259759
Reviewed-on: https://chromium-review.googlesource.com/371503
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add write line routine which is called indirectly by FSP.
TEST=Build and run on Galileo Gen2.
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16127
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Idefb6e9ebe5a2b614055dabddc1882bfa3bba673
Reviewed-on: https://chromium-review.googlesource.com/369113
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16104
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id4ed4d93e331f1bf16e038df69ef067446d00102
Reviewed-on: https://chromium-review.googlesource.com/369087
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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
BRANCH=None
TEST=None
Change-Id: I47e8ed76b137c32d9ea0c4967fc616edf40798e5
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>
Reviewed-on: https://chromium-review.googlesource.com/367363
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
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
BUG=None
BRANCH=None
Change-Id: I36982430d0619e1ae8a3745964e497e9c11cf3db
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>
Reviewed-on: https://chromium-review.googlesource.com/366300
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This removes the newlines from all files found by the new
int-015-final-newlines script.
BUG=None
BRANCH=None
TEST=None
Change-Id: I89fcb55ff285e4793d7f057f684187359334cb70
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>
Reviewed-on: https://chromium-review.googlesource.com/366218
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
