This file reportedly didn't compile on SUSE Linux with gcc 4.3.4:
[...]
> HOSTCC cbfstool/fsp_relocate.o
> In file included from coreboot/src/commonlib/fsp_relocate.c:18:
> coreboot/src/commonlib/include/commonlib/fsp.h:26: error:
> expected '=', ',', ';', 'asm' or '__attribute__' before
> 'fsp_component_relocate'
[...]
According to POSIX-2008[1], sys/types.h defines ssize_t, so include it.
This should not break coreboot code (as opposed to utils code), as we
have a sys/types.h in src/include.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
BUG=none
BRANCH=none
TEST=none
Change-Id: I61d49c1e118c7d16d2f4ec1b600796c7b996c6f3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b89b2c50c5
Original-Change-Id: Id3694dc76c41d800ba09183e4b039b0719ac3d93
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/18417
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445833
This is more consistent with newer Intel targets.
BUG=none
BRANCH=none
TEST=none
Change-Id: If00a2a24cb0d9f85913fb60ef87048a2feac844c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b29e0b70f8
Original-Change-Id: I52ee8d3f0c330a03bd6c18eed08e578dd6ae284b
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18371
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/445832
There was a 'typo' where the subsystem id was set instead of the codec
vendor id. This caused the lynxpoint HDA codecs init to fail to find
the proper codecid verbs so codecs were never initialized. That caused
the headphones jack to not work.
BUG=none
BRANCH=none
TEST=none
Change-Id: I6821c13910c1cd8c91ae6a70e15a222372b135dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 02756b8ffb
Original-Change-Id: I975031643fc42937ecaea2300639b90632543f67
Original-Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Original-Reviewed-on: https://review.coreboot.org/18411
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/445829
The M.2 SSD is on the SATA port 3, which also required the DTLE setting
to be set.
This fixes issues with the M.2 SSD not being detected/stable.
BUG=none
BRANCH=none
TEST=none
Change-Id: I6922d284aeb07f2e32ced1cffaa47fcc1fd28637
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a462c157f8
Original-Change-Id: Id39d9ec395a2d9d32be4c079678d0708f08b3935
Original-Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Original-Reviewed-on: https://review.coreboot.org/18409
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445827
The Broadwell SATA controller supports IOBP registers on ports 0 and 1 but
Browell supports up to 4 ports, so we need to support setting IOBP for
ports 2 and 3 as well.
The magic numbers (IOBP SECRT88 and DTLE) for ports 2 and 3 were only
guessed by looking at ports 0 and 1 and extrapolating from there.
Port 3 has been tested (DTLE setting on Librem 13) and confirmed to work
so we can assume that port 2 and 3 magic numbers are valid, but having
someone confirm them (through non-public documents?) would be great.
BUG=none
BRANCH=none
TEST=none
Change-Id: I8fc1e8ece37b7250cec54ba066b6293420ee6276
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 696ebc2dbc
Original-Change-Id: I59911cfa677749ceea9a544a99b444722392e72d
Original-Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Original-Reviewed-on: https://review.coreboot.org/18408
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445826
The K4B4G1646E-BYK0 shares sdram config with K4B4G1646D-BYK0.
For clarity, sdram-ddr3-samsung-2GB now is used by
- K4B4G1646D-BYK0
- K4B4G1646E-BYK0
- K4B4G1646Q-HYK0
BUG=chrome-os-partner:62131
BRANCH=veyron
TEST=emerge
Change-Id: I461c6f36c28ea0eeaf7d64292c9c87ab0c9de443
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/446197
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit f98251a4a4fe4d49721a936a684f6ac80f3f6405)
Reviewed-on: https://chromium-review.googlesource.com/446300
This adds SDRAM entries for the following modules:
- Micron: DDMT52L256M64D2PP-107
- Hynix: H9CCNNNBKTALBR-NUD
They are compatible with Samsung K4E8E324EB-EGCF, so this just
copies sdram-lpddr3-samsung-2GB-24EB.inc and changes the name used
in the comment near the top.
Notes on our "special snowflake" boards:
- veyron_danger's RAM ID is hard-coded to zero, so I skipped changes
involving the binary first numbering scheme.
- Rialto's SDRAM mapping is different, so I padded its SDRAM entries
to 24 to match other boards.
- veyron_mickey requires different MR3 and ODT settings than other
boards due to its unique PCB (chrome-os-partner:43626).
BUG=chrome-os-partner:59997
BRANCH=none
TEST=Booted new modules on Mickey (see BUG)
Change-Id: I22386a25b965a4b96194d053b97e3269dbdea8c7
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412328
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Jiazi Yang <Tomato_Yang@asus.com>
Tested-by: Jiazi Yang <Tomato_Yang@asus.com>
(cherry picked from commit bd5aa1a5488b99f2edc3e79951064a1f824062f6)
Reviewed-on: https://chromium-review.googlesource.com/446299
Commit-Ready: Shunqian Zheng <zhengsq@rock-chips.com>
Tested-by: Shunqian Zheng <zhengsq@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In order to allow GPIOs to be set/clear according to their polarity,
provide helper functions that check for polarity and call set/clear
SoC functions for generating ACPI code.
BUG=None
BRANCH=None
TEST=Verified that the ACPI code generated remains the same as before
for reef.
Change-Id: I0857d9e5625eca339f6185acea204fcfba901d25
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf4845dd3a
Original-Change-Id: Ie8bdb9dc18e61a4a658f1447d6f1db0b166d9c12
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18427
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/445821
This is done to avoid any conflicts with same IRQ enums defined by other
drivers.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: I54701329455709ce023bf363bdacdadf4f7d2639
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5b9b593f2f
Original-Change-Id: I539831d853286ca45f6c36c3812a6fa9602df24c
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18444
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446382
Adds the necessary plumbing for acpi_device_path() to find the LPC
bridge on the AMD Family14 northbridge with an SB800 southbridge.
This is necessary for TPM support since the acpi path to the LPC bridge
(_SB.PCI0.ISAB) doesn't match the built-in default in tpm.c
(_SB.PCI0.LPCB).
BUG=none
BRANCH=none
TEST=none
Change-Id: I707dcace91005120df4361e8bad749b2f165a308
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d8a2c1fb17
Original-Change-Id: I1ba5865d3531d8a4f41399802d58aacdf95fc604
Original-Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Original-Reviewed-on: https://review.coreboot.org/18402
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/446379
poppy board uses Maxim 98927 speaker codec and Realtek RT5663
for headset. Select the apropriate NHLT blobs to be packaged in CBFS.
Also, generate the required ACPI NHLT table for codec and the supported
topology in poppy.
BUG=chrome-os-partner:62051
BRANCH=None
TEST=With the required driver support in kernel verify that
the Audio plays on on-board speakers and headset, recording
works from on-board mics and headset mics.
Change-Id: I8134a6978c2e21ff0d167a4ee038a1bc69df591f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f5446be4a
Original-Change-Id: I98c65038b35fe99a661807de0766e6eac2c80eed
Original-Signed-off-by: M Naveen <naveen.m@intel.com>
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Original-Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18214
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445640
Add the audio devices to Eve mainboard:
- Describe Maxim 98927 speaker amps and RT5663 headphone codec
in ACPI so they can be enumerated by the OS.
- Supply NHLT binaries for MAX98927, RT5663, and DMIC_4CH.
BUG=chrome-os-partner:61009
TEST=manual testing on Eve P1 with updated kernel to ensure that
both speakers and headset are functional. DMIC support is
is still being worked on and is not yet functional.
Change-Id: Ib2965da2bb25c6d3b48d1da9aad2641b8eaf9189
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5492bfb55c
Original-Change-Id: I5243e35d159a0ed15c6004e94ba5a50b28cff0a9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18398
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/445639
Update GPIO controls and mainboard configurations for Rowan.
BUG=chrome-os-partner:62672
BRANCH=none
TEST=emerge-rowan coreboot
Change-Id: I18ebc3ccf4c7d051839d7c50e9b0682ef8f09830
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/430557
Reviewed-by: Julius Werner <jwerner@chromium.org>
With recent change (a4b11e5c90: soc/intel/skylake: Perform CPU MP Init
before FSP-S Init) to perform CPU MP init before FSP-S init, suspend
resume is currently broken for all skylake/kabylake boards. All the
skylake/kabylake boards store external stage cache in TSEG, which is
relocated post MP-init. Thus, if FSP loading and initialization is
done after MP-init, then ramstage is not able to:
1. Save FSP component in external stage cache during normal boot, and
2. Load FSP component from external stage cache during resume
In order to fix this, ensure that FSP loading happens separately from
FSP initialization. Add fsp_load callback for pre_mp_init which ensures
that the required FSP component is loaded/saved from/to external stage
cache.
BUG=chrome-os-partner:63114
BRANCH=None
TEST=Verified that 100 cycles of suspend/resume worked fine on poppy.
Change-Id: I1b5cef5e3d70669c7e1454f69443c5f4964361b7
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Id: c248044b20
Original-Change-Id: I5b4deaf936a05b9bccf2f30b949674e2ba993488
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18414
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445863
Add a function to allow FSP component loading separately from silicon
initialization. This enables SoCs that might not have stage cache
available during silicon initialization to load/save components from/to
stage cache before it is relocated or destroyed.
BUG=chrome-os-partner:63114
BRANCH=None
TEST=Compiles successfully.
Change-Id: I593b27934b3f2093e3d1d0a36106471d2b5f10e4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Id: f4b20af9d7
Original-Change-Id: Iae77e20568418c29df9f69bd54aa571e153740c9
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18413
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445862
Wacom I2C driver does the same thing as I2C HID driver, other than
defining macros for Wacom HID. Instead of maintaining two separate
drivers providing the same functionality, update all wacom devices to
use generic I2C HID driver.
BUG=None
BRANCH=None
TEST=Verified that ACPI nodes for wacom devices are unchanged.
Change-Id: I40316a2bc0a1210661becf0bf392d259310adbc5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5360c7ef94
Original-Change-Id: Ibb3226d1f3934f5c3c5d98b939756775d11b792c
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18401
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445638
Enable Fast-Plus speed for the touchscreen device so it can
be used at 1MHz instead of 400KHz.
BUG=chrome-os-partner:61277
TEST=manual testing on Eve P1, needs backported kernel patches
to actually make use of any I2C speed other than 400KHz
Change-Id: I0bc6834ed731a60108a77bedef7816bd7bffcc20
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 658a6dc78d
Original-Change-Id: I3f44ff4a02a02a7b05e69ad54d4c6d60e5878393
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18397
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/445637
Since we are not using gpio regulators on reef anymore, remove the
selection from Kconfig as well.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Iaa6ef0c06a23d42c0d92a57a7b3bbf634c4d14d5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: abd5d1d35c
Original-Change-Id: Iae7d88dec3ac476d65b292f97a6ba3add71ce07a
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18399
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445139
Using x86 RDRAND instruction, two functions are supplied to
generate a 32bit or 64bit number.
One potential usage is the sealing key generation for SGX.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve to generate a 64bit random number.
Change-Id: I5e2768ba499f1e008c9b68feae68b368cedaaa39
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 18792314d7
Original-Change-Id: I50cbeda4de17ccf2fc5efc1fe04f6b1a31ec268c
Original-Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18362
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445138
Currently the USB OC pins definition only being defined up to OC3.
For PCH-H, OC4 and OC5 are needed, so add both into OC pin enum.
Changes is being verified and booted to Yocto with Saddle Brook.
BUG=none
BRANCH=none
TEST=none
Change-Id: I48ed19f800726d1220c0110cd3a7fdcb53b760dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f296ce91b9
Original-Change-Id: Idaed6fa7dcddb9c688966e8bc59f656aec2b26eb
Original-Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18364
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445137
Move code common code from each variant's mainboard.asl into
common ACPI code for all variants (like google/auron). This also
adds the _PRW method for the LID0 device for falco and peppy, which
omitted the function when they were originally upstreamed.
See Chromium commit c8b41f7, falco: Add _PRW for LID0 ACPI Device
BUG=none
BRANCH=none
TEST=none
Change-Id: I9199128d0270e1ed6f2600282216950a592001df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4b8252ed76
Original-Change-Id: I7f5129340249a986f5996af37c01ccbde8d374e8
Original-Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18368
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445136
Apply the measured rise and fall times for I2C bus 1 on Eve
so it can be tuned properly for 400KHz operation.
BUG=chrome-os-partner:63020
TEST=verify I2C1 bus speed with a scope
Change-Id: I4bd676d69f77cc8c90cf3c2eb6d29776039aee15
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c86fa6d975
Original-Change-Id: I32b5aa460ea35aadca7f3d52324a64880764919f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18396
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445135
Currently UART0 GPIOs are being put into native mode during FSP-S
stage, so have ramstage re-configure them back to regular GPIO mode.
GPP_C8 does not seem to be functioning properly when routed to the
APIC, possibly due to the UART0 being enabled even though it is unused,
which is required because UART0 is PCI 1e.0 and so must be present for
other 1e.x functions to be enumerated. Instead, use this pin as a GPIO
interrupt so it will be routed through the GPIO controller at IRQ 14.
GPP_C9 was inverted and was only working because the pin was being
re-configured in FSP-S.
Also export the reset gpio as a device property so it can be used by
the kernel driver, which will stop it from complaining at boot.
BUG=chrome-os-partner:61233
TEST=verify that the interrupt and device is functional in the OS
Change-Id: Idca8e787f9d99f2bba03f103ae6fcf0d49ad6a3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6c8238521e
Original-Change-Id: Iaf9efbf50a13a981c6a9bbd507475777837e9c12
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18395
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445134
There is an enable_s0ix config option in the devicetree that should
be used to disable it when not set:
- do not export C8/C9/C10 C-states in _CST
- do not enable SLP_S0 in FSP
BUG=chrome-os-partner:58666
TEST=test on eve board to ensure that OS only sees 3 ACPI C-states
instead of 6 and that it no longer attempts to enter C10
Change-Id: Iabec05c85df22899c04ad5eeb77923fc3e1caf26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 25c7d9342b
Original-Change-Id: I90e4dc776d1d17d0b700cda63c8476786cd2e4ff
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18394
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445133
Add support for more ACPI features in the generic SPI ACPI
driver so it can be flexible enough to support more devices,
or devices in different configurations.
- add a wake pin
- add support for using IRQ GPIO instead of PIRQ
- add power resource support with enable and reset gpios
BUG=chrome-os-partner:61233
TEST=ensure existing SSDT generation is unchanged,
and test that new features generate expected code
Change-Id: Ib4dcba5b0d57539030eb380a9ec38db9f7aea9a7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c9db384ea4
Original-Change-Id: Ibe37cc87e488004baa2c08a369f73c86e6cd6dce
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18393
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445132
Add individual macros for the various interrupt types so
they can be used in devicetree.
BUG=chrome-os-partner:58666
TEST=nothing uses this yet, will be used in an upcoming commit
Change-Id: I191f422ec4216ecc70896a3b33ebbb62955053b4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f31d5c2ce
Original-Change-Id: I2a569f60fcc0815835615656b09670987036b848
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18392
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445131
Move the function that adds a power resource block from
i2c/generic to the acpi device code at src/arch/x86/acpi_device.c
so it can be used by more drivers.
BUG=chrome-os-partner:61233
TEST=verify SSDT table generation is unchanged
Change-Id: I20371b7a7f4e270cd1c61a3e8b9b58b10cafc8ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd73dbbc38
Original-Change-Id: I0ffb61a4f46028cbe912e85c0124d9f5200b9c76
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18391
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445130
Prmrr configuration is supported by Kabylake FSP-M with UPD provided.
It is required as one of the SGX initialization steps in BIOS.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve, verified uncore PRMRR MSRs get programmed to set
size and boot.
Change-Id: I4bf81697e1fa2a2329b67d1b228a329c3a42fc3e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e65affa2ed
Original-Change-Id: I2b3dc7c92487505165ee429bd1a37bd60ceac8f3
Original-Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18361
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445129
Created using autoport plus some manual work and copying from G505S to
account for the non-H8 EC.
This model uses the same ENE KB9012 EC as the G505S.
Tested:
- Mainboard variant with 8GB Elpida DDR3
- SeaBIOS payload
- Booting into Linux 4.9.6 with Debian/unstable installed on the
internal HDD/SDD slot
- Native raminit
- Both native VGA init and option rom VGA init
- Basic TPM functionality (auto-detection and RNG)
- Battery status readout
- Basic ACPI functions (power button event; power-off; reboot)
- thinkpad-acpi hotkey functions
- thinkpad-acpi LED control (red thinkpad LED)
- Suspend to RAM and resume works
- Mini displayport output works
Known issues:
- Patches needed for EC battery support
https://review.coreboot.org/#/c/18348/https://review.coreboot.org/#/c/18349/
- No thermal zone since temperature sensing is not H8-compatible
and needs to be reverse engineered.
Not tested:
- msata/wwan (probably works)
BUG=none
BRANCH=none
TEST=none
Change-Id: Ifd82918d0eb93002027b9ed841e138419691c854
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cee930a39b
Original-Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Original-Change-Id: I52bc4515277e5c18afbb14a80a9ac788049f485c
Original-Reviewed-on: https://review.coreboot.org/18351
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/445636
This mainboard uses two i210 Ethernet controller. Therfore we enable the
usage of the i210 driver and have to provide a function to search for a
valid MAC address for all i210 devices by using Siemens hwilib.
BUG=none
BRANCH=none
TEST=none
Change-Id: I70c71081b5a190304a2f36c4f185c9564822f0d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 480eab0da9
Original-Change-Id: I36246cdef987fcece15a297ebb2f41561fca1f69
Original-Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/18380
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://chromium-review.googlesource.com/445155
Not selecting the Kconfig option `GENERATE_SMBIOS_TABLES` the build
fails with the error below.
```
CC ramstage/ec/lenovo/h8/h8.o
src/ec/lenovo/h8/h8.c:201:2: error: unknown field 'get_smbios_strings' specified in initializer
.get_smbios_strings = h8_smbios_strings,
^
src/ec/lenovo/h8/h8.c:201:2: error: initialization from incompatible pointer type [-Werror]
src/ec/lenovo/h8/h8.c:201:2: error: (near initialization for 'h8_dev_ops.read_resources') [-Werror]
cc1: all warnings being treated as errors
```
So add the appropriate preprocessor guards to fix the build error.
BUG=none
BRANCH=none
TEST=none
Change-Id: I8d29e84c4664871193e0ca6e40ea22554caea1ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a4a452abc
Original-Change-Id: I3baed452d422539a805c628a8c4a6a8c2a809317
Original-Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-on: https://review.coreboot.org/17770
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/445154
Setting both bits 27 and 7 of PCH register PMSYNC_CFG (PMSYNC
Configuration; offset 0x33c8) causes pre-OS display init to fail
on HSW-U/Lynxpoint and BDW-U ChromeOS devices when the VBIOS/GOP
driver is run after the register is set. A re-examination of
Intel's reference code reveals that bit 7 should be set for the
LP PCH, and bit 27 for non-LP, but not both simultaneously.
The previous workaround was to disable the entire power optimizer
section via a Kconfig option, which isn't ideal.
Test: unset bit 27 of PMSYNC_CFG and boot google/lulu,
observe functional pre-OS video output
BUG=none
BRANCH=none
TEST=none
Change-Id: Ie0cc1b294a4f8722bdd3a79faef1516f503d2e03
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c97e042a9b
Original-Change-Id: I446e169d23dd446710a1648f0a9b9599568b80aa
Original-Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18385
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445153
We've been able to narrow down the problem to a single register/
single bit, so revert this commit and address the problem in a
follow-on commit.
This reverts commit 0f2025da0f.
BUG=none
BRANCH=none
TEST=none
Change-Id: I0e986e2be69c6e74eb57c70b13cf625b0317c44d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ee6a612eb2
Original-Change-Id: I780f9ea2976dd223aaa3e060aef6e1af8012c346
Original-Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18384
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445152
It explains the prerequisites to run the script, some
background on how to setup the computer running the script,
and the board it gathers the information from.
That information is too long to fit inside the script's
help.
BUG=none
BRANCH=none
TEST=none
Change-Id: I140c19404433fbeb457a349f39ce26efbb312d13
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: efd9dee646
Original-Change-Id: Iecba7310ff1583149c02728e955716775bcbbdc4
Original-Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Original-Reviewed-on: https://review.coreboot.org/6660
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445151
Add a test in case we have a DIMM2 not populated but DIMM3 is.
BUG=none
BRANCH=none
TEST=none
Change-Id: I80508fd652795593aef7e202891b494d60d4d6a9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75da1fb2ba
Original-Change-Id: I14f82afe03884740570838e7b2771233356c518d
Original-Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Original-Reviewed-on: https://review.coreboot.org/18386
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/445150
Coverity is detecting 'sp' as a variable which has not been initialized.
This is obviously not correct, so this patch *TRIES* to mark it as false
I'm not positive that this will work because the annotation needs to go
on the line above the error, but this error is inside of a # define.
Does the whole #define count as one line? Can it go on the line
above the #define in the .h file? Does it have to precede every line
where the #define is used? The documentation doesn't make this clear.
Should suppress coverity issues: 1368525 & 1368527
uninit_use: Using uninitialized value sp.
BUG=none
BRANCH=none
TEST=none
Change-Id: I8fa056af3e829218d8139f3899b7291e62ea6796
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f797a1ac6a
Original-Change-Id: Ibae5e206c4ff47991ea8a11b6b59972b24b71796
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/18247
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://chromium-review.googlesource.com/445149
