Specify the memory initialization parameters in
mainboard/intel/galileo/devicetree.cb. Pass these values into FSP to
initialize memory.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I83ee196f5fb825118a3a74b61f73f3728a1a1dc6
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15260
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359317
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Switch the I2C scripts to properly match the I2C address selection for
the Galileo Gen1 board.
TEST=Build an run on Galileo Gen1
BUG=None
BRANCH=None
TEST=None
Change-Id: I9fc8b59a3a719abb474c99a83e0d538794626da9
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15258
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359316
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Remove the unused Kconfig values which specify the PDAT file, its
location and inclusion into the coreboot file system. Remove the code
in romstage which locates the pdat.bin file.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I397aa22ada6c073c60485a735d6e2cb42bfd40ab
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15205
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359313
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Use the device driver for DA7219 device configuration in the SSDT and
remove the static copy in the DSDT.
Tested on reef to ensure that the generated SSDT contents are
equivalent to the current DSDT contents.
BUG=None
BRANCH=None
TEST=None
Change-Id: I288eb05d0cb3f5310c4dca4aa1eab5a029f216af
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15539
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359311
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add a device driver to generate the device and required properties
into the SSDT.
This driver uses the ACPI Device Property interface to generate the
required parameters into the _DSD table format expected by the kernel.
This was tested on the reef mainboard to ensure that the SSDT contained
the equivalent parameters that are provided by the current DSDT object.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia809e953932a7e127352a7ef193974d95e511565
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15538
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359310
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15537
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358959
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
IRQ 9 is used for different purpose on this board so move
SCI away to IRQ10.
BUG=None
BRANCH=None
TEST=None
Change-Id: I107bfb5ec8cd05f844ee75550779be7746e77a88
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15563
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358957
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
TPM PCRs are used in Chrome OS for two purposes: to communicate
crucial information from RO firmware and to protect FW and kernel
rollback counters from being deleted.
As implemented in TPM1 compatible way, the PCR extension command
requires a prebuilt digest to calculate a new PCR value.
TPM2 specification introduces a PCR_Event command, where the TPM
itself calculates the digest of an arbitrary length string, and then
uses the calculated digest for PCR extension. PCR_Event could be a
better option for Chrome OS, this needs to be investigated separately.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that the two PCRs are successfully extended before the
RW firmware is called.
Change-Id: I1a9bab7396fdb652e2e3bc8529b828ea3423d851
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358098
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
The code misses the cases when a response was received but the command
failed. This patch fixes the problem.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=none
Change-Id: I914ab6509d3ab2082152652205802201a6637fcc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358096
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
The TPM2 specification allows defining NV ram spaces in such manner,
that it is impossible to remove the space, unless a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This will guarantee that the spaces can not be
deleted.
Also, there is no need in creating firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358094
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The command is sent in session mode, but has no parameters associated
with it.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the following patches verified that TPM_Clear command is
handled successfully by the TPM.
Change-Id: Ida19e75166e1282732810cf45be21e59515d88e2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357973
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For coreboot TPM2 use case session header is always of the minimal
possible size, the only difference is that some commands require one
and some - two handles.
Let's refactor common session header marshaling code into a separate
function, it will be useful when more commands marshaling code is
added.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=flashed the TPM and rebooted the device a few times, it
successfully loaded chrome os on every attempt.
Change-Id: I86e6426be5200f28ebb2174b418254018e81da8e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357972
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The function is reusing some variables which confuses the reader as
the variable names do not match their second function.
This patch edits the code for readability without changing
functionality.
BRANCH=None
BUG=chrome-os-partner:50465
TEST=with the rest of the patches applied Kevin still boots into
chrome OS.
Change-Id: I95a07945d9d2b00a69d514014f848802b82dd90f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358915
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The marshaling/unmarshaling code is using integer values to represent
room left in the buffer, to be able to communicate three conditions:
positive number means there is room left in the buffer, zero means
that the exact amount of data in the buffer was unmarshaled and
negative value means that the result of the operation did not fit into
the buffer.
The implementation is wrong though, as it compares directly signed and
unsigned values, which is illegal, as signed values get promoted to
unsigned by the compiler.
This patch changes the marshaling code to use size_t for the size, and
use zero as marshaling failure indication - after all the buffer where
the data is marshaled to should definitely be large enough, and it is
reasonable to expect at least some room left in it after marshaling.
The unmarshaling situation is different: we sure want to communicate
errors to the caller, but do not want to propagate error return values
through multiple layers. This patch keeps the size value in int, but
checks if it is negative separately, before comparing with positive
values.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied kevin successfully boots up.
Change-Id: Ie7552b333afaff9a1234c948caf9d9a64447b2e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358772
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Based on the board revision apply the correct GPIO changes.
The only differences are the addition of 2 peripheral wake signals
and a dedicated peripheral reset line.
BUG=chrome-os-partner:54959,chrome-os-partner:54960,chrome-os-partner:54961
BRANCH=None
TEST=Built and tested on reef.
BUG=None
BRANCH=None
TEST=None
Change-Id: I9cac82158e70e0af1b454ec4581c2e4622b95b4b
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15562
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358897
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The board build version is provided by the EC on reef.
Provide the necessary functional support for coreboot
to differentiate the board versions.
BUG=chrome-os-partner:54959,chrome-os-partner:54960,chrome-os-partner:54961
BRANCH=None
TEST=Built and tested on reef.
BUG=None
BRANCH=None
TEST=None
Change-Id: I1b7e8b2f4142753cde736148ca9495bcc625f318
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15561
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358896
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
While the proto boards didn't have a memory SKU notion the
EVT boards do. Therefore, provide support for selecting the
proper memory SKU information based on the memory id straps.
This works on EVT boards because the pins used for the
strapping weren't used on proto. However, internal pullups
need to be enabled so that proto boards read the correct
id.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
BUG=None
BRANCH=None
TEST=None
Change-Id: I8653260e5d1b9adc83b78ea2770c683b72535e11
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15560
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358895
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Instead of having all the mainboards put similar logic
into their own code provide common mechanism for memory
SKU selection. A function, meminit_lpddr4_by_sku(), is
added that selects the proper configuration based on the
SKU id and configuration passed in. LPDDR4 speed as well
as DRAM device density configuration is associated for
each logical channel per SKU id.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ifc6a734040bb61a58bc3d4c128a6420a71245c6c
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15559
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358894
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The internal pulls for gpio_input_pullup() and gpio_input_pulldown()
were using fairly strong pulls. Weaken them so that external pulls
can override the internal ones. This matches the current assumptions
of lib/gpio.c.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ifda1d04d40141325f78db277eb0bd55574994abf
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15558
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358893
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Provide common implementations for gpio_base2_value() variants
which configure the gpio for internal pullups and pulldowns.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
BUG=None
BRANCH=None
TEST=None
Change-Id: I9be8813328e99d28eb4145501450caab25d51f37
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15557
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358892
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Have acpigen_write_package() return a pointer to the package element
counter so it can be used for dynamic package generation where needed.
BUG=None
BRANCH=None
TEST=None
Change-Id: Id7f6dd03511069211ba3ee3eb29a6ca1742de847
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15536
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358891
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The name must not terminated with a newline character `n` as it would
make it hard to use it strings. So, remove the newline from the two SoCs
with it.
BUG=None
BRANCH=None
TEST=None
Change-Id: I7570442b38a455e7c497d7f461c208fb0a88296d
Original-Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-on: https://review.coreboot.org/15540
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358890
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
A call to early_mainboard_init is already present in verstage, thus it
is only necessary to call it from romstage when not in vboot context.
BUG=None
BRANCH=None
TEST=None
Change-Id: I2e0b5a369c5fb24efae4ac40d83a31f5cf4a078d
Original-Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Original-Reviewed-on: https://review.coreboot.org/15450
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358837
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This includes the proper Kconfig options (based on the chromium os
coreboot configuration) for setting up verstage on tegra124 devices.
BUG=None
BRANCH=None
TEST=None
Change-Id: I4a1976ff684a417cae6fa718ef53cad763cee47d
Original-Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Original-Reviewed-on: https://review.coreboot.org/15451
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358836
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since SPI controller opcode registers are locked by FSP, they need to be
initialized to a known good state before ReadyToBoot event and after
every SPI flash access (e.g. for MRC cache) has been finished in order
to enable the OS to use SPI controller without constraints.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0a66344cd44e036c3999ae98d539072299cf5112
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15547
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358832
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The SCI interrupt can be routed to different IRQs using ACPI control
register. Instead of using hard coded IRQ9 for ACPI table generation
read back the register and return the used IRQ number. This way SCI IRQ
can be modified (e.g. for a given mainboard) and ACPI tables will
remain consistent.
BUG=None
BRANCH=None
TEST=None
Change-Id: I534fc69eb1df28cd8d733d1ac6b2081d2dcf7511
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15548
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Original-Reviewed-by: York Yang <york.yang@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358831
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
TPM2 structure definitions use pointers instead of buffers where
possible. One structure was left behind, replace buffer definition
with a pointer to be consistent.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=compilation succeeds, the code using the changed structure in the
upcoming patches allows to successfully boot chrome OS on Kevin
Change-Id: I9856ac516be13f5892ba8af0526708409a297033
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358771
Reviewed-by: Douglas Anderson <dianders@chromium.org>
There are several different macros available to convert a PCI device and
function to a single 8 bit value. One is PCI_DEVFN and is defined in
device/pci_def.h. The other is DEV_FUNC and is defined in several intel
fsp based chipset implementations. In fsp_broadwell_de DEV_FUNC is even
used without being defined at all. This patch unifies the situation so
that only PCI_DEVFN is used.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia1c6d7f3683badc66d15053846936d88aa836632
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15546
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358603
Reviewed-by: Martin Roth <martinroth@chromium.org>
Enable the usage of DRIVER_INTEL_I210 and provide a function to search
for a valid MAC address for all i210 devices using hwilib.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ic0f4f1579364cf5b0111334a05a8a0926785318b
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15517
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358600
Reviewed-by: Martin Roth <martinroth@chromium.org>
The function mainboard_get_mac_address() is used to get a MAC address
for a given i210 PCI device. Instead of passing pure numbers for PCI
bus, device and function pass the device pointer to this function. In
this way the function can retrieve the needed values itself as well as
have the pointer to the device tree so that PCI path can be evaluated
there.
BUG=None
BRANCH=None
TEST=None
Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15516
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358599
Reviewed-by: Martin Roth <martinroth@chromium.org>
This patch adds the basic framework for SCI to GPE routing code.
BUG = chrome-os-partner:53438
TEST = Toogle pch_sci_l from ec console using gpioset command and
see that the sci counter increases in /sys/firmware/acpi/interrupt
and also 9 in /proc/interrupts.
BUG=None
BRANCH=None
TEST=None
Change-Id: I3b3198276530bf6513d94e9bea02ab9751212adf
Original-Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15324
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358596
Reviewed-by: Martin Roth <martinroth@chromium.org>
On Apollolake CSE can be used to fetch firmware from boot media. However,
when this feature is not used, CSE needs to be explicitly notified of it
before memory training is complete. This way it can transition to next
state.
BUG=chrome-os-partner:53876
TEST=CSE can be power-gated during S0iX. Confirmed with LTB.
BUG=None
BRANCH=None
TEST=None
Change-Id: I5141bff350b6c0bb662424b7b709f0787ec5fd28
Original-Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15494
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358594
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add the Audio DSP device for apollolake as a PCI driver with a static
scan_bus handler so generic devices can be declared under it.
This is for devices like the Maxim 98357A which is connected on the
I2S bus for data but has no control channel bus and instead just has
a GPIO for channel selection and power down control and needs to
describe that GPIO connection to the OS via ACPI.
BUG=None
BRANCH=None
TEST=None
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659b12
Original-Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15528
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358592
Reviewed-by: Martin Roth <martinroth@chromium.org>
The P2SB device is device 0xd and function 0. If hidden that
causes the latter pci devices on function >= 1 to not be probed
in the kernel. This is also a problem for coreboot if the P2SB
device is hidden by FSP. That means the coreboot driver won't
be ran. Therefore, provide hide and unhide functions for the
P2SB device.
The other quirk is to allow the GPIO devices to work correctly.
Those devices are ACPI devices. However, their resources are
sub-regions within the P2SB BAR. Sadly, linux doesn't handle
ACPI devices being children of PCI devices. This leads to resource
conflict errors when the P2SB device is visible. For the
time being keep the P2SB device hidden, but also ensure the
resources it is using are accounted for and reserved. The fallout
of that is the PMC and SPI device are no longer probed by the
kernel.
BUG=chrome-os-partner:53017
TEST=Ensured P2SB device is visible and pci resources are allocated
correctly for the devices.
BUG=None
BRANCH=None
TEST=None
Change-Id: I24e59bbde74310e1ce8425b344a3ad0b88702153
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15530
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358590
Reviewed-by: Martin Roth <martinroth@chromium.org>
Correct the GPP PCIe lane number comments so that they match the code.
BUG=None
BRANCH=None
TEST=None
Change-Id: If27c6a55ebedb0927dd9e8c7c9a833194e129a25
Original-Signed-off-by: Derek Waldner <derek.waldner.os@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15095
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358589
Reviewed-by: Martin Roth <martinroth@chromium.org>
Have the different acpi_device_ path functions use a different static
buffer so they can be called interchangeably.
BUG=None
BRANCH=None
TEST=None
Change-Id: I270a80f66880861d5847bd586a16a73f8f1e2511
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15521
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358588
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add the function defined in gpio.h to translate a gpio_t into a
value for use in an ACPI GPIO pin table.
For skylake this just returns the gpio_t value as the pins are
translated directly and they are all in the same ACPI device.
BUG=None
BRANCH=None
TEST=None
Change-Id: I00fad1cafec2f2d63dce9f7779063be0532649c7
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15520
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358587
Reviewed-by: Martin Roth <martinroth@chromium.org>
The upstream kernel driver is not using the of-style naming for
sdmode-gpio so remove the maxim prefix, and remove the duplicate
entry for the sdmode-delay value as well.
Also fix the usage of the path variable, since the device path uses
a static variable it can't be assigned that early or it will be
overwritten by later calls.
This results in the following output for the _DSD when tested on
reef mainboard:
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package (0x02)
{
Package (0x02)
{
"sdmode-gpio",
Package (0x04)
{
_SB.PCI0.HDAS.MAXM,
Zero,
Zero,
Zero
}
},
Package (0x02)
{
"sdmode-delay",
Zero
}
}
})
BUG=None
BRANCH=None
TEST=None
Change-Id: Iab33182a5f64c89151966f5e79f4f7c30840c46f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15514
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358586
Reviewed-by: Martin Roth <martinroth@chromium.org>
