Fix a linking problem with VBOOT and USE_OPTION_TABLE enabled.
Make use of cbfs_locate_file_in_region() and always search the
cmos_layout.bin in the 'COREBOOT' region.
With this change applied there's no need to include the vboot_locator
in SMM any more, we can't break NVRAM with different CMOS layouts,
and we keep VBOOT and non VBOOT behaviour the same.
Only include cmos_layout.bin and cmos.default in RO region.
Add notes explaining the decisions.
Tested on Intel Sandybridge, builds and boots with vboot enabled.
Change-Id: I10ae94d7936581bbb5ea49384122062bd4934ea5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put the PCIe clock pins in power-saving mode for the BayHub eMMC bridge to
save power. This requires use of an additional register (Misc control
register 2) and another bit in the existing 'protect' register. The naming
of bit 0 of that register is incorrect, based on the latest datasheet
(14 June 2018) so fix that too.
BUG=b:73726008
BRANCH=none
TEST=boot without this patch:
iotools mem_read32 0xfed80e00
0x0046ffff
With this patch:
$ iotools mem_read32 0xfed80e00
0x00463fff
Also see that the PCIe clock stops when eMMC is idle and can be started by
starting disk activity.
Change-Id: I5ad1467b2e2e151215d2dfd2ce48cd4a451fe480
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/26515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
i2c/alps driver implementation is an exact copy of the i2c/hid driver
with only the addition of ALPS0001_HID. This can be supported by the
i2c/hid driver using the hid field in devicetree which is what glkrvp
mainboard does. So, this change removes the i2c/alps driver which is
anyways unused.
Change-Id: I60761c384f3d800532b2b346272da7be28b77acd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Commit 77034fa [intel/common: compress VBT] compressed vbt.bin in
CBFS, but only changed the loader in soc/intel/common, forgetting
the separate one used by FSP 1.1.
As the soc/intel/common loader has now been rolled into the one in
drivers/intel/gma, replace the VBT loader used by FSP 1.1 with the GMA one.
Also, remove 2 now-unused header files.
Test: build/boot google/chell, observe display initialized prior
to OS load, no FSP warning in cbmem console due to invalid VBT signature.
Change-Id: Iba882ee4d9e83dcd88bdf7dd2f5591f66005a3fe
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/27169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds a new driver for the SX9310 proximity detector device.
The purpose of this is to enable the device's calibration information
to be stored in firmware, and then transferred over to the kernel
via ACPI.
This device has more than 10 individual configuration parameters,
so they would not fit in the generic driver's properties table.
Change-Id: Id8c434eec9fe2da731e142442503a12e88db2236
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://review.coreboot.org/27173
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Why would that be a user visible option? Drop the prompt and the
`default n` and select it automatically when needed. I hope I
caught all its users.
TEST=Confirmed that systems with ELOG_GSMI or DEBUG_SMI compile
and link.
Change-Id: I44aeec530cc333f4ed4c8cfe67c7b5c9d8fb0049
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Clean it up and add all flash chip drivers to postcar stage thereby.
There seem to be SPI controllers that don't need the individual
flash chip drivers. For those postcar support was added in b6b1b23
(console/flashconsole: Enable support for postcar). However for
SPI controllers that need the individual drivers (i.e. those with
CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS=y), linking of the postcar
stage was broken.
For all other stages, the set of compilation units stays the same.
Change-Id: Ib8bdb824bfcf2d31ac696e39f797c4355b765756
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26871
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the i210 MACPHY is operated in the SERDES Backplane mode (which
depends on the programmed firmware image), its PCI-ID will be 0x1537.
This does however not change the programming interface for the MAC
address.
Therefore add this new PCI-ID to the driver so that the MAC address can
be programmed in this operation mode as well.
Change-Id: I608535202c49e40690381c2b2ab26322d62cfb37
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/26683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As far as I can see this Kconfig option was used wrong ever since it
was added. According to the commit message of 107f72e (Re-declare
CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR), it was only necessary
to prevent overlapping with CAR.
Let's handle the potential overlap in C macros instead and get rid
of that option. Currently, it was only used by most FSP1.0 boards,
and only because the `fsp1_0/Kconfig` set it to CBFS_SIZE (WTF?).
Change-Id: I4d0096f14a9d343c2e646e48175fe2127198a822
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It doesn't make sense to log post codes from a previous (failed) boot
if we are resuming from S3, since the previous boot has to have been
successful in order to enter S3 in the first place.
While we are at it, use a helper function to combine conditionals and
improve readability.
BUG=none
TEST=boot, suspend & resume grunt
Change-Id: I4f3bb8526a0c8c0ea1efd924628b33c147543b88
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/26528
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previously, we were unconditionally adding a TYPE_BOOT message to the ELOG
on every boot (even S3 resume) if CONFIG_ELOG_BOOT_COUNT was disabled.
Now that boot_count_read() returns 0 for the !CONFIG_ELOG_BOOT_COUNT
case, the code becomes a bit simpler.
BUG=b:79865267
TEST=firmware_EventLog
Change-Id: I803fa4c3e03b6cc94751cf0ce34b78021ae2124e
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/26527
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a support for generating USB port descriptors for ACPI based
on their definition by the board in devicetree.cb. This will
generate a _UPC and _PLD for each port, using a generic _PLD by
default. The _PLD can also be customized for more accurate
descriptions if necessary.
This sample devictree.cb shows a USB 2.0 type-A port behind a root
hub connected to an xHCI controller:
device pci 14.0 on
chip drivers/usb/acpi
register "desc" = ""Root Hub""
register "type" = "UPC_TYPE_HUB"
device usb 0.0 on
chip drivers/usb/acpi
register "desc" = ""USB 2.0 Type-A""
register "type" = "UPC_TYPE_A"
device usb 2.0 on end
end
end
end
end
It will generate the following ACPI code in the SSDT:
Scope (\_SB.PCI0.XHCI.RHUB.HS01)
{
Name (_DDN, "USB 2.0 Type-A")
Name (_UPC, Package (0x04)
{
0xFF,
0x00,
Zero,
Zero
})
Name (_PLD, ToPLD (
PLD_Revision = 0x2,
PLD_IgnoreColor = 0x1,
PLD_Red = 0x0,
PLD_Green = 0x0,
PLD_Blue = 0x0,
PLD_Width = 0x0,
PLD_Height = 0x0,
PLD_UserVisible = 0x1,
PLD_Dock = 0x0,
PLD_Lid = 0x0,
PLD_Panel = "UNKNOWN",
PLD_VerticalPosition = "CENTER",
PLD_HorizontalPosition = "CENTER",
PLD_Shape = "RECTANGLE",
PLD_GroupOrientation = 0x0,
PLD_GroupToken = 0x0,
PLD_GroupPosition = 0x0,
PLD_Bay = 0x0,
PLD_Ejectable = 0x0,
PLD_EjectRequired = 0x0,
PLD_CabinetNumber = 0x0,
PLD_CardCageNumber = 0x0,
PLD_Reference = 0x0,
PLD_Rotation = 0x0,
PLD_Order = 0x0,
PLD_VerticalOffset = 0x0,
PLD_HorizontalOffset = 0x0)
)
}
Change-Id: I7024390e407fda4b195211bd4755bb5ca53b2b37
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/26173
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is a special case for the Fizz firmware branch, when the device index
is 1, it will check "ethernet_mac" first and then "ethernet_mac0".
For single NIC: config.device_index = "1", maps to "ethernet_mac"
For multiple NICs: config.device_index = "1", maps to "ethernet_mac0"
BUG=b:77836343
BRANCH=Fizz
TEST=Add device index in device tree &&
Program the mac address to VPD in shell
vpd -s ethernet_mac=<mac address> or
vpd -s ethernet-mac[0-9]=<mac address> && reboot the system.
Ensure the MAC address was fetched correctly by ifconfig command.
Change-Id: I67fd2e999c8f9d8782f294fcafa84b8da970a3a6
Signed-off-by: David Wu <david_wu@quantatw.com>
Reviewed-on: https://review.coreboot.org/26051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Had 0x2e hardcoded, which is often the SuperIO chip. Instead,
pull the port from the PNP tree generated from devicetree.cb,
where either 0x4e or 0x2e will be specified.
Change-Id: I4a92693f8acd3a1618cefcdf6b25eb22a727e20f
Signed-off-by: Kevin Cody-Little <kcodyjr@gmail.com>
Reviewed-on: https://review.coreboot.org/26203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
In 4a3956d7 (drivers/intel/gma, soc/intel/common: improve
cooperation) the vbt_size parameter was not honored leading to
the use of unitialized variables from the caller. Instead, keep
track of if the vbt is already loaded by using the size returned
from the load. If it's non-zero the vbt has been loaded.
BUG=b:79562868
Change-Id: Ia1c47f0d982fae74e0223922f83943c68a846aa9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26236
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of both featuring their own VBT loaders, use a single one.
It's the compression-enabled one from soc/intel/common, but moved to
drivers/intel/gma.
The rationale (besides making all the Kconfig fluff easier) is that
drivers/intel/gma is used in some capacity on all platforms that load a
VBT, while soc/intel/common's VBT code is for use with FSP.
BUG=b:79365806
TEST=GOOGLE_FALCO and GOOGLE_CHELL both build, exercising both affected
code paths.
Change-Id: I8d149c8b480e457a4f3e947f46d49ab45c65ccdc
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/26039
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Non-dts based systems can pass mclk to da7219 driver by
this property.
BUG=b:74570989
TEST=Enabled clock in kernel driver using the property
Change-Id: I2e10769e5b3c6b3aa30f340fe0e88c29b87430cb
Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Reviewed-on: https://review.coreboot.org/25919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
