The functionality to restore the previous power state after power was
lost that could previously be enabled by selecting
MAINBOARD_POWER_RESTORE in the mainboard's Kconfig can now be achieved
by selecting POWER_STATE_PREVIOUS_AFTER_FAILURE in the mainboard's
Kconfig instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab9578ebea89651dc2389bf6ca93ca3f3507eb47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52302
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Picasso and Stoneyridge didn't do a read-modify-write operation on the
lower nibble of PM_RTC_SHADOW_REG, but just wrote the upper nibble as
all zeros. Since the upper nibble might be uninitialized before the
lower nibble gets written, do what Picasso and Stoneyridge did here
instead of what the reference code does. Also add a comment why and how
this register behaves a bit weird.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0bda2349e3ae84cba50b187cc773fd8a5b17f4e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52301
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Not selecting POWER_STATE_DEFAULT_ON_AFTER_FAILURE brings Cezanne that
is currently the only SoC using this functionality in line with Picasso
where the default is that the board remains in power off mode after
power was lost and later restored. Boards can change this behavior by
selecting POWER_STATE_OFF_AFTER_FAILURE, POWER_STATE_ON_AFTER_FAILURE or
POWER_STATE_PREVIOUS_AFTER_FAILURE.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic96f40e3c9867cd821e58d752f58b763930f6d0f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The first CSE Lite SKU is available, therefore enable the Kconfig
option to have the CSE reboot the system into its RW FW during a cold
boot.
BUG=b:183826781
TEST=50 cold reboot cycles
Cq-Depend: chrome-internal:3758108
Change-Id: Ib3a1a9f8ac51bdab8858b2764d5bc0f6f07987cc
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Gerrit is able to add reviewers based on entries in the `MAINTAINERS`
file. For inclusion and exclusion matches either paths or regular
expressions can be used. The syntax is described in the header of the
file.
When matching a path, there are two sensible possibilities:
- `path/to/file` matches a file.
- `path/to/dir/` matches a folder including its contents recursively.
- `path/to/dir/*` matches all files in that folder, without recursing
into its subfolders.
The trailing slash in the second example is essential. Without it, only
the directory entry itself matches when, for example, the folder gets
deleted, renamed or its permissions get modified. Reviewers in the list
won't get added to changes of any files or directories below that path.
However, from time to time entries get added without this trailing
slash. Thus, implement a workaround in `maintainers.go` to check, if a
path entry is actually a directory. In such case a trailing slash gets
appended, so that the contents will match, too.
Example: `path/to/dir` will become `path/to/dir/`
Tests:
1. output before and after does not differ
2. manual test of resulting regex when running `maintainers.go`
Change-Id: Ic712aacb0c5c50380fa9beeccf5161501f1cd8ea
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52276
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
maintainers.go does not handle globs as described in MAINTAINERS.
Instead of only matching the files inside a directory, it also matches
everything below. Also, a glob used in between (`e.g. path/to/*/dir`)
could lead to matching many more paths unexpectedly.
This is caused by the way paths using globs are converted to regegular
expressions for use with gerrit:
1. The script converts all paths with trailing slash to a path with
trailing glob. That means, a recursive match on a directory gets
converted to match only the files in the directory (at least
according to the documentation - if there wasn't 2).
Example: `path/to/dir/` becomes `path/to/dir/*`
2. When converting the path to a regex, all globs get converted to
prefix matching by replacing the glob by `.*`. Instead of only
matching the files in the directory, everything below matches,
which is a) not what the documentation states and b) the opposite
of what 1. did first.
Example: `path/to/dir/*` becomes `^path/to/dir/.*$`
In sum, this leads to all sorts of issues. Examples:
- `path/*/dir` becomes `^path/.*/dir$`
- `path/to/dir/*` becomes `^path/to/dir/.*$`
- `path/to/*.c` becomes `^path/to/.*\.c$`
This change fixes that behaviour by:
- dropping the wrong conversion from 1. above.
- fixing glob matching by replacing `*` by `[^/]`.
- handling paths with trailing `/` as prefix, as documented.
The change was not split because these changes depend on each other and
splitting would break recursive matching between the commits.
Tests:
1. diffed output before and after is equal (!= the same)
2. manual testing of glob matching
Change-Id: I4347a60874e4f07e41bdee43cc312547bea99008
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch ports the last remaining use of cbfs_boot_locate() in the
Intel FSP drivers to the new CBFS API. As a consequence, there is no
longer a reason for fsp_validate_component() to operate on rdevs, and
the function is simplified to take a direct void pointer and size to a
memory-mapping of the FSP blob instead.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If1f0239eefa4542e4d23f6e2e3ff19106f2e3c0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52281
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the vboot EC sync code to use the new CBFS API. As a
consequence, we have to map the whole EC image file at once (because the
new API doesn't support partial mapping). This should be fine on the
only platform that uses this code (Google_Volteer/_Dedede family)
because they are x86 devices that support direct mapping from flash, but
the code was originally written to more carefully map the file in
smaller steps to be theoretically able to support Arm devices.
EC sync in romstage for devices without memory-mapped flash would be
hard to combine with CBFS verification because there's not enough SRAM
to ever hold the whole file in memory at once, but we can't validate the
file hash until we have loaded the whole file and for performance (or
TOCTOU-safety, if applicable) reasons we wouldn't want to load anything
more than once. The "good" solution for this would be to introduce a
CBFS streaming API can slowly feed chunks of the file into a callback
but in the end still return a "hash valid/invalid" result to the caller.
If use cases like this become pressing in the future, we may have to
implement such an API.
However, for now this code is the only part of coreboot with constraints
like that, it was only ever used on platforms that do support
memory-mapped flash, and due to the new EC-EFS2 model used on more
recent Chrome OS devices we don't currently anticipate this to ever be
needed again. Therefore this patch goes the easier way of just papering
over the problem and punting the work of implementing a more generic
solution until we actually have a real need for it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7e263272aef3463f3b2924887d96de9b2607f5e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52280
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Gerrit is able to add reviewers based on entries in the `MAINTAINERS`
file. For inclusion and exclusion matches either paths or regular
expressions can be used. The syntax is described in the header of the
file.
When matching a path, there are two sensible possibilities:
- `path/to/file` matches a file.
- `path/to/dir/` matches a folder including its contents recursively.
- `path/to/dir/*` matches all files in that folder, without recursing
into its subfolders.
The trailing slash in the second example is essential. Without it, only
the directory entry itself matches when, for example, the folder gets
deleted, renamed or its permissions get modified. Reviewers in the list
won't get added to changes of any files or directories below that path.
Thus, add a linter script to ensure a path match on a directory always
ends with `/` or `/*` as shown above.
Change-Id: I9873184c0df4a0b4455f803828e2719887e545db
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of counting consecutive matches (in `j`), check for a second
match directly in the control flow. Also, add some dedicated variables:
* `tap`: Keeps track of the tap value that resulted in a match and
is eventually programmed into the hardware.
* `tap2`: Is just temporarily used to search for another edge.
Keeping `tap` sync'ed with the hardware has the benefit that we don't
need to read the programmed value back for later fixups.
Change-Id: I3ae541c39efdc695f5ca74bc757b2f009239ec93
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When EC_GOOGLE_CHROMEEC_INCLUDE_SSFC_IN_FW_CONFIG is enabled and SSFC is
not set, all fw_config is invalidated. But for some platform this may
not be necessary, we can treat missing SSFC as zero and use other 32
bits of firmware config.
BUG=b:184809649
TEST=boot and check fw_config is not -1 even if ssfc is not set
BRANCH=zork
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I21c7b0d449a694d28ad7b3f14b035e3a5830030a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This commit enables HECI such that interface can be used from
userspace on the dedede mainboards.
BUG=b:184219504
TEST=Build and flash drawcia, verify that Intel Flash Programming Tool
can communicate with the Converged Security Engine.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I5b28c471d6554a5e14538073d48ef47da05936fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Verified that all accessed registers exist in all SoCs that use this
code (Carrizo, Mullins, Stoneyridge, Picasso and Cezanne at the moment)
and that the bit definitions match as well. Also at the time of writing
this patch only Picasso calls gpio_fill_wake_state, so dropping the
check won't change behavior. This also avoids having SoC specific code
that doesn't get selected by Kconfig options in the common AMD SoC
directory and also avoids having to add a check for SOC_AMD_CEZANNE to
support this functionality on Cezanne in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If770780a67776daf81744db1b635ffd402653a47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52223
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is no nb/amd/pi northbridge left in coreboot that could be paired
with the Bolton FCH, since the remaining nb/amd/pi northbridges all use
an integrated FCH (Avalon on Mullins and Kern on Carrizo) while Bolton
is a discrete FCH. I ran into this when verifying if the common soc/amd
GPIO functionality that gets added by selecting
SOC_AMD_COMMON_BLOCK_BANKED_GPIOS is valid for all chips selecting it
and that code isn't valid for Bolton that uses the old GPIO 100
interface.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iffe876bee96e42645e1be10730b78959b1c06d59
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52222
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Coverity reported false-positive possible memory overrun
in setup_calloc_test(). Change memset address to use actual
buffer instead of pointer stored in symbol value in order
to silence Coverity.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I19f0718c657d565e515157e66367573e08f51254
Found-by: Coverity CID 1452005
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52136
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch enables Bluetooth config in the devicetree and removes
non-existent Bluetooth PCI interface.
TEST=Verified by checking Garfield Peak controller's PID:VID(8087:0033) in
the lsusb ouput.
Output of lsusb:
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. USB 10/100/1000 LAN
Bus 004 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0781:55a9 SanDisk Corp. Dual Drive
Bus 003 Device 004: ID 413c:2113 Dell Computer Corp. Dell KB216 Wired Keyboard
Bus 003 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 003 Device 005: ID 8087:0033 Intel Corp.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I7a54d344ef1b0418bee56e7308977a61604b954a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52182
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure the power state to return to when the power is re-applied
after power failure.
BUG=b:183739671
TEST=Build and Boot to OS in Majolica and Guybrush. By default when the
power fails the device turns on after power is re-applied. When the
POWER_ON_AFTER_POWER_FAILURE is disabled, the device remains off even
after the power is re-applied.
Change-Id: I21c5da08c82156d6239450ef6921771da74cbaa1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52049
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a power management library to handle the power resume after
power failure. Enable HAVE_POWER_STATE_AFTER_FAILURE config when this
library is enabled.
BUG=b:183739671
TEST=Build Guybrush and Majolica mainboard.
Change-Id: Iea4ea57d747425fe6714d40ba6e60f2447febf28
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
