Break TPM related Kconfig into the following dimensions:
TPM transport support:
config CRB_TPM
config I2C_TPM
config SPI_TPM
config MEMORY_MAPPED_TPM (new)
TPM brand, not defining any of these is valid, and result in "generic" support:
config TPM_ATMEL (new)
config TPM_GOOGLE (new)
config TPM_GOOGLE_CR50 (new, implies TPM_GOOGLE)
config TPM_GOOGLE_TI50 (new to be used later, implies TPM_GOOGLE)
What protocol the TPM chip supports:
config MAINBOARD_HAS_TPM1
config MAINBOARD_HAS_TPM2
What the user chooses to compile (restricted by the above):
config NO_TPM
config TPM1
config TPM2
The following Kconfigs will be replaced as indicated:
config TPM_CR50 -> TPM_GOOGLE
config MAINBOARD_HAS_CRB_TPM -> CRB_TPM
config MAINBOARD_HAS_I2C_TPM_ATMEL -> I2C_TPM && TPM_ATMEL
config MAINBOARD_HAS_I2C_TPM_CR50 -> I2C_TPM && TPM_GOOGLE
config MAINBOARD_HAS_I2C_TPM_GENERIC -> I2C_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_LPC_TPM -> MEMORY_MAPPED_TPM
config MAINBOARD_HAS_SPI_TPM -> SPI_TPM && !TPM_GOOGLE && !TPM_ATMEL
config MAINBOARD_HAS_SPI_TPM_CR50 -> SPI_TPM && TPM_GOOGLE
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I4656b2b90363b8dfd008dc281ad591862fe2cc9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This was originally several commits that had to be squashed into one
because the intermediate states weren't able to build coreboot:
- one to remove everything that wasn't our own code, leaving only
regex.[ch], toada.c, description.md and Makefile.inc.
- one to copy in Linux 5.13's scripts/kconfig and adapt Makefile.inc
to make the original Makefile work again.
- adapt abuild to use olddefconfig, simplifying matters.
- apply patches in util/kconfig/patches.
- Some more adaptations to the libpayload build system.
The patches are now in util/kconfig/patches/, reverse applying them
should lead to a util/kconfig/ tree that contains exactly the Linux
version + our own 5 files.
Change-Id: Ia0e8fe4e9022b278f34ab113a433ef4d45e5c355
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Soft straps, that can be configured by the vendor in the Intel Flash
Image Tool (FIT), can influence some pads' default state. It is possible
to select either a native function or GPIO mode for some pads on
non-server SoCs, while on server SoCs most pads can be controlled.
Thus, add a recommendation to always configure all pads for a board to
guarantee integrity between different board or vendor firmware revisions
where the soft straps might have been changed.
Change-Id: I33063a3f6a1c9cd5267d85f7da84deb554489a26
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Intel PDGs starting from Skylake / Sunrise Point state that, different
from the general recommendation in digital electronics, unconnected
GPIOs defaulting to GPIO mode do explicitly not require termination.
The reason for this is, that these GPIOs have the `GPIORXDIS` bit set,
which effectively disconnects the pad from the internal logic by
disabling the input buffer.
This bit - besides `GPIOTXDIS` - can also be set explicitly by using
the gpio macro `PAD_NC(pad, NONE)`.
In some cases, a pull resistor may be required due to bad board design
or when a vendor sets the RX/TX disable bits together with a pull
resistor and schematics are not available to check if the pad is really
unconnected or just unused. In this case the pull resistor should be
kept.
Pads defaulting to native functions usually don't need special handling.
However, when pads requiring external pull-ups are missing these due to
bad board design, they should be configured with `PAD_NC` to disconnect
them internally.
Rewrite the documentation to reflect these new findings.
Also clarify the comment in soc/intel gpio code accordingly.
Change-Id: Id01b197ebe8f2b8bb4ecf3d119ec2298b26d9be0
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52139
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop LPC pad configuration code since all boards now do pad
configuration on their own. The comment about LPC_CLKRUNB when using
eSPI is moved to `Documentation/getting_started/gpio.md`.
Change-Id: I710d6aee8c3b2c8282cd321cd0688b9b26abea07
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49410
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the declaration is done after the default, menuconfig will see that
symbol defined at the first place where kconfig tool will find it.
For example, if we run menuconfig and search for 'MAINBOARD_VENDOR', we
will see it defined at ""src/mainboard/51nb/Kconfig" which is odd.
Change-Id: I215a1817e60e6deb6931679f139d110ba762d3c8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
They're more or less the same but reworked for hopefully some more
clarity. There have been some best practices around documenting the
reason for expedited processing so let's make them official, too.
Change-Id: I620e48016a1ceda2ac43f26624ed21af01f6a0a5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43484
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This macro is not correct because the RX Level/Edge Configuration
(trig) and the GPIO Tx/Rx Buffer Disable (bufdis) fields in DW0
register do not affect on the pad in the native function mode.
This is part of the patch set
"src/mb/*, src/soc/intel/common/gpio: Remove PAD_CFG_NF_BUF_TRIG ":
CB:43455 - cedarisland: undo set trig and bufdis for NF pads
CB:43454 - tiogapass: undo set trig and bufdis for NF pads
CB:43561 - h110m: undo set trig and bufdis for NF pads
CB:43569 - soc/intel/common/gpio_defs: Remove PAD_CFG_NF_BUF_TRIG
Change-Id: Ic0416e3f67016c648f0886df73f585e8a08d4e92
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Michael Niewöhner
The resource allocator woes post-4.12 release showed room for
improvement on both discussion and documentation. To encourage this
(and encourage reviewers to look out for issues in that space),
extend the review guidelines so that they encourage to more clearly
document the reason for a change with the change (commit message or
our documentation) and also to loop in the mailing list.
Change-Id: I1962dba3fe7e1a01fa4c8b0058297c7d050cb7b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Martin Roth
Jes B. Klinke
Subrata Banik
Felix Singer
Patrick Georgi
Martin Roth
Yu-Ping Wu
Michael Niewöhner
Paul Menzel
Elyes HAOUAS
Jonathan Zhang
Maxim Polyakov