All four SMI/NMI interrupt inputs have an external pull-up resistor and
get triggered by pulling the line low. Thus, correct the trigger to
active-low.
Also document the signals by adding appropriate comments.
The pads' connections have been determined by dissecting a dead board.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Id1a8c1e0b9fe723a15d04a88d565a53eeba9b085
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48093
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is used as a signal to show the system state. It hadn't been used
up to this point as we're not currently using S0i3, but the fingerprint
sensor will use it to go into a low power mode, so set it appropriately
on Trembyle. Dalboz devices don't use the FPMCU, but set there as well
so that the state matches.
BUG=b:174695987
TEST=Verify GPIO state in S0 and S3 with the EC
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ibc725905909830d44f77c2498a26edf6d7a3dc05
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48255
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
IASL version 20180927 and greater, detects Unnecessary/redundant uses of
the Offset() operator within a Field Unit list.
It then sends a remark "^ Unnecessary/redundant use of Offset"
example:
OperationRegion (OPR1, SystemMemory, 0x100, 0x100)
Field (OPR1)
{
Offset (0), // Never needed
FLD1, 32,
Offset (4), // Redundant, offset is already 4 (bytes)
FLD2, 8,
Offset (64), // OK use of Offset.
FLD3, 16,
}
We will have those remarks:
dsdt.asl 14: Offset (0),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
dsdt.asl 16: Offset (4),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
Change-Id: I260a79ef77025b4befbccc21f5999f89d90c1154
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43283
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch reduces some code duplication in cbfstool by switching it to
use the CBFS data structure definitions in commonlib rather than its own
private copy. In addition, replace a few custom helpers related to hash
algorithms with the official vboot APIs of the same purpose.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch flips the default of CONFIG_NO_CBFS_MCACHE so the feature is
enabled by default. Some older chipsets with insufficient SRAM/CAR space
still have it explicitly disabled. All others get the new section added
to their memlayout... 8K seems like a sane default to start with.
Change-Id: I0abd1c813aece6e78fb883f292ce6c9319545c44
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the fw_config entries for the newly added boot device fields.
These are added as separate fields since a board may have more
than one selected.
BUG=b:173129299
TEST=abuild google/volteer
Change-Id: I2af9ffcf0b90d4f4b7f2f31613ee110d8f350454
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The initial commit only focused on GL9755S and RTS5261, but there
were recently other cards added to the fw_config and those also
need to be added to the probe lists.
BUG=b:173207454
TEST=abuild google/volteer
Change-Id: Ic27074a016ffbd4c4dd86104a6d85437357c4b82
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48159
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Default VBT supports only integrated Display port. Drawman supports a
HDMI port and hence support a separate VBT for Drawman.
BUG=b:161190931
BRANCH=dedede
TEST=Build and boot to OS in Drawlat and Drawman.
Cq-Depend: TBD
Change-Id: I8895cc67d87428eddb31328f1e3a90c346b54533
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Current flash layout doesn't support the fsp debug builds since
the FW_MAIN_A/B doesn't have enough space to hold the fsp debug
binaries along with ME RW binaries.
This patch reduces the SI_ALL size to 3.5MiB and increase the
SI_BIOS to 12.5MiB to include both ME RW and FSP debug binaries.
BRANCH=dedede
TEST=Build and Boot jslrvp with fsp debug enabled coreboot.
Cq-Depend: chrome-internal:3425366
Change-Id: I6f6354b0c80791f626c09dabafe33eefccedb9c2
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48154
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
AGESA checks to make sure that the firmware version reading the MRC
cache is the same version that wrote it, so it doesn't need to be
erased during a firmware update.
BUG=b:173724014
TEST=Flash firmware to DUT, update firmware, check RW_MRC_CACHE was
not erased
BRANCH=Zork
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ice3d1d467c25366b7ef678cd6481d043f62644ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
As per latest schematics GPP_A15 is not used for EC_SYNC_IRQ
hence remove the unused GPIO.
Wrong GPIO configuration is causing platform reboot issue on
ADLRVP with Chrome SKU.
Change-Id: I704cd722683258c80197d8872d3bdaafb7c923dc
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48131
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
List of changes in SPD:
1. SPD Revision (of JEDEC spec)
2. SDRAM Maximum Cycle Time (tCKAVGmax) (MTB)
3. MSB -> CAS Latencies Supported, First Byte
4. CAS Latencies Supported, Second Byte
5. CAS Latencies Supported, Third Byte
6. LSB -> CAS Latencies Supported, Fourth Byte
7. Minimum CAS Latency Time (tAAmin)
8. Fine Offset for SDRAM Maximum Cycle Time (tCKAVGmax)
9. Fine Offset for SDRAM Minimum Cycle Time (tCKAVGmin)
10.Cyclical Redundancy Code (0- 125 byte)
TEST=Able to build and boot with updated SPD.
Change-Id: Iae7f2693e87bffb2dfa20bd07b22f4a4768c56cb
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Hook up the mainboard_ops driver and configure the GPIOs using .init,
since mainboard_silicon_init_params() is meant for the configuration of
the FSP, not the GPIOs.
Change-Id: I6ab8d258c6f81c90d835cb8d07c6387d3de76d85
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47850
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the drobit variant of the volteer reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.2.0).
BUG=b:171947885
BRANCH=none
TEST=emerge-volteer coreboot
Signed-off-by: Frank Chu <frank_chu@pegatron.corp-partner.google.com>
Change-Id: I63b7312bba236bd5af028359804d042f6850d8ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47787
Reviewed-by: Zhuohao Lee <zhuohao@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
