Age | Commit message (Collapse) | Author |
|
This patch is based on a8a9f34e9b7b ("sb/intel/i82801{g,j}x:
Automatically generate ACPI PIRQ tables")
Tested on an ASRock H81M-HDS. The generated _PRT object looks correct,
and the system doesn't show any issue when running. The following
assignments occur:
ACPI_PIRQ_GEN: PCI: 00:02.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:03.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:14.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:16.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:1a.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:1b.0: pin=0 pirq=6
ACPI_PIRQ_GEN: PCI: 00:1c.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:1c.1: pin=1 pirq=1
ACPI_PIRQ_GEN: PCI: 00:1c.2: pin=2 pirq=2
ACPI_PIRQ_GEN: PCI: 00:1c.3: pin=3 pirq=3
ACPI_PIRQ_GEN: PCI: 00:1d.0: pin=0 pirq=7
ACPI_PIRQ_GEN: PCI: 00:1f.2: pin=1 pirq=3
ACPI_PIRQ_GEN: PCI: 00:1f.3: pin=2 pirq=2
Also tested on a Google Peppy board. The following assignments occur:
ACPI_PIRQ_GEN: PCI: 00:02.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:03.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:14.0: pin=0 pirq=2
ACPI_PIRQ_GEN: PCI: 00:1b.0: pin=0 pirq=6
ACPI_PIRQ_GEN: PCI: 00:1c.0: pin=0 pirq=0
ACPI_PIRQ_GEN: PCI: 00:1d.0: pin=0 pirq=3
ACPI_PIRQ_GEN: PCI: 00:1f.2: pin=0 pirq=6
ACPI_PIRQ_GEN: PCI: 00:1f.3: pin=1 pirq=2
ACPI_PIRQ_GEN: PCI: 00:1f.6: pin=2 pirq=1
A diff of the _PRT object for the Google Peppy board is below. The code
used in the diff has been modified for clarity, but the semantics remain
the same. To summarise the diff:
* The disabled PCIe root ports are no longer included.
* The LPC controller is no longer included, as it has no interrupt pin.
The pins for the remaining LPC devices are each one less. Perhaps the
original _PRT object was incorrect?
* The SDIO device is no longer included, as it is disabled.
* The Serial IO devices are no longer included, but that is due to a
separate issue I am having with this system (the devices don't show up
under Linux regardless of this patch). In short: their omission is not
a fault of this patch.
--- pre/_PRT
+++ post/_PRT
@@ -1,301 +1,157 @@
Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table
{
If (PICM)
{
- Return (Package (0x12)
+ Return (Package (0x09)
{
Package (0x04)
{
0x0002FFFF,
Zero,
Zero,
0x10
},
Package (0x04)
{
0x0003FFFF,
Zero,
Zero,
0x10
},
Package (0x04)
{
0x0014FFFF,
Zero,
Zero,
0x12
},
Package (0x04)
{
0x001BFFFF,
Zero,
Zero,
0x16
},
Package (0x04)
{
0x001CFFFF,
Zero,
Zero,
0x10
},
- Package (0x04)
- {
- 0x001CFFFF,
- One,
- Zero,
- 0x11
- },
-
- Package (0x04)
- {
- 0x001CFFFF,
- 0x02,
- Zero,
- 0x12
- },
-
- Package (0x04)
- {
- 0x001CFFFF,
- 0x03,
- Zero,
- 0x13
- },
-
Package (0x04)
{
0x001DFFFF,
Zero,
Zero,
0x13
},
Package (0x04)
{
0x001FFFFF,
Zero,
Zero,
0x16
},
Package (0x04)
{
0x001FFFFF,
One,
Zero,
0x12
},
Package (0x04)
{
0x001FFFFF,
0x02,
Zero,
0x11
- },
-
- Package (0x04)
- {
- 0x001FFFFF,
- 0x03,
- Zero,
- 0x10
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- Zero,
- Zero,
- 0x14
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- One,
- Zero,
- 0x15
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- 0x02,
- Zero,
- 0x15
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- 0x03,
- Zero,
- 0x15
- },
-
- Package (0x04)
- {
- 0x0017FFFF,
- Zero,
- Zero,
- 0x17
}
})
}
Else
{
- Return (Package (0x12)
+ Return (Package (0x09)
{
Package (0x04)
{
0x0002FFFF,
Zero,
^LPCB.LNKA,
Zero
},
Package (0x04)
{
0x0003FFFF,
Zero,
^LPCB.LNKA,
Zero
},
Package (0x04)
{
0x0014FFFF,
Zero,
^LPCB.LNKC,
Zero
},
Package (0x04)
{
0x001BFFFF,
Zero,
^LPCB.LNKG,
Zero
},
Package (0x04)
{
0x001CFFFF,
Zero,
^LPCB.LNKA,
Zero
},
- Package (0x04)
- {
- 0x001CFFFF,
- One,
- ^LPCB.LNKB,
- Zero
- },
-
- Package (0x04)
- {
- 0x001CFFFF,
- 0x02,
- ^LPCB.LNKC,
- Zero
- },
-
- Package (0x04)
- {
- 0x001CFFFF,
- 0x03,
- ^LPCB.LNKD,
- Zero
- },
-
Package (0x04)
{
0x001DFFFF,
Zero,
^LPCB.LNKD,
Zero
},
Package (0x04)
{
0x001FFFFF,
Zero,
^LPCB.LNKG,
Zero
},
Package (0x04)
{
0x001FFFFF,
One,
^LPCB.LNKC,
Zero
},
Package (0x04)
{
0x001FFFFF,
0x02,
^LPCB.LNKB,
Zero
- },
-
- Package (0x04)
- {
- 0x001FFFFF,
- 0x03,
- ^LPCB.LNKA,
- Zero
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- Zero,
- ^LPCB.LNKE,
- Zero
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- One,
- ^LPCB.LNKF,
- Zero
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- 0x02,
- ^LPCB.LNKF,
- Zero
- },
-
- Package (0x04)
- {
- 0x0015FFFF,
- 0x03,
- ^LPCB.LNKF,
- Zero
- },
-
- Package (0x04)
- {
- 0x0017FFFF,
- Zero,
- ^LPCB.LNKH,
- Zero
}
})
}
}
Change-Id: Id3f067cbf7c7d649fbbf774648d8ff928cb752a4
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ib39305effdb00e032ca07e6d0e0d84cdf3dcf916
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/29098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The assignment of header->checksum was in some cases done twice, or
unnecessarily split into two lines.
Change-Id: Ib0c0890d7589e6a24b11e9bda10e6969c7d73c56
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/28988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
Only for those that are x86 and also have a RW_LEGACY region.
The assumption is that all devices touched have 64k block sizes when
choosing size and alignment of the region.
Change-Id: I12addb137604f003d1296f34f555dae219330b18
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/28532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Most FADT report using ACPIv3 FADT table. Using the get revision
function keeps the table versions in sync.
Change-Id: Ie554faf1be65c7034dd0836f0029cdc79eae1aed
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/28277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ia38c6f8d978065090564d449cae11d54ddb96421
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28064
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
There is no need to redefine option present in
southbridge/intel/common/firmware/Kconfig.
Change-Id: I9999440031b07006e2df11e00dfb9f3dbe04f832
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/28007
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I3108193c0e0b644cecb74ae0c7a7b54e24a75b58
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/28049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I80dd65484fd52e9048635091fb20a123e959e999
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27869
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
With commits 9987534 [southbridge/intel: Remove leftover TPM ACPI code]
and 66ce18c [soc/intel: Remove legacy static TPM asl code] removing
TPM ASL code from the southbridge's LPCB device, the LPC TPM chip driver
(drivers/pc80/tpm) must be added to devicetree in order to ensure the
new acpigen code is used to replace it.
Test: boot various google/samsung boards, verify SSDT created with
LPBC.TPM device and TPM visible to and usable by SeaBIOS and Linux
Change-Id: Iedaa01f26fb357914549bb3dda24b0bd6ef67480
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/27786
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As per the ACPI specification, there are two types of power button
devices:
1. Fixed hardware power button
2. Generic hardware power button
Fixed hardware power button is added by the OSPM if POWER_BUTTON flag
is not set in FADT by the BIOS. This device has its programming model
in PM1x_EVT_BLK. All ACPI compliant OSes are expected to add this
power button device by default if the power button FADT flag is not
set.
On the other hand, generic hardware power button can be used by
platforms if fixed register space cannot be used for the power button
device. In order to support this, power button device object with HID
PNP0C0C is expected to be added to ACPI tables. Additionally,
POWER_BUTTON flag should be set to indicate the presence of control
method for power button.
Chrome EC mainboards implemented the generic hardware power button in
a broken manner i.e. power button object with HID PNP0C0C is added to
ACPI however none of the boards set POWER_BUTTON flag in FADT. This
results in Linux kernel adding both fixed hardware power button as
well as generic hardware power button to the list of devices present
on the system. Though this is mostly harmless, it is logically
incorrect and can confuse any userspace utilities scanning the ACPI
devices.
This change gets rid of the generic hardware power button from all
google mainboards and relies completely on the fixed hardware power
button.
BUG=b:110913245
TEST=Verified that fixed hardware power button still works correctly
on nautilus.
Change-Id: I733e69affc82ed77aa79c5eca6654aaa531476ca
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/27272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Tested on Google peppy (Acer C720).
Change-Id: I6453c40bf4ebe4695684c1bd3a403d6def82814f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/26835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Use of device_t has been abandoned in ramstage.
Use pci_devfn_t or pnp_devfn_t instead of device_t in romstage.
Change-Id: Ie0ae3972eacc97ae154dad4fafd171aa1f38683a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26984
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
* Remove 2nd software stack in pc80 drivers directory.
* Create TSPI interface for common usage.
* Refactor TSS / TIS code base.
* Add vendor tss (Cr50) directory.
* Change kconfig options for TPM to TPM1.
* Add user / board configuration with:
* MAINBOARD_HAS_*_TPM # * BUS driver
* MAINBOARD_HAS_TPM1 or MAINBOARD_HAS_TPM2
* Add kconfig TPM user selection (e.g. pluggable TPMs)
* Fix existing headers and function calls.
* Fix vboot for interface usage and antirollback mode.
Change-Id: I7ec277e82a3c20c62a0548a1a2b013e6ce8f5b3f
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/24903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I24fd33887152c12b9db9742af475115b02b31ff2
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Currently the throttle event handler method THRM is defined as an
extern on the intel bd82x6x and lynxpoint chipsets, then defined
again in the platform with thermal event handling. In newer versions
of IASL, this generates an error, as the method is defined in two
places. Simply removing the extern causes the call to it to fail on
platforms where it isn't actually defined, so add a preprocessor define
where it's implemented, and only call the method on those platforms.
This also requires moving the thermal handler, which now includes
the define to before the gnvs asl file.
TEST=Build before and after, make sure correct code is included.
Change-Id: I7af4a346496c1352ec20bda8acb338b5d277d99b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/26123
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use of device_t has been abandoned in ramstage.
Change-Id: I8e549e4222ae2ed6b9c46f81c5b5253e8b227ee8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/26086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Use SUPERIO_DEV for global control device instead of DUMMY_DEV.
Change-Id: If3555906d359695b2eae51209cd97fbaaace7e61
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/25852
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's very confusing trying to find the google platform names, because
they seem all unsorted in Kconfig. They're actually sorted according
to the variant name, but previously, that was impossible to tell.
- Add a comment to the top of variants in Kconfig.name
- Inset each variant name. If you start a prompt with whitespace,
it gets ignored, so after trying various ways to indent, the arrow
was the option I thought looked the best.
It now looks like this:
*** Beltino ***
-> Mccloud (Acer Chromebox CXI)
-> Monroe (LG Chromebase 22CV241 & 22CB25S)
-> Panther (ASUS Chromebox CN60)
-> Tricky (Dell Chromebox 3010)
-> Zako (HP Chromebox G1)
Butterfly (HP Pavilion Chromebook 14)
Chell (HP Chromebook 13 G1)
Cheza
*** Cyan ***
Change-Id: I35cb16b040651cd1bd0c4aef98494368ef5ca512
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/26020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Fix the values that were off by one.
This was discovered when using postcar stage that prints with
debuglevel BIOS_NEVER.
Change-Id: I73a077950ed0dc735d89c9747a8da0a25f30822d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Commit c09c2a4 [mb/google: Add Chromebook marketing names] added
marketing names for many ChromeOS devices; add some that were left out,
correct some errors, and try to format model names/numbers consistently
(or as consistently as the manufacturers allow).
Change-Id: Ia13858e2e6ba7d7e025f25fad33e6338250498e5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/22520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It's sometimes hard to find the code name of a Chromebook. Add the
marketing names to Kconfig, since they are easily available.
Information (mostly) taken from:
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
Unknown boards (unreleased, etc.):
* Fizz
* Foster
* Nasher, Coral
* Purin
* Rotor
* Rowan
* Scarlet, Nefario
* Soraka
* Urara
* Veyron_Rialto
Baseboards:
* Glados
* Gru
* Jecht
* Kahlee
* Nyan
* Oak
* Poppy
* Rambi
* Zoombini
White label boards:
* Enguarde
* Heli
* Relm, Wizpig
TODO: How does this interact with the board_status code?
Change-Id: I20a36e23bd3eea8c526a0b3b53cd676cebf9cd86
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/22404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There have been discussions about removing this since it does not seem
to be used much and only creates troubles for boards without defaults,
not to mention that it was configurable on many boards that do not
even feature uart.
It is still possible to configure the baudrate through the Kconfig
option.
Change-Id: I71698d9b188eeac73670b18b757dff5fcea0df41
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The LED polarity was set incorrectly, fix using values derived
from original Chromium sources:
branch firmware-mccloud-5827.B, ToT
src/mainboard/google/mccloud/smihandler.c
src/mainboard/google/mccloud/romstage.c
TEST: boot google/mccloud, observe power LED on normally,
blinking in S3/S4, and off in S5.
Change-Id: Ia1f63eebbccb48fcf8543188db390b23045d843e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21102
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I8febb8d74e2463622cab0313c543ceebec71fdf4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I1f906c8c465108017bc4d08534653233078ef32d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add capability and location data for USB ports/devices via
_PLD and _UPC ACPI methods, which is utilized by Windows and
required by macOS.
All beltino variants use the exact same USB port layout.
Change-Id: If5b540949ea071f7165876e12ac1ef50e62d2b22
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/19966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Haswell, Broadwell, Baytrail, and Braswell ChromeOS devices'
FADT version were incorrectly set to 3, rather than the correct
ACPI_FADT_REV_ACPI_3_0. The incorrect value resulted in these
devices reporting compliance to ACPI 2.0, rather than ACPI 3.0.
This mirrors similar recent changes to SKL and APL SoCs.
Test: boot any affected device and check ACPI version reported
vai FADT header using OS-appropriate tools.
Change-Id: I689d2f848f4b8e5750742ea07f31162ee36ff64d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/19498
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The virtualized developer switch was invented five years ago and has
been used on every vboot system ever since. We shouldn't need to specify
it again and again for every new board. This patch flips the Kconfig
logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with
CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to
set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the
latter for Lumpy which seems to have been omitted incorrectly, and hide
it from menuconfig since it's a hardware parameter that shouldn't be
configurable.)
Since almost all our developer switches are virtual, it doesn't make
sense for every board to pass a non-existent or non-functional developer
mode switch in the coreboot tables, so let's get rid of that. It's also
dangerously confusing for many boards to define a get_developer_mode()
function that reads an actual pin (often from a debug header) which will
not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set.
Therefore, this patch removes all those non-functional instances of that
function. In the future, either the board has a physical dev switch and
must define it, or it doesn't and must not.
In a similar sense (and since I'm touching so many board configs
anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC.
Instead, it should just be assumed by default whenever a Chrome EC is
present in the system. This way, it can also still be overridden by
menuconfig.
CQ-DEPEND=CL:459701
Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18980
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Simplify set_power_led() by consolidating switch and setting values
as needed inline based on LED state. Remove unnecesary function
param, includes for Tidus.
Change-Id: I28e6fac5f8d7e2ff419002db714ce88697895faf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17744
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Simplify set_power_led() by consolidating switch and setting values
as needed inline based on LED state.
Fix non-off LED polarity for Tricky using correct value from Chromium source
TEST: power on Tricky, observe LED lit / solid
Change-Id: I8bc7c4ae3f83d3f37b76fd5c90a4faed7057ebee
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17719
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ic22beaa47476d8c600e4081fc5ad7bc171e0f903
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17735
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ifeef04b68760522ce7f230a51f5df354e6da6607
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17734
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Combine existing board google/panther with new ChromeOS devices
mccloud, monroe, tricky, and zako, using their common reference board
(beltino) as a base.
Chromium sources used:
firmware-mccloud-5827.B 65bfee7 [haswell: No need pre-graphics delay...]
firmware-monroe-4921.B 1ac749d [Monroe: Disable KB/MS in ITE8772.]
firmware-tricky-5829.B 2db5322 [haswell: No need pre-graphics delay...]
firmware-zako-5219.B eacedef [haswell: No need pre-graphics delay...]
Existing google/panther board will be removed in a subsequent commit.
Variant setup modeled after google/reef
Change-Id: I5d7e0c2551e8b0707841032460c35615cefb2886
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17329
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|