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>
Bootstrapping gcc is the recommended way if your host gcc's version
doesn't match the gcc version you're going to build. While a build
with an outdated host gcc usually succeeds, an outdated gnat seems
to be a bigger issue.
v3: Some library controversy: gcc likes the libraries it ships with
most but we don't want to install shared libraries. So we build
them static --disable-shared) and install only the minimum
(libgcc, libada, libstdc++). However, as the code of these
libraries might be used to build a shared library we have to
compile them with `-fPIC`.
v4: o Updated getopt strings.
o The workaround for clang (-fbracket-depth=1024) isn't needed
for bootstrapping and also breaks the build, as clang is only
used for the first stage in that case and gcc doesn't know
that option.
So far build tested with `make BUILDGCC_OPTIONS="-b -l c,ada"` on
o Ubuntu 14.04 "Trusty Tahr" (i386)
o Debian 8 "Jessie" (x86_64) (building python (-S) works too)
o current Arch Linux (x86_64)
o FreeBSD 10.3 (x86_64) (with gcc-aux package)
and with clang host compiler, thus C only: `make BUILDGCC_OPTIONS="-b"`
on
o Debian 8 "Jessie" (x86_64)
o FreeBSD 10.3 (x86_64)
v5: Rebased after toolchain updates to GCC 5.3.0 etc.
Build tested with `make BUILDGCC_OPTIONS="-b -l c,ada"` on
o Debian 8 "Jessie" (x86_64)
BUG=None
BRANCH=None
TEST=None
Change-Id: Icb47d3e9dbafc55737fbc3ce62a084fb9d5f359a
Original-Signed-off-by: Nico Huber <nico.huber@secunet.com>
Original-Reviewed-on: https://review.coreboot.org/13473
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358602
Reviewed-by: Martin Roth <martinroth@chromium.org>
Refactor build() to make things more flexible:
Add a parameter that tells if we build a package for the host or for a
target architecture. This is just passed to the build_$package()
function and can be used later to take different steps in each case
(e.g. for bootstrapping a host gcc).
Move .success files into the destination directory. That way we can tell
that a package has been built even if the package build directory has
been removed.
BUG=None
BRANCH=None
TEST=None
Change-Id: I52a7245714a040d11f6e1ac8bdbff8057bb7f0a1
Original-Signed-off-by: Nico Huber <nico.huber@secunet.com>
Original-Reviewed-on: https://review.coreboot.org/13471
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358601
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>
Due to a newer flex version with which the scanner was recreated, we
also have to make the compiler less strict on the generated code.
BUG=None
BRANCH=None
TEST=None
Change-Id: I3758c0dcb2f5661d072b54a30d6a4ebe094854e6
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15482
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358598
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>
Require the user to specify which architecture the payload/stage
was built for before extracting it.
BUG=None
BRANCH=None
TEST=None
Change-Id: I8ffe90a6af24e76739fd25456383a566edb0da7e
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/15438
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/358595
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>
cbgfx currently makes a separate function call (recomputing some values)
for every single pixel it draws. While we mostly don't care that much
about display speed, this can become an issue if you're trying to paint
the whole screen white on a lowly-clocked Cortex-A53. As a simple
solution for these extreme cases, we can build a fast path into
clear_screen() that just memset()s the whole framebuffer if the color
and pixel format allow it.
BUG=chrome-os-partner:54416
TEST=Screen drawing speed on Kevin visibly improves (from 2.5s to 3ms).
BUG=None
BRANCH=None
TEST=None
Change-Id: I22f032afbb86b96fa5a0cbbdce8526a905c67b58
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15524
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358591
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>
There are four GPIO communities in this SOC and they are implemented
as separate ACPI devices. This means the pin number that is used in
an ACPI GPIO declaration needs to be relative to the community that
the pin resides in. Also select GENERIC_GPIO_LIB in the SOC Kconfig
so this function actually gets used.
This was tested on the reef mainboard by verifying the output of the
SSDT for the Maxim 98357A codec that the assigned GPIO_76 is listed
as pin 0x24 which is the value relative to the Northwest community.
BUG=None
BRANCH=None
TEST=None
Change-Id: Iad2ab8eccf4c91185a075ffce8d41c81f06c1113
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15513
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/358585
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
BUG=None
BRANCH=None
TEST=None
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15512
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/358584
Reviewed-by: Martin Roth <martinroth@chromium.org>
Instantiate the touchpad using the drivers/i2c/generic device driver
to generate the ACPI object in the SSDT.
There is not currently a separate wake pin for this device, this will
be added in EVT hardware.
This was tested on the reef board by ensuring that the touchpad device
continues to work in the OS.
Also remove the LPC TPM from the DSDT as it is not present.
BUG=None
BRANCH=None
TEST=None
Change-Id: I3151a28f628e66f63033398d6fab9fd8f5dfc37b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15481
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/358583
Reviewed-by: Martin Roth <martinroth@chromium.org>
Support the I2C interfaces on this SOC using the Intel common lpss_i2c
driver. The controllers are supported in pre-ram environments by
setting a temporary base address in bootblock and in ramstage using
the naturally enumerated base address.
The base speed of this controller is 133MHz and the SCL/SDA timing
values that are reported to the OS are calculated using that clock.
This was tested on a google/reef board doing I2C transactions to the
trackpad both in verstage and in ramstage.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0a9d62cd1007caa95cdf4754f30c30aaff9f78f9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15480
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/358582
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add support for the soc_acpi_name() handler in the device operations
structure to translate a device path into ACPI name.
In order to make this more complete add some missing devices in
include/soc/pci_devs.h.
BUG=None
BRANCH=None
TEST=None
Change-Id: I517bc86d8d9fe70bfa0fc4eb3828681887239587
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15479
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/358581
Reviewed-by: Martin Roth <martinroth@chromium.org>
That function is no longer used. All users have been updated to
use the ulzman() function which specifies lengths for the input
and output buffers.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15526
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358580
Reviewed-by: Martin Roth <martinroth@chromium.org>
Boards broken with commit:
062ef1c AGESA boards: Split dispatcher to romstage and ramstage
Boot failure with asus/f2a85-m witnessed around MemMS3Save() call,
message "Save memory S3 data in heap" in verbose agesa logs was
replaced by a system reset.
Default stubs for MemS3ResumeConstructNBBlock() returned TRUE
without initializing the block contents. This would not work for case
with multiple NB support built into same firmware.
MemMCreateS3NbBlock() then returned with S3NBPtr!=NULL with uninitialized
data and MemMContextSave() referenced those as invalid pointers.
There is no reason to prevent booting in the case S3 resume data is not
passed to ramstage, so remove the ASSERT(). It only affects builds with
IDSOPT_IDS_ENABLED=TRUE anyways.
BUG=None
BRANCH=None
TEST=None
Change-Id: I8fd1e308ceab2b6f4b4c90f0f712934c2918d92d
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15344
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358388
Reviewed-by: Martin Roth <martinroth@chromium.org>
This linker error was the problem:
build/util/kconfig/zconf.tab.o: In function `conf_read_simple':
/home/jn/dev/coreboot/util/kconfig/confdata.c:413: undefined reference to `kconfig_warnings'
/home/jn/dev/coreboot/util/kconfig/confdata.c:413: undefined reference to `kconfig_warnings'
build/util/kconfig/zconf.tab.o: In function `sym_calc_value':
/home/jn/dev/coreboot/util/kconfig/symbol.c:388: undefined reference to `kconfig_warnings'
/home/jn/dev/coreboot/util/kconfig/symbol.c:388: undefined reference to `kconfig_warnings'
collect2: error: ld returned 1 exit status
/home/jn/dev/coreboot/util/kconfig/Makefile:339: recipe for target 'build/util/kconfig/gconf' failed
make: *** [build/util/kconfig/gconf] Error 1
BUG=None
BRANCH=None
TEST=None
Change-Id: I4a667c7c15b35618fb9ad536f2be5044b8031ab4
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/15505
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358387
Reviewed-by: Martin Roth <martinroth@chromium.org>
