Refer to section 7.9 Port Connector Information of DSP0134_3.3.0
to add type 8 data, the table of data should be ported according
to platform design and MB silkscreen.
Change-Id: I81e25d27c9c6717750edf1d547e5f4cfb8f1da14
Signed-off-by: BryantOu <Bryant.Ou.Q@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add a new LB_TAG_PLATFORM_BLOB_VERSION for FSP version, it would
add Intel FSP version to coreboot table LB_TAG_PLATFORM_BLOB_VERSION
when PLATFORM_USES_FSP2_0 is selected.
Tested=On OCP Delta Lake, with an updated LinuxBoot payload cbmem utility
can see "LB_TAG_PLATFORM_BLOB_VERSION": "2.1-0.0.1.120"
Change-Id: I92a13ca91b9f66a7517cfd6784f3f692ff34e765
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Replace uses with MAINBOARD_HAS_LPC_TPM, if drivers/pc80/tpm
is present in devicetree.cb it is necessary to always include
the driver in the build.
Change-Id: I9ab921ab70f7b527a52fbf5f775aa063d9a706ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner
1. Populate SMBIOS data from OCP_DMI driver read from FRU and PPIN MSR
for OEM string 1 to 6, add string 8 for PCIE configuration.
2. Set the read PPIN MSR to BMC.
Tested on OCP Delta Lake.
Change-Id: I9127cf5da1c56d8012694d070615aec24cc22fdf
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41279
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These changes are in accordance with the documentation:
[*] page 208-209
Intel(R) 64 and IA-32 Architectures, Software Developer’s Manual,
Volume 4: Model-Specific Registers. May 2019.
Order Number: 335592-070US
Tested on OCP Tioga Pass and Delta Lake.
Change-Id: I8c2eac055a065c06859a3cb7b48ed59f15ae2fc4
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42901
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's necessary to run IPMI commands in romstage for writing error SEL
such as memory initialization error SEL, and also for other usages
such as starting FRB2 timer, OEM commands, etc.
Add CONFIG_BMC_KCS_BASE for BMC KCS port address that can be used
across romstage and ramstage.
Change-Id: Ie3198965670454b123e570f9056673fdf515f52b
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40234
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A UPD HybridStorageMode allows a platform to dynamically configure the
PCIe strap configuration required if an Optane device is connected.
The strap configuration is done by HECI commands between FSP and CSE to
override the default PCIe strap value, and the updated strap value is
stored in SPI RW data to be used on the next boot.
CSE Lite supports the strap override when running on CSE RW partition,
while CSE RO partition does not support it because CSE RO is not allowed
to access SPI RW data. The strap override failure on CSE RO causes FSP
not initializing PCH Clkreq and PCIe port mapping and this results NVMe
and Optane initialization failure.
By disabling HybridStorageMode in case of CSE RO boot, NVMe detection is
done by the default PCIe configuration and Optane is detected as a
single NVMe storage device on CSE RO boot in recovery mode. Both NVMe
and Optane devices detection as well as OS installation to these storage
devices are verified on CSE RO boot in recovery mode.
BUG=b:158643194
TEST=boot and verified with tglrvp and volteer in recovery mode
Cq-Depend: chrome-internal:3100721
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Change-Id: I5397cfc007069debe3701bf1e38e81bd17a29f0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42282
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c531000f:
2020-05-18 20:55:55 +0000 - (vboot: Add recovery reason code for CSE Lite SKU errors)
to commit id 68de90c7:
2020-07-02 11:31:05 +0000 - (Allow building for non-CrOS environments)
This brings in 59 new commits.
Change-Id: I7f3c30511ff4acc60e3581bdab89d685dc7beaa5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43008
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The eSPI polarity macros were reversed. Those are fixed so adjust
the corresponding values related to the correct expectations of
the IRQ path: eSPI virtual wire IRQs are active level high. The EC
sends active level high virtual wire IRQs. The default interrupt
encodings in ACPI for P2/S devices are active edge high. Therefore,
there is no need to override anything.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia28d82cd9e432df98839f68bac4eae4447455e53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
eSPI interrupts are active level high. The eSPI polarity register
in the chipset inverts incoming signals if the corresonding bit
is 0 in the register. Therefore, all active high (edge or level)
virtual wire interrupts need to ensure they are not inverted.
And really the sender of the interrupts should be conforming to the
the eSPI spec. As such inverting any signals should not be necessary,
but this register in the chipset allows for fixing up those misbehaviors.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7346bb0484506d96d7ab2e6d046ffa0571683a48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Time Window Tau bits are only supported by Comet Lake/Cannon Lake
onwards, so skip setting those bits for earlier SoCs.
Change-Id: Iff899ee8280a9b9bbcea57d4e98b92d5410be21d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42979
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
V.2: Spare USB routed internally to another peripheral and so
no plug event hook needed.
BUG=b:1603699358,b:157479891
BRANCH=none
TEST=none
Change-Id: Ideacac417a46b96f3e82b53bbb341ecce79ee420
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42994
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Originally, there was problem with PC Engines apu1 platform
which returned serial number value as -64. It was caused by wrong
value of dev->bus->secondary.
Source of the problem is in Porting.h header file. It contains
'#pragma pack(1)' which affects struct device. As mainboard.c
uses different binary layout because of this attribute,
reference dev->bus->secondary lands at wrong memory address.
This patch reorder includes and put <AGESA.h> and <AMD.h>
at the end of list, making struct device consistent.
As a result bus number value in device's structure is correct
and hence serial number.
TEST=`dmidecode -t 2` command in Linux Debian
Signed-off-by: Piotr Kleinschmidt <piotr.kleinschmidt@3mdeb.com>
Change-Id: I5e8690d100b38ac7889395d375c0ff32bdefda0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42512
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reflow lines, correct coding style and align struct members, among
other things. As raminit is very large, handle it on a follow-up.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 does not change.
Change-Id: I343edf1bc2a5ac20ff0aa6de4486e685ce430737
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42701
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the generation of I2SM ACPI device from static asl
file to runtime generation by ACP device driver. dmic_select_gpio is
set to match version 3+ of Trembyle and Dalboz schematics. In order to
maintain backward compatibility, dmic_select_gpio is updated at
runtime using variant_audio_update for board versions that are prior
to version 3 of reference schematics.
The only difference from static generation is that the device I2SM is
added under ACPD (i.e. ACP device) instead of CREC (Chrome EC
device). It does not make any functional difference from the kernel
perspective.
BUG=b:157603026
TEST=Verified that the following device gets generated in SSDT:
Scope (\_SB.PCI0.PBRA.ACPD)
{
Device (I2SM)
{
Name (_HID, "AMDI5682") // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_DDN, "I2S machine driver") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x000D
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"dmic-gpios",
Package (0x04)
{
\_SB.PCI0.PBRA.ACPD.I2SM,
Zero,
Zero,
Zero
}
}
}
})
}
}
Verified audio via speakers and mic input.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I5d1602c7f719eef9487ddea68e429d27408f9a76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2253638
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds support in ACP device driver to generate I2S machine
device (AMDI5682) in SSDT. It expects mainboard to provide chip config
`dmic_select_gpio` that can be passed as `dmic-gpios` in _DSD for the
device.
BUG=b:157603026
TEST=Verified that I2S machine device is correctly generated for
trembyle.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I22ab53d7d68c6e042e467e598d688e360d28586f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2252557
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per ACPI spec, GpioIo does not have any polarity associated with
it. Linux kernel uses `active_low` argument within GPIO _DSD property
to allow BIOS to indicate if the corresponding GPIO should be treated
as active low. Thus, if GPIO has active high polarity or if it does
not have any polarity associated with it, then the `active_low`
argument is supposed to be set to 0.
Having a `polarity` field in acpi_gpio seems confusing because GPIOs
might not always have polarity associated with them. Example, in case
of DMIC-select GPIO where 0 means select DMIC0 and 1 means select
DMIC1, there is no polarity associated with the GPIO. Thus, it would
be clearer for mainboard to use macros without having to specify a
particular polarity. In order to enable mainboards to provide GPIO
information without polarity for GpioIo usage, this change also adds
`ACPI_GPIO_OUTPUT` and `ACPI_GPIO_INPUT` macros.
BUG=b:157603026
Change-Id: I39d2a6ac8f149a74afeb915812fece86c9b9ad93
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds helper macros for initializing acpi_gpio fields
for GpioIo/GpioInt objects. This allows dropping some redundant code
for each macro to set the structure fields.
Change-Id: Id0a655468759ed3035c6c1e8770e37f1275e344e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Proposal for gpio_regulator usage in ACPI never got accepted upstream
for Linux kernel. So, the gpio_regulator driver in coreboot remains
unused. This change drops this unused driver.
Change-Id: Ia1e0ae4f955b9ffc8346d957f755499419d8cbc7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Sonora Pass server program was terminated.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I5354ea1e912fd25f0ac9851edf0461413ad8bb21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42948
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ACPI code was not masking off the correct bits for publishing
the SPI bar to the OS.
It resulted in a dmesg messagelike:
system 00:00: [mem 0xfec10002-0xfec11001] has been reserved
And /proc/iomem entry
fec10002-fec11001 : pnp 00:00
These addresses are wrong because they are including bits of a
register that are not a part of the address.
Moreover, the code does not publish the eSPI register area either.
The eSPI registers live at 0x10000 added to the SPI bar. Lastly,
both regions are less than a page so only report a page of usage
for each.
Stoney Ridge's SPI bar register defines the address as 31:6 while
Picasso's SPI bar register defines the address as 31:8. Use Picasso's
valid mask for both cases because no one is assigning addresses
that are aligned to less than 256 bytes.
With the fixes, dmesg reports:
system 00:00: [mem 0xfec10000-0xfec10fff] has been reserved
system 00:00: [mem 0xfec20000-0xfec20fff] has been reserved
And /proc/iomem indicates:
fec10000-fec10fff : pnp 00:00
fec20000-fec20fff : pnp 00:00
BUG=b:160290629
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I130b5ad26d9e13b44c25fbb35a05389f9e8841ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42959
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify DPTF parameters for faffy from thermal team.
BUG=b:160292247
BRANCH=None
TEST=emerge-puff coreboot chromeos-bootimage
verify the parameters are correct
Change-Id: Ie8290f5460838f785a587c85b2ab7dd171dd0a54
Signed-off-by: Tim Chen <tim-chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
* Add support for Sphinx 3.0+
* Add backward support for Sphinx 1.8 and older
* Make sphinxcontrib ditaa an optional extension
* Allow SPHINXOPTS to be set from command line
* Add sphinx and sphinx-lint to top level Makefile
Change-Id: If10aef51dc426445cb742aad13b19ee7fe169c51
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41492
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just call the called function directly.
Change-Id: I0c997a63cbbd2b1029f94c23685847df910f8a0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, EC wake signal (GPIO_24) is configured early on in
romstage. However, there is no need for that since EC wake is not
really required to be configured until ramstage. This change moves
GPIO_24 configuration to happen in ramstage.
BUG=b:159832123
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I6949dcd7c866df2fa028c7b2e7f347cec988e309
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42952
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates the pad configurations for wake lines as
follows:
1. Pen eject wake signal needs to be configured as PAD_WAKE i.e. wake
using GPIO controller block. This is because pen eject signal is not
dual routed and the trigger filtering is set by the kernel driver
differently for S0 and S3 wake. Hence, it cannot use SCI GEVENT and
instead has to fall back to using GPIO controller wake.
2. All other wake signals (EC, trackpad, fingerprint) need to be
configured as SCI. This allows OS to enable/disable wake from these
sources if required. Example: powerd disables wake from trackpad when
in tablet mode. Hence, all other wake sources use SCI.
BUG=b:159832123
TEST=Verified wake using pen eject and EC.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id8cd5926f223db51a689ed8948040b8070cf1680
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42951
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set tcc_offset value to 10 in devicetree for Thermal Control
Circuit (TCC) activation feature.
BUG=None
BRANCH=None
TEST=Built for dedede platform and verified the MSR value
Change-Id: I53d1bd413c64643cf8bdaef266bde25a2f3a97ee
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42906
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, northbridge BARs are 32-bit values. We don't have any use
case for BARs above 4 GiB in early stages, so handling possibly 64-bit
values seems unnecessary, which currently is a noisy way to write zero.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 remains identical.
Change-Id: I93d1740b961f6a5962757d9a1e960b3f1014a0c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function was copy-pasted, comments included, from Sandy Bridge.
However, it is only called with 0x0044 as the northbridge's PCI ID.
Therefore, `bridge_silicon_revision() & BASE_REV_MASK` will always
evaluate to 0x40, which never equals `BASE_REV_SNB`, that is, 0x00.
As the condition is always false, treat this code as dead and drop it.
Following a similar reasoning, all direct comparisons against SNB
steppings will always be true, because `bridge_silicon_revision()`
returns at least 0x40 which is always larger than either `SNB_STEP_D0`
or `SNB_STEP_D1`. So, drop all but the code path that is actually used.
Change-Id: I5219a6af3df98ed77c9c4abfb9a63c2ebf8171bb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When building a configuration that requires futility (e.g. Chrome OS
builds), pkg-config and libcrypto are required. Since vboot's build
system isn't the most helpful about it, test ourselves and fail out
with some actionable message.
Tested:
- configs that don't need futility don't test for pkg-config, so it's
not required for them.
- failing pkg-config test leads to the message
- working pkg-config test leads to a successful build
Fixes https://ticket.coreboot.org/issues/242
Change-Id: I103ce5115284352e0a3a7fdcf8b427f56ce15ba7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Vboot determines openssl through pkgconfig, so pointing its build
system to /bin/true makes the build not break unless it needs to use
valid information about openssl.
Vboot's use of openssl is only for some special features, mostly around
PKCS key format parsing and not needed by cbfstool. While cbfstool
can link vboot, it can't link with openssl because openssl's license
is deliberately incompatible with the GPL.
Change-Id: Ia3825f9625a1964d7cefc47ab3c3a8250ceefafb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
BryantOu