This should be defined by mainboard. Add a dummy
default to fix master while HyperTransport files
are still around referencing this.
Change-Id: I58188a200a2cad5fa20affee1844117ba71ac338
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37036
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are four chipsets selecting PMC_GLOBAL_RESET_ENABLE_LOCK but only
one (apollolake) is actually calling the code. Add the missing call.
Also fix the register offset in a comment in reset code.
Tested successfully on X11SSM-F by reading ETR3.
Change-Id: If190c3c66889ede105d958b423b38ebdcb698332
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36573
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are four chipsets selecting PMC_GLOBAL_RESET_ENABLE_LOCK but only
one (apollolake) is actually calling the code. Add the missing call.
Change-Id: I3e450a473ccdf99221e82e0f857879039d78991b
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36572
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are four chipsets selecting PMC_GLOBAL_RESET_ENABLE_LOCK but only
one (apollolake) is actually calling the code. Add the missing call.
Change-Id: I6aba9bcb2ad09e6ae0e02d8c0b552e34bdb3fa72
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36571
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make use of the new ETR address API in the ETR3 register related
functions.
Further, disabling and locking of global reset is now done at once to
save one read-modify-write cycle, thus the function was renamed
accordingly and the now redundant disabling in soc/apl got removed.
Change-Id: I49f59efb4a7c7d3d629ac54a7922bbcc8a87714d
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a comment to the newly introduced MMIO address helpers for PCI
config registers, that the pointer returned may change during the boot
processs and, thus, must not be cached.
Change-Id: Ieb90ae9d67a3b944d35587dec54756a17c27c86f
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36875
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add VBT file extracted from vendor (AMI) firmware,
use by default to ensure functional display after
resume from S3 when using libgfxinit.
Test: build/boot Librem 13v1/15v2 boards, verify
functional display after resume from S3 when using libgfxinit.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I44d75486da3083cd1f07ea82dc18688db84a621e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36916
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIO49 is strapped high, so setting it low likely increases power
usage. GPIO53 is hooked to a testpad so there is no reason to set
it here.
Change-Id: I00fb38c90417b673c2b36191c20279474eb0dc21
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Perform EC software sync in romstage, before memory training is started.
Because the ChromeOS EC will not currently perform USB-PD negotiation
until it jumps to running its RW code, this allows the system to get
access to more power earlier in the boot flow.
This is guarded by CONFIG_VBOOT_EARLY_EC_SYNC.
BUG=b:112198832
BRANCH=none
TEST=EC software sync works in update and non-update case.
No significant effect on boot time (~6 ms).
Change-Id: I31f3407a2afcbf288461fab1397f965f025bc07c
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36211
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, depthcharge and coreboot are using two different vboot libraries.
coreboot is using "fwlib20", while depthcharge uses "fwlib". The only
difference between the two libraries is the inclusion of vboot1-only
compilation units in fwlib, which are now deprecated. Therefore, coreboot
may as well use fwlib too. Vboot is expected to converge on a single firmware
library soon.
BUG=none
BRANCH=none
TEST=compiles and runs verstage correctly
Change-Id: I905b781c3596965ec7ef45a2a7eafe15fdd4d9cc
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36341
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add 4 new timestamps to the EC software sync flow:
1) Beginning of EC software sync
2) EC finished calculating Vboot hash
3) EC is no longer requesting power limiting
4) End of EC software sync
BUG=none
BRANCH=none
TEST=verified timestamps show up in cbmem log
Change-Id: I6e5703c146b5ec27d01700fdb39cb3d2092ea8a8
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use the new functions introduced into the EC driver to support
performing EC software sync via vboot callbacks.
NOTE: This patch assumes that the EC image is added to CBFS
uncompressed. Streaming decompression of the image will be added in a
future patch.
Also adds a new Kconfig option VBOOT_EARLY_EC_SYNC. The new Kconfig
option compiles EC software sync into romstage, dependent upon having a
CrOS EC.
BUG=b:112198832
BRANCH=none
TEST=Successful EC software sync
Change-Id: I9b1458a45ab3ed5623af50f78036c4f88461b226
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36208
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop struct cbfs_props and replace with struct region_device object.
The goal of the cbfs locator APIs are to determine the correct region
device to find the cbfs files. Therefore, start directly using struct
region_device in the cbfs location paths. Update the users of the API
and leverage the default boot region device implementation for
apollolake.
Change-Id: I0158a095cc64c9900d8738f8ffd45ae4040575ea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since we already have pre-RAM cache for FMAP (CB:36657), calling
load_firmware() multiple times is no longer a problem. This patch
replaces vboot_get_selected_region() usage with vboot_locate_firmware(),
which locates the firmware by reading from the CBMEM cache.
In addition, returning false from vboot_is_slot_selected() implies the
recovery path was requested, i.e., vb2_shared_data.recovery_reason was
set. Therefore, we simply remove the vboot_is_slot_selected() check from
vboot_check_recovery_request().
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: I27cb1a2175beb189053fc3e44b17b60aba474bb0
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since buffer_size is no longer used, remove it from struct
vboot_working_data.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: Ie770e89b4a45e0ec703d5bbb8fb6a298ce915056
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With removal of Torpedo mainboard, this code is no longer
necessary. Will resolve some unique Coverity issues.
Change-Id: I2927245c426566a8f80863a109d015ebf6176803
Signed-off-by: Joe Moore <awokd@danwin1210.me>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
With removal of Torpedo mainboard, this code is no longer
necessary. This also removes fam12 support from northbridge
and SB900 from southbridge.
Change-Id: I8a30461278844d0d9ad4320f0e952774c4fd644f
Signed-off-by: Joe Moore <awokd@danwin1210.me>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This also permits removal of vc/amd/agesa/f12, as it was the only
mainboard using it. That will in turn allow resolving some unique
Coverity issues reported against that source.
Change-Id: I73f570f01fcb5ba0e306508a569ea97f432596b3
Signed-off-by: Joe Moore <awokd@danwin1210.me>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The MIPS architecture port has been added 5+ years ago in order to
support a Chrome OS project that ended up going nowhere. No other board
has used it since and nobody is still willing or has the expertise and
hardware to maintain it. We have decided that it has become too much of
a mainenance burden and the chance of anyone ever reviving it seems too
slim at this point. This patch eliminates all MIPS code and
MIPS-specific hacks.
Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After removing urara no board still uses this SoC, and there are no
plans to add any in the future (I'm not sure if the chip really exists
tbh...).
Change-Id: Ic4628fdfacc9fb19b6210394d96431fdb5f8e8f1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36491
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This board never really existed and nobody has any hardware left over
for it.
Change-Id: Icdba4f5209725995e4a55dcdbc299a9e91a5869a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Arthur Heymans