With this change, the type-unsafe {get,set}_option() API functions are
no longer used directly. The old API gets dropped in a follow-up.
Change-Id: Id3f3e172c850d50a7d2f348b1c3736969c73837d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52512
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new configuration low_power_probe to avoid camera privacy LED
blink during the boot.
Change-Id: I27d5c66fb380ae6cd76d04ee82b7736407dac1b0
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52189
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The selector component in Sound Open Firmware (SOF) can consume all the
mics and use the configuration in the Use Case Manager (UCM) to select
the right channel. Hence dmic select gpio configuration is optional.
BUG=b:182960979
TEST=Build and boot to OS in Guybrush. Ensure that the machine driver
ACPI object is populated without DMIC select GPIO.
Change-Id: Iba00b07c3656c487e33bab184fefee7037745e2d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52393
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
IPMI debug was extra spewy, so add a debug option as SPI and
other drivers have when they need to be debugged.
Change-Id: I788d67c242cac23bde9750aa3e95e3276c3f1fd7
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Traditionally, for each Intel platform using FSP, FSP-S has at some
point configured GPIOs differently than the mainboard configuration in
coreboot. This has resulted in various side-effects in coreboot,
payload and OS because of misconfigured GPIOs. On more recent Intel
platforms, a UPD `GpioOverride` is added that coreboot can use to
ensure that FSP does not touch any GPIO configuration.
This change adds a debug option `CHECK_GPIO_CONFIG_CHANGES` to fsp2_0
driver in coreboot that makes a platform callback `gpio_snapshot` to
snapshot GPIO configuration before making a call to FSP SiliconInit
and Notify phases. This snapshot is then compared against the GPIO
configuration using platform callback `gpio_verify_snapshot` after
returning from FSP. The callbacks are not added to romstage (FSP-M)
because mainboard configures all pads in ramstage.
This debug hook allows developers to dump information about any pads
that have a different configuration after call to FSP in ramstage. It
is useful to identify missed UPD configurations or bugs in FSP that
might not honor the UPDs set by coreboot.
This debug hook expects the platform to implement the callbacks
`gpio_snapshot` and `gpio_verify_snapshot`. These can be implemented
as part of the common GPIO driver for platforms using
FSP2.0+. Platforms that implement this support must select the config
`HAVE_GPIO_SNAPSHOT_VERIFY_SUPPORT` to make the debug config
`CHECK_GPIO_CONFIG_CHANGES` visible to user.
Proposal for the GPIO snapshot/verify support was discussed in the RFC
CB:50829.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I5326fc98b6eba0f8ba946842253b288c0d42c523
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50989
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a driver for the TI TAS5825M smart amplifier [1].
The driver expects the mainboard using it to define tas5825m_setup(),
which uses the tas5825m_* functions to set configuration data. Each
mainboard may have very different configuration data, depending on
its audio hardware.
Tested on System76 addw1, bonw14, oryp5, and oryp6.
[1]: https://www.ti.com/product/TAS5825M
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I896e8f272f18e64bfc90f406e7d4163010800aaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the Intel MMA driver to use the new CBFS API.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icc11d0c2a9ec1bd7a1d6af362f849dac16375433
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch ports the last remaining use of cbfs_boot_locate() in the
Intel FSP drivers to the new CBFS API. As a consequence, there is no
longer a reason for fsp_validate_component() to operate on rdevs, and
the function is simplified to take a direct void pointer and size to a
memory-mapping of the FSP blob instead.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If1f0239eefa4542e4d23f6e2e3ff19106f2e3c0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52281
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPTF HIDs are different per-platform going forward, so refactor these
into SoC-specific structures which the DPTF driver can query at runtime
for platform-specific information.
Change-Id: I6307f9d28f4274b851323ad69180ff4ae35053da
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Rename the Kconfig parameter to more accurately reflect what it does.
TPM can be initialised in a different stage too, for instance with
VBOOT it is done in verstage.
Change-Id: Ic0126b356e8430c04c7c9fd46d4e20022a648738
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
This guards code accessing the vboot context which does not exist if
vboot starts after romstage.
Change-Id: I2a38daa00d6d18df9c5e22858530814e23bb3e00
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Add definitions to describe GPIOs in generated ACPI objects.
The method allow either write a GpioInt() or Interrupt() descriptor.
Signed-off-by: Seven Lee <wtli@nuvoton.com>
Change-Id: I37fec7b0b9324dbfb61b7a8bea80f45026c54409
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51922
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TPM_INIT depends on VBOOT but should also depend on
VENDORCODE_ELTAN_xBOOT.
Add dependency. TPM_INIT will be enable for measured boot only.
BUG = NA
TEST = Boot Facebook FB1701 with possible combinaties of VBOOT, measured
boot and eltan security.
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Change-Id: I03f8457731c73c653bd82b1042bda3fc2d797feb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
The only FSP 1.1 platform with MMA support is Skylake. As it now uses
Kaby Lake FSP 2.0, this code is no longer useful. Drop it.
Change-Id: I819c3152bdea0fdad629793d96136ef134429fbd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The Intel FSP 2.0 driver contains a custom construct that basically
serves the same purpose as the new CBFS allocator concept: a callback
function to customize placement of a loaded CBFS file whose size is
initially unknown. This patch removes the existing implementation and
replaces it with a CBFS allocator.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0b7b446a0d2af87ec337fb80ad54f2d404e69668
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Until now every AML package had to be closed using acpigen_pop_len().
This commit introduces set of package closing functions corresponding
with their opening function names. For example acpigen_write_if()
opens if-statement package, acpigen_write_if_end() closes it.
Now acpigen_write_else() closes previously opened acpigen_write_if(),
so acpigen_pop_len() is not required before it.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Icfdc3804cd93bde049cd11dec98758b3a639eafd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since prog_locate() was eliminated, prog_rdev() only ever represents the
loaded program in memory now. Using the rdev API for this is unnecessary
if we know that the "device" is always just memory. This patch changes
it to be represented by a simple pointer and size. Since some code still
really wants this to be an rdev, introduce a prog_chain_rdev() helper to
translate back to that if necessary.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If7c0f1c5698fa0c326e23c553ea0fe928b25d202
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IPMI OEM command set processor information has already been implemented
in u-root payload:
efdc3a30ec
Also this command has a higher chance to see BMC KCS timeout issue when
coreboot log level is 4, which can be avoided if this command is run at
a later stage such as LinuxBoot.
Signed-off-by: JingleHsuWiwynn <jingle_hsu@wiwynn.com>
Change-Id: If0081e5195cbd605e062723c197ac74343f79a13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51276
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that SAR support in VPD is deprecated in coreboot, there is no
need for a separate Kconfig `WIFI_SAR_CBFS` as the SAR table is only
supported as a CBFS file. This change drops the config `WIFI_SAR_CBFS`
from drivers/wifi/generic/Kconfig and its selection in
mb/google/.../Kconfig.
wifi_sar_defaults.hex is added to CBFS only if
CONFIG_WIFI_SAR_CBFS_FILEPATH is not empty because current mainboards
do not provide a default SAR file in
coreboot. Thus, CONFIG_WIFI_SAR_CBFS_FILEPATH is updated to have a
default value of "".
BUG=b:173465272
Cq-Depend: chromium:2757781
Change-Id: I0bb8f6e2511596e4503fe4d8c34439228ceaa3c7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch rewrites the last few users of prog_locate() to access CBFS
APIs directly and removes the call. This eliminates the double-meaning
of prog_rdev() (referring to both the boot medium where the program is
stored before loading, and the memory area where it is loaded after) and
makes sure that programs are always located and loaded in a single
operation. This makes CBFS verification easier to implement and secure
because it avoids leaking a raw rdev of unverified data outside the CBFS
core code.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7a5525f66e1d5f3a632e8f6f0ed9e116e3cebfcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
From ALSA reviewer suggest to change the name to RTL1015.
Details in below threads:
https://www.spinics.net/lists/alsa-devel/msg123395.html
BUG=b:177971830
TEST=: ALC1015P driver can probe properly.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I2762852bdc3164346e3618c373aa4d3336415653
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Missing acpi_dp_write and correct the name from sdb to sdb-gpios for
driver.
BUG=b:177971830
TEST: ALC1015P driver can get sdb-gpio properly.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I2728a7dad695d5c97e85c5d86b1effea1595da65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51379
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
EFI_PEI_MP_SERVICES_STARTUP_ALL_APS passes in a boolean flag singlethread
which indicates whether the work should be scheduled in a serially on all APs
or in parallel. Current implementation of this function mp_startup_all_aps
always schedules work in parallel on all APs. This implementation ensures
mp_startup_all_aps honors to run serialized request.
BUG=b:169114674
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: I4d85dd2ce9115f0186790c62c8dcc75f12412e92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51085
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current driver is using chip registers map to configure the SAR
sensor, which is opaque, especially when the datasheet is not published
widely.
Use more descriptive names, as defined in Linux kernel documentation at
https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/proximity/semtech%2Csx9310.yaml
BUG=b:173341604
BRANCH=volteer
TEST=Dump all tables, check semtech property:
for i in $(find /sys/firmware/acpi/tables/ -type f) ; do
f=$(basename $i); cat $i > /tmp/$f.dat ; iasl -d /tmp/$f.dat
done
In SSDT.dsl, we have:
Package (0x06)
{
Package (0x02)
{
"semtech,cs0-ground",
Zero
},
Package (0x02)
{
"semtech,startup-sensor",
Zero
},
Package (0x02)
{
"semtech,proxraw-strength",
Zero
},
Package (0x02)
{
"semtech,avg-pos-strength",
0x0200
},
Package (0x02)
{
"semtech,combined-sensors",
Package (0x03)
{
Zero,
One,
0x02
}
},
Package (0x02)
{
"semtech,resolution",
"finest"
}
}
Change-Id: I8d1c81b56eaeef1dbb0f73c1d74c3a20e8b2fd7b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch pulls control of the memory pool serving allocations from the
CBFS_CACHE memlayout area into cbfs.c and makes it a core part of the
CBFS API. Previously, platforms would independently instantiate this as
part of boot_device_ro() (mostly through cbfs_spi.c). The new cbfs_cache
pool is exported as a global so these platforms can still use it to
directly back rdev_mmap() on their boot device, but the cbfs_cache can
now also use it to directly make allocations itself. This is used to
allow transparent decompression support in cbfs_map().
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0d52b6a8f582a81a19fd0fd663bb89eab55a49d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use lowercase `port` in both the spec and the body.
Change-Id: I3d1e2abe03eedcaf57716af444a3e3b8a61b60d4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In commit 2609eaaa8f (src/drivers/i2c/rx6110sa: Omit _HID temporarily)
the randomly assigned and therefore wrong ACPI ID for RTC RX6110SA was
removed. In the meantime Seiko-Epson did a great job and registered an
official vendor ID in the ACPI database [1]. Further on, Seiko-Epson
has now assigned the unique Product Identifier for the RX6110SA, which
is '6110'. The assignment of the Product Identifier is controlled by
the vendor and there is no official database where this ID is stored
in. It is up to the vendor to make sure that this ID stays unique.
This patch adds this new vendor and product ID to the driver. Together
with a pending Linux patch this RTC is now useable as ACPI device in
Linux.
[1] https://uefi.org/ACPI_ID_List?search=SECC
Change-Id: I45838162f014a760520692c6dcaae329ad98547d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51176
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Johannes Hahn <johannes-hahn@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RAM is not yet configured in bootblock. This function was copy-pasted
from Broadwell. Also, Skylake no longer uses FSP 1.1 and the stubs in
there can be removed as nothing else uses them.
Change-Id: I22cb7e63ed1e9565934296fd40771130ba91d227
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50949
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds new soundwire device ALC1308
The codec properties are filled out as best as possible
with the datasheet as a reference.
The ACPI address for the codec is calculated with the information in
the codec driver combined with the devicetree.cb hierarchy where the
link and unique IDs are extracted from the device path.
The unique ID is calculated from schematics by referring to ASEL[1:0]
strap settings. Datasheet of ALC1308 provides info about the mapping of
ASEL strap settings to unique ID
For example this device is connected to master link ID 1 and has strap
settings configuring it for unique ID 2.
chip drivers/soundwire/alc1308
register "desc" = ""Left Speaker""
device generic 1.2 on end
end
Bug=None
Test=Build and boot on TGLRVP.Extract SSDT and confirm that the entries for
PCI0.HDAS.SNDW are present for ALC1308
Test speaker out functionality
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ibf3f1d5c6881cbd106e96ad1ff17ca216aa272ac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51042
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sathyanarayana Nujella
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From JSL FSP v2376 "FirmwareVersionInfo.h" header file is
added and "FirmwareVersionInfoHob.h" is deprecated. This patch
adds support to display firmware version information using
"FirmwareVersionInfo.h" header file.
Changes included in this patch:
- Add Kconfig to select FirmwareVersionInfo.h
- Add code change to display firmware version info using
FirmwareVersionInfo.h header
No change in version info print format.
BUG=b:153038236
BRANCH=None
TEST=Verify JSLRVP build with all the patch in relation chain
and verify the version output prints no junk data observed.
couple of lines from logs are as below.
Display FSP Version Info HOB
Reference Code - CPU = 8.7.16.10
uCode Version = 0.0.0.1
Change-Id: I50f7cae9ed4fac60f91d86bdd3e884956627e4b5
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
FSP expects mp_get_processor_info to give processor specfic apic ID,
core(zero-indexed), package(zero-indexed) and thread(zero-indexed) info.
This function is run from BSP for all logical processor, With current
implementation the location information returned is incorrect per logical
processor. Also the processor id returned does not correspond to the
processor index, rather is returned only for the BSP.
BUG=b:179113790
Change-Id: Ief8677e4830a765af61a0df9621ecaa372730fca
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50880
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the UPD size in coreboot sizes mismatches the one from the FSP-M
binary, we're running into trouble. If the expected size is smaller than
the UPD size the FSP provides, call die(), since the target buffer isn't
large enough so only the beginning of the UPD defaults from the FSP will
get copied into the buffer. We ran into the issue in soc/amd/cezanne,
where the UPD struct in coreboot was smaller than the one in the FSP, so
the defaults didn't get completely copied.
TEST=Mandolin still boots.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia7e9f6f20d0091bbb4abfd42abb40b485da2079d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50241
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
coreboot sets up CLK_PM, ASPM, and L1ss automatically based on related
bits in "Link Capability Register" and "L1 PM Substates Capabilities
Register". coreboot overrides these configs even if the driver sets
them. Therefore, setting up CLK_PM, ASPM, and L1ss in the driver is
redundant and useless.
BUG=b:177955523
BRANCH=zork
TEST="lspci -vvvv" prints are identical with and without this patch;
LV2_LINK_CTRL(0x90) is 0x00110102 with and without this patch.
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I17c19f4271da426ac2b926b948378dc88131e95a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
coreboot sets up certain configs (e.g. L1ss) based on the device's
reported capacities; however, this BayHub lv2 driver modifies some
of its capacities after coreboot uses them. Therefore, coreboot may
make incorrect configs based on out-of-date capacities.
This patch moves the driver from ".init" to ".enable" so that the
capacities are set before the rest of coreboot queries them.
BUG=b:177955523
BRANCH=zork
TEST="lspci -vvvv" reported "PCI-PM_L1.2-" and "ASPM_L1.2-" on L1SubCtl1
of both PCI device "00:01.3" and "02.00.0"
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I857b7c7c6732bbd26de561052affa3a3e7e25737
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As per HID over I2C Protocol Specification[1] Version 1.00 Section 7.4,
the interrupt line used by the device is required to be level triggered.
This change ensures that the IRQ is appropriately configured.
References:
[1] http://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx
BUG=b:172846122
TEST=./util/abuild/abuild. Build and boot to OS in Dedede.
Change-Id: I3245a9de6e88cd83528823251083e62288192f0d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Enforcing the exact match of FSPS UPD block size between FSP and
coreboot mandates simultaneous updates to coreboot and FSP repos. Allow
coreboot to proceed if its UPD structure is smaller than FSP one. This
usually indicates that FSPS has an updated (larger) UPD structure which
should be soon matched/updated on the coreboot side to keep them in
sync.
While this is an undesirable situation that should be corrected
ASAP, it is safe from coreboot perspective. It is safe (as long as
default values in FSP UPD are sane enough to boot) because FSPS UPD
buffer is allocated on the heap with the size specified in FSPS
(larger) and filled with FSPS default values. This allows FSP UPD
changes to be submitted first followed by changes in coreboot repo.
Note that this only applies to the case when entire FSPS UPD structure
grows which should be rare as FSP should allocate enough reserve space,
anticipating future expansion, to keep the structure from growing when
new members are added.
BUG=b:171234996
BRANCH=Zork
TEST=build Trembyle
Change-Id: I557fd3a1f208b5b444ccf76e1552e74ecf4decad
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Only the call in `spi_flash_cmd_write_page_program` uses non-constant
values for the array length. However, the value for `data_len` has an
upper bound: `flash->page_size` is set to `1U << vi->page_size_shift`
which depends on the flash chip vendor info, and the largest value it
can currently have is 8. Thus, the maximum page size is currently 256.
Define the `MAX_FLASH_CMD_DATA_SIZE` macro to place an upper bound on
the amount of data that can be written in one command. Then, use this
value to allocate a fixed-size buffer in `spi_flash_cmd_write`. Also,
add a check to prevent buffer overflow problems. Finally, ensure that
the `spi_flash_cmd_write_page_program` function always writes no more
than 256 bytes of data when using the `spi_flash_cmd_write` function.
Tested on Asrock B85M Pro4 (Winbond W25Q64FV), MRC cache still works.
Change-Id: Ib630bff1b496bc276616989d4506a3c96f242e26
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
ACPI S3 is a global state and it is no longer needed to
pass it as a parameter.
Change-Id: Id0639a47ea65c210b9a79e6ca89cee819e7769b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Hide the detail of allocation from cbmem from the FSP.
Loading of a BMP logo file from CBFS is not tied to FSP
version and we do not need two copies of the code, move
it under lib/.
Change-Id: I909f2771af534993cf8ba99ff0acd0bbd2c78f04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add support for MP services2 PPIs, which is slight modification
over MP services 1 PPIs. A new API StartupAllCPUs have been added
to allow running a task on BSP and all APs. Also the EFI_PEI_SERVICES
parameter has been removed from all MP PPI APIs.
This implementation also selects the respective MP services PPI version
supported for SoCs
BUG=b:169196864
Change-Id: Id74baf17fb90147d229c78be90268fdc3ec1badc
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change drops the config FSP_PEIM_TO_PEIM_INTERFACE.
FSP_PEIM_TO_PEIM_INTERFACE is used for:
* Auto-selecting FSP_USES_MP_SERVICES_PPI
* Including src/drivers/intel/fsp2_0/ppi/Kconfig
* Adding ppi to subdirs-y
* Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y
and is selected by SoCs that want to enable MP PPI services.
Instead of using the indirect path of selecting MP PPI services, this
change allows SoC to select FSP_USES_MP_SERVICES_PPI directly. The
above uses are handled as follows:
* Auto-selecting FSP_USES_MP_SERVICES_PPI
--> This is handled by SoC selection of FSP_USES_MP_SERVICES_PPI.
* Including src/drivers/intel/fsp2_0/ppi/Kconfig
--> The guard isn't really required. The Kconfig options in this
file don't present user prompts and don't really need to be guarded.
* Adding ppi to subdirs-y
--> Makefile under ppi/ already has conditional inclusion of files
and does not require a top-level conditional.
* Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y
--> This is set to y if FSP_USES_MP_SERVICES_PPI is selected by SoC.
TEST=Verified that timeless build for brya, volteer, icelake_rvp,
elkhartlake_crb and waddledee shows no change in generated coreboot.rom
Change-Id: I0664f09d85f5be372d19925d47034c76aeeef2ae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50274
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a driver which puts the device into power-saving mode.
BUG=b:177955523
BRANCH=zork
TEST=boot and see this message:
BayHub LV2: Power-saving enabled 110102
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Change-Id: Idc1340b1a6fe7063d16c8ea16488d6e2b8b308cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add new Kconfig symbols to mark FSP binary as x86_32.
Fix the FSP headers and replace void pointers by fixed sized integers
depending on the used mode to compile the FSP.
This issue has been reported here:
https://github.com/intel/FSP/issues/59
This is necessary to run on x86_64, as pointers have different size.
Add preprocessor error to warn that x86_64 FSP isn't supported by the
current code.
Tested on Intel Skylake. FSP-M no longer returns the error "Invalid
Parameter".
Change-Id: I6015005c4ee3fc2f361985cf8cff896bcefd04fb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* Use probe_resource instead of find_resource. This prevents
a call to die and instead returns NULL.
* Handle the case where BAR2 isn't present
* Don't hardcode legacy VGA when BAR2 is present. This fixes
graphic initialisation when the Aspeed isn't the primary GPU
and thus doesn't decode VGA cycles.
This makes the coreboot code more similar to the Linux kernel code.
Change-Id: I2a99712a562a57c65f1cd0df7b1d7606681afe9b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50195
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BH720 PCR registers are accessed using an index/data register pair.
Introduce some helper functions to clarify the PCR register operations.
Change-Id: I1a48b10071af20dca61b7dd90c5a70bc9d1089b4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
1. These are common OCP/Facebook IPMI OEM commands, move from mainboard
into drivers/ipmi/ocp to avoid code duplication and provide better
reusability.
2. OCP Tioga Pass enables IPMI_OCP driver.
Tested=On OCP Delta Lake and Tioga Pass verify the commands still work
correctly.
Change-Id: Idd116a89239273fd5cc7b06c7768146085a3ed69
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Allow platforms to use the coreboot postcar code instead of calling
into FSP-M TempRamExit API.
There are several reasons to do this:
- Tearing down CAR is easy.
- Allows having control over MTRR's and caching in general.
- The MTRR's set up in postcar be it by coreboot or FSP-M are
overwritten later on during CPU init so it does not matter.
- Avoids having to find a CBFS file before cbmem is up (this
causes problems with cbfs_mcache)
Change-Id: I6cf10c7580f3183bfee1cd3c827901cbcf695db7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48466
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case of a mismatch print both the UPD signature in the FSP and the
expected signature and then calls die(), since it shouldn't try calling
into the wrong FSP binary for the platform.
Signed-off-by: Justin Frodsham <justin.frodsham@protonmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I469836e09db6024ecb448a5261439c66d8e65daf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Factor out the condition when an attempt to load
stage from cache can be tried.
Change-Id: I936f07bed6fc82f46118d217f1fd233e2e041405
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The function has only one local call-site.
Change-Id: I623953796e6cd3a8e5b4f72293d953b61f14a5a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49999
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Except for one debug print in sarien, both functions are identical.
Move them to driver code to avoid unnecessary redundancy.
Change-Id: I82635a289e3c05119eab4ee1f7a6bf3a8a1725c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
It was confusing to have this defined while there was another
symbol bootblock_protected_mode_entry that was not really used
as an entry point.
Change-Id: I3da07ba9c0a9fc15b1515452adfb27f963659951
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48404
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to FSP_INFO_HEADER structure in FSP EAS v2.0-v2.2,
BIT1 indicates an "official" build.
Change-Id: I94df6050a1ad756bbeff60cda0ebac76ae5f8249
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There's no need to repeat the same code on every board.
Change-Id: I2e19decfe8609fa644e609673a56ee5109bafefa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49831
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the "ERROR:" tag so that it ease debug effect.
TEST=Test tools like "suspend_stress_test" (specific to Chrome OS) can
identify the obvious coreboot ERROR prior running S3 resume test.
Change-Id: I64717ce0412d43697f42ea2122b932037d28dd48
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49798
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to update the BB retimers for usb4/tbt they need to be turned
on and into TBT mode. Expand the current DSM to allow for the use of an
EC RAM byte RFWU to get the current state of each port and whether or
not it has a retimer. It also allows Kernel to issue state transitions
for the retimer to be put into TBT mode for firmware update.
BUG=b:162528867
TEST=Along with work in progress kernel and EC patches, the Retimer
firmware update is verified under device attached and no device attached
scenarios.
Change-Id: I768cfb56790049c231173b0ea0f8e08fe6b64b93
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The `clear` command for SMMSTORE version 1 does not require a parameter.
Change-Id: I992b7ce5962bf7ee62b7e1970ae7aa1b975ef42e
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49724
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
prog_locate() will load FSP, before CBMEM is initialized.
The vboot workbuffer is used for loading, but
CBMEM_ID_VBOOT_WORKBUF is not available.
A NULL pointer is returned as workbuffer resulting in error
'Ramstage was not loaded!' at second boot.
Initialize CBMEM before calling prog_locate().
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I2f04a326a95840937b71f6ad65a7c011268ec6d6
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This will remove "CONFIG_FRU_DEVICE_ID=0" from ".config" when unused.
Change-Id: Ic50de165c1f3de3886d3cd1ae66853c9fad35ed2
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Having some symmetry with <soc/nvs.h> now allows to reduce
the amount of gluelogic to determine the size and cbmc field
of struct global_nvs.
Since GNVS creation is now controlled by ACPI_SOC_NVS,
drivers/amd/agesa/nvs.c becomes obsolete and soc/amd/cezanne
cannot have this selected until <soc/nvs.h> exists.
Change-Id: Ia9ec853ff7f5e7908f7e8fc179ac27d0da08e19d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
By default, the HS400 mode of GL9763E is slow mode (150MHz).
Therefore, the slow mode is disabled for HS400 running at 200MHz.
For eMMCs such as Hynix (H26M74002HMR) on HS400, adjust the internal
Rx latch dealy of HS400 to have better compatibility.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I84844c2432d4223d9929182c5c430915e52875b7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Booting on Kingston (EMMC64G-TA29/TX29-HP) and Hynix (H26M74002HMR) eMMC
currently fails due to R/W error. This is a workaround to finetune the
data latch timing by verdor-specific setting of GL9763E. For improving
the compatibility of GL9763E with these two eMMC.
Signed-off-by: Renius Chen <reniuschengl@gmail.com>
Change-Id: Iddb145ed6a9edb2d7a50248e64659cda78b88ae6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Allocation now happens prior to device enumeration. The
step cbmem_add() is a no-op here, if reached for some
boards. The memset() here is also redundant and becomes
harmful with followup works, as it would wipe out the
CBMEM console and ChromeOS related fields without them
being set again.
Change-Id: I9b2625af15cae90b9c1eb601e606d0430336609f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48701
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For arch/x86 the realmode part has to be located within the same 64
KiB as the reset vector. Some older intel platforms also require 4 KiB
alignment for _start16bit.
To enforce the above, and to separate required parts of .text without
matching *(.text.*) rules in linker scripts, tag the pre-C environment
assembly code with section .init directive.
Description of .init section for ELF:
This section holds executable instructions that contribute to the
process initialization code. When a program starts to run, the
system arranges to execute the code in this section before calling the
main program entry point (called main for C programs).
Change-Id: If32518b1c19d08935727330314904b52a246af3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add functions to read the system and mainboard serial numbers
from VPD tables stored in flash.
Remove board-specific implementations for google/drallion and
google/sarien and select the new Kconfig instead.
Test: build/boot google/akemi with RO_VPD region persisted from
stock Google firmware, verify system/mainboard serial numbers
present via dmidecode.
Change-Id: I14ae07cd8b764e1e22d58577c7cc697ca1496bd5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49050
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, use of the VPD driver to read VPD tables from flash
requires the use of a custom FMAP with one or more VPD regions.
Extend this funtionality to boards using the default FMAP by
creating a dedicated VPD region when the driver is selected.
Test: build qemu target with CONFIG_VPD selected, verify entry
added to build/fmap.fmd.
Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add a new macro `GMA_DEFAULT_PANEL(ssc)` as shortcut for specifying one
internal panel at port A (0) in the devicetree.
Change-Id: I5308b53667657d0b255ae5bc543f1a00431f5818
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are multiple different devicetree setting formats for graphics
panel settings present in coreboot. Replace the ones for the platforms
that already have (mostly) unified gma/graphics setup code by a unified
struct in the gma driver. Hook it up in HSW, BDW, SKL, and APL and adapt
the devicetrees accordingly.
Always ensure that values don't overflow by applying appropriate masks.
The remaining platforms implementing panel settings (GM45, i945, ILK and
SNB) can be migrated later after unifying their gma/graphics setup code.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I445defe01d5fbf9a69cf05cf1b5bd6c7c2c1725e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
which select INTEL_GMA_ACPI. Rework brightness level includes and
platform-level asl files to avoid duplicate device definition for GFX0.
Include gfx.asl for Skylake/Kabylake, since all other soc/intel/common
platforms already do. Adjust mb/51nb/x210 to prevent device redefinition.
Some OSes (e.g. Windows, MacOS) require/prefer the ACPI device for
the IGD to exist, even if ACPI brightness controls are not utilized.
This change adds a GFX0 ACPI device for all boards whose platforms
select INTEL_GMA_ACPI without requiring non-functional brightness
controls to be added at the board level.
Change-Id: Ie71bd5fc7acd926b7ce7da17fbc108670fd453e0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add the right register values for backlight control to CNL's Kconfig.
To make iasl happy about the reversed register order, split the field.
Change-Id: I05a06cc42397c202df9c9a1ebc72fb10da3b10ec
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some server boards like OCP Tiogapass and X11-LGA1151 boards use a gpio
for signalling "POST complete" to BMC/IPMI. Add a new driver devicetree
option to set the gpio and configure a callback that pulls the gpio low
right before jumping to the payload.
Test: Check that sensor readings appear in BMC web interface when the
payload gets executed.
Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with
CB:48711 and OCP DeltaLake with CB:48672.
Change-Id: I34764858be9c7f7f1110ce885fa056591164f148
Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Some boards, like the Supermicro X11SSM-F, have a jumper for enabling or
disabling the BMC and IPMI. Add a new devicetree driver option to set
the GPIO used for the jumper and enable or disable IPMI according to its
value.
This gets used in a follow-up change by Supermicro X11SSM-F.
Test: Boot with jumper set to each enabled and disabled and check debug
log if IPMI gets enabled/disabled accordingly.
Successfully tested on Supermicro X11SSM-F with CB:48095.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Icde3232843a7138797a4b106560f170972edeb9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The register `ESR` conflicts with the `Exception syndrome register` in
UDK2017. To resolve the conflict, drop the unused `ESR` register from
gma registers. It can be readded and prefixed or renamed if it's
required at a later point.
Change-Id: Icfdd834aea59ae69639a180221f5e97170fbac15
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We missed that Cannon Point, the PCH usually paired with Coffee, Whiskey
and Comet Lake, differs a bit from its predecessors. Hence, libgfxinit
now has a new Kconfig setting for the PCH.
Change-Id: I1c02c0d9abb7340aabe94185ee5e17ef4c2b0d36
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add a new driver for OEM commands and select it from x11-lga1151-series.
The driver communicates the BIOS version and date to the BMC using OEM
commands. The command should be supported on all X11 series mainboards,
but might work with older BMC, too.
Tested on X11SSH-TF:
The BIOS version strings are updated on boot and are visible in the
BMC web UI.
Change-Id: I51c22f83383affb70abb0efbcdc33ea925b5ff9f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The latest version defined by TCG is 1.3.
Change-Id: Idb12e2212d6d38c720c8fe989678724c871af6ef
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45569
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement the ACPI PPI interface as described in
"TCG PC Client Physical Presence Interface Specification" Version 1.3.
Add a new Kconfig that allows to use the full PPI instead of the stub
version compiled in.
This doesn't add code to execute the PPI request, as that's up to the
payload with graphical UI support.
Tested on GNU/Linux 5.6 using the sysfs interface at:
/sys/class/tpm/tpm0/ppi/
Change-Id: Ifffe1d9b715e2c37568e1b009e86c298025c89ac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45568
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a different FSP binary was chosen in menuconfig, the split fd files
do not get updated. Thus, make them depend on `.config` to trigger a
rebuild when the config changes.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I54739eae50fa1a47bf8f3fe2e79334bc7f7ac3d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently it's not possible to add multiple graphics driver into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics driver can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple indepent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace set_vbe_mode_info_valid with fb_add_framebuffer_info or
fb_new_framebuffer_info_from_edid.
Change-Id: I95d1d62385a201c68c6c2527c023ad2292a235c5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Currently it's not possible to add multiple graphics drivers into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics drivers can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace all duplications of fill_fb_framebuffer and provide a single one
in edid_fill_fb.c. Should not change the current behaviour as still only
one graphic driver can be active at time.
Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some former commits (e.g. Ieb41771c75aae902191bba5d220796e6c343f8e0)
blindly assume that dev->chip_info is capable to be dereferenced,
making at least compilers complain about potential null pointer
dereference. They might cause crash if truly (dev->chip_info == NULL).
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I1d694b12f6c42961c104fe839d4ee46c0f111197
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Configure the CFG2 register to set the latency to <64us in order
to ensure the L1 exit latency is consistent across devices and that
L1 ASPM is always enabled.
This moves the setup code from device init to device enable so it
executes before coreboot does ASPM configuration, and removes the
call to pci_dev_init() as that is just for VGA Option ROMs.
BUG=b:173207454
TEST=Verify the device and link capability and control for L1:
DevCap: Latency L1 <64us
LnkCap: Latency L1 <64us
LnkCtl: ASPM L1 Enabled
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ie2b85a6697f164fbe4f84d8cd5acb2b5911ca7a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Stack is set up for bootblock.
Tested on Facebook FBG1701.
Change-Id: I0dd3fc91c90bf76e0d93925da35dc197d68d3e88
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47802
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DRIVER_I2C_TPM_ACPI is used to enable the "driver" needed for coreboot
to present a TPM node in the devicetree. It would usually only do so,
if coreboot itself is communicating with the TPM via I2C (I2C_TPM).
However, technically, there is no dependency.
In order to not show the ACPI option in menuconfig if the board is not
using I2C, a dependency was declared in Kconfig. However, the same can
be achieved without making it an error to manually declare
DRIVER_I2C_TPM_ACPI without I2C_TPM.
For Volteer, we have just such a need, since it has two "sub-variants"
sharing the same overridetree.cb, one having SPI TPM and another having
I2C TPM. The former will have a disabled ACPI node representing the I2C
TPM, while its Kconfig is such that coreboot itself does not have I2C
TPM support.
In order to export even a disabled ACPI node representing the I2C
connected TPM, coreboot needs DRIVER_I2C_TPM_ACPI. Hence, that will
have to be enabled in a case where coreboot does not have I2C_TPM (for
one of the two sub-variants, namely volteer2).
BUG=b:173461736
TEST=Tested as part of next CL in chain
Change-Id: I9717f6b68afd90fbc294fbbd2a5b8d0c6ee9ae55
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48222
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use a wrapper code that does nothing on x86_32, but drops to protected
mode to call into FSP when running on x86_64.
Tested on Intel Skylake when running in long mode. Successfully run the
FSP-M which is compiled for x86_32 and then continued booting in
long mode.
Change-Id: I9fb37019fb0d04f74d00733ce2e365f484d97d66
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48202
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Export all registers that driver is looking for. And put in alphabetic order.
The missing registers for kernel v5.4 sx93xx are:
reg_irq_msk
reg_irq_cfg0
reg_irq_cfg2
reg_afe_ph0/1/2/3
BUG=b:172397658
BRANCH=zork
TEST=Build passed
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ic9d7a959b1769b6846bba302e3aeab9a3a1cedac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47866
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When FSP-T is used, the first thing done in postcar is to call FSP-M
to tear down CAR. This is done before cbmem is initialized, which
means CBFS_MCACHE is not accessible, which results in FSP-M not being
found, failing the boot.
TESTED: ocp/deltalake boots again.
Change-Id: Icb41b802c636d42b0ebeb3e3850551813accda91
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48282
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Once the console's FMAP region is full, we stop clearing the line
buffer and `line_offset` is not reset anymore. Hence, sanity check
`line_offset` everytime before writing to the buffer.
The issue resulted in boot hangs and potentially a brick if the
log was very verbose.
Change-Id: I36e9037d7baf8c1ed8b2d0c120bfffa58c089c95
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48074
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces two new CBFS API functions which are equivalent to
cbfs_map() and cbfs_load(), respectively, with the difference that they
always operate on the read-only CBFS region ("COREBOOT" FMAP section).
Use it to replace some of the simple cases that needed to use
cbfs_locate_file_in_region().
Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The current location for the sensor initialization procedure was chosen
by mistake. Move this into a separate function in nct7802y.c .
Change-Id: I093ae75db5f0051bff65375b0720c86642b9148a
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This pollutes the log on all platforms not implementing an override.
Change-Id: I0d8371447ee7820cd8e86e9d3d5e70fcf4f91e34
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48128
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit bd31642ad8 (intel/i210: Set bus master bit in command register)
is only necessary because a buggy OS expects Bus Master to be set, not
because the hardware requires Bus Master during initialization. It is
thus safe to defer the Bus Master request into the .final callback.
Change-Id: Iecfa6366eb4b1438fd12cd9ebb1a77ada97fa2f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47401
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: siemens-bot
Define and use the MAC_ADDR_LEN macro in place of the `6` magic value.
Change-Id: Icfa2ad9bca6668bea3d84b10f613d01e437ac6a2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47404
Tested-by: siemens-bot
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Move the FSP FD PATH option down, so it gets shown in place of the split
FD files, when the users chooses to use a full FD binary.
Change-Id: Ie03a418fab30a908d020abf94becbaedf54fbb99
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, setting a custom FSP binary is only possible by using split
FSP-T/M/S FD files. This change introduces the possibility to pass a
combined FD file (the "standard" FSP format).
This is done by adding a new boolean Kconfig FSP_FULL_FD, specifying
that the FSP is a single FD file instead of split FSP-T/M/S FD files,
and making FSP_FD_PATH user-visible when the option is chosen. In this
case, the other options for split files get hidden.
When the user chooses to use a full FD file instead of the split ones,
the FD file gets split during build, just like it is done when selecting
the Github FSP repo (FSP_USE_REPO).
Test: Supermicro X11SSM-F builds and boots fine with custom FSP FD set.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I1cb98c1ff319823a2a8a95444c9b4f3d96162a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
As preparation to a full PPI implementation move the acpi code out
of the pc80/tpm/tis driver into the generic tpm driver folder.
This doesn't change any functionality.
Change-Id: I7818d0344d4a08926195bd4804565502717c48fa
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Follow model of drivers/i2c/generic and use user-supplied device
name if specified in the chip config.
Change-Id: Ia783bac2797e239989c03a3421b9293a055db3d0
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47782
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DDN field isn't required, no point in writing an empty string to it.
Change-Id: Ifea6e48c324598f114178e86a79f519ee35f5258
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47781
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a new driver for the SX9324 proximity detector device.
Follow SX9324 datasheet Rev3.
BUG=b:172397658
BRANCH=zork
TEST=Test sx9324 is working as expected.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ifd582482728a2f535ed85f6696b2f5a4529ba421
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47640
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols.
Tested on Facebook FBG1701
Change-Id: Ice748e542180f6e1dc1505e7f37b6b6c68772bda
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Whole car region is cleared, while only small part needs to be done.
Clear .bss area only
Tested on Facebook FBG1701
Change-Id: I021c2f7d3531c553015fde98d155915f897b434d
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only need to check this once so check it at romstage where
the console is usually ready. Also define union fsp_revision
to avoid code duplication.
Change-Id: I628014e05bd567462f50af2633fbf48f3dc412bc
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Top of Temp RAM is used as bootloader stack, which is the
_car_region_end area. This area is not equal to CAR stack area as
defined in car.ld file.
Use _ecar_stack (end of CAR stack) as starting stack location.
Tested VBOOT, Vendorboot security and no security on Facebook FBG1701.
Change-Id: I16b077f60560de334361b1f0d3758ab1a5cbe895
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47737
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot might not store wifi SAR values in VPD and may store it in
CBFS. Logging the message with 'error' severity may interfere
with automated test tool.
Lowering severity to BIOS_DEBUG avoids this issue.
BUG=b:171931401
BRANCH=None
TEST=Severity of message is reduced and we don't see it as an error
Change-Id: I5c122a57cfe92b27e0291933618ca13d8e1889ba
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The current HID "RX6110SA" does not comply with the ACPI spec in terms
of the naming convention where the first three caracters should be a
vendor ID and the last 4 characters should be a device ID. For now
there is a vendor ID for Epson (SEC) but there is none for this
particular RTC. In order to avoid the reporting of a non ACPI-compliant
HID it will be dropped completely for now.
Once Epson has assigned a valid HID for this RTC, this valid HID will be
used here instead.
Change-Id: Ib77ffad084c25f60f79ec7d503f14731b1ebe9e2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47706
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This Kconfig option was just added incorrectly, so would never add
the verstage.c file.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4c39dca9d429ed786ea42c0d421d6ee815e8c419
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The CONFIG_TPM_I2C_BURST_LIMITATION was never added, so this has never
been turned on. The Kconfig linter generates three warnings about this
block:
Warning: Unknown config option CONFIG_TPM_I2C_BURST_LIMITATION
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I53fa8f5b4eac6a1e7efec23f70395058bad26299
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47367
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a trivial patch to fix some comments that were generating
notes in the kconfig lint test.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I26a95f17e82910f50c62215be5c29780fe98e29a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47366
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the host sends data in i2c bus, device might not send ACK. It means
that data is not processed on the device side, but for now we don't
check for that condition thus wait for the response which will not come.
Designware i2c detect such situation and set TX_ABORT bit. Checking for
the bit will enable other layers to immediately retry rather than
wait-timeout-retry cycle.
BUG=b:168838505
BRANCH=zork
TEST=test on zork devices, now we see "Tx abort detected" instead of I2C
timeout for tpm initializtion.
Change-Id: Ib0163fbce55ccc99f677dbb096f67a58d2ef2bda
Signed-off-by: Kangheui Won <khwon@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently the decision of whether or not to use mrc_cache in recovery
mode is made within the individual platforms' drivers (ie: fsp2.0,
fsp1.1, etc.). As this is not platform specific, but uses common
vboot infrastructure, the code can be unified and moved into
mrc_cache. The conditions are as follows:
1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain
switch is true)
2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this
means that memory training will occur after verified boot,
meaning that mrc_cache will be filled with data from executing
RW code. So in this case, we never want to use the training
data in the mrc_cache for recovery mode.
3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this
means that memory training happens before verfied boot, meaning
that the mrc_cache data is generated by RO code, so it is safe
to use for a recovery boot.
4. Any platform that does not use vboot should be unaffected.
Additionally, we have removed the
MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the
mrc_cache driver takes care of invalidating the mrc_cache data for
normal mode. If the platform:
1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data
2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set
BUG=b:150502246
BRANCH=None
TEST=1. run dut-control power_state:rec_force_mrc twice on lazor
ensure that memory retraining happens both times
run dut-control power_state:rec twice on lazor
ensure that memory retraining happens only first time
2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig
boot twice to ensure caching of memory training occurred
on each boot.
Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The defines for RX6110SA_SLAVE_ADR and RX6110SA_I2C_CONTROLLER are not
used anymore and can be deleted.
Change-Id: I3cddf7a9e2f757a22c729ae0f0ff767d55909b9c
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: siemens-bot
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This patch adds basic ACPI support for the RTC so that the OS is able to
use this RTC via the ACPI interface.
If the Linux kernel is able to find the RTC in ACPI scope, you should
see the following lines in dmesg, where [n] is an enumerated number:
rx6110 i2c-RX6110SA:00: rtc core: registered RX6110SA:00 as rtc[n]
rtc rtc[n]: Update timer was detected
Change-Id: I9b319e3088e6511592075b055f8fa3e2aedaa209
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
CB:46865 ("mb, soc/intel: Reorganize CNVi device entries in
devicetree") reorganized the devicetree entries to make the
representation of CNVi device consistent with other internal PCI
devices. Since a dummy generic device is added for the CNVi device,
`emit_sar_acpi_structures()` needs to first check if the device is PCI
before checking the vendor ID. This ensures that SAR table generation
is skipped only for PCIe devices with non-Intel vendor IDs and not for
the dummy generic device.
BUG=b:165105210
Change-Id: I3c8d18538b94ed1072cfcc108552f3a1ac320395
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Some devices, such as cameras, can implement a physical switch to
disable the input on demand. Think of it like the typical privacy
sticker on the notebooks, but more elegant.
In order to notify the system about the status this feature, a GPIO is
typically used.
The map between a GPIO and the feature is done via ACPI, the same way as
the reset_gpio works.
This patch implements an extra field for the described privacy gpio.
This gpio does not require any extra handling from the power management.
BUG=b:169840271
Change-Id: Idcc65c9a13eca6f076ac3c68aaa1bed3c481df3d
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Allow a USB device to define PowerResource in its SSDT AML code.
PowerResouce ACPI generation expects SoC to define the callbacks for
generating AML code for GPIO manipulation.
Device requiring PowerResource needs to define following parameters:
* Reset GPIO - Optional, GPIO to put device into reset or take it out
of reset.
* Reset delay - Delay after reset GPIO is asserted (default 0).
* Reset off delay - Delay after reset GPIO is de-asserted (default 0).
* Enable GPIO - Optional, GPIO to enable device.
* Enable delay - Delay after enable GPIO is asserted (default 0).
* Enable off delay - Delay after enable GPIO is de-asserted (default 0).
BUG=b:163100335
TEST=Ensure that the Power Resource ACPI object is added under the
concerned USB device.
Change-Id: Icc1aebfb9e3e646a7f608f0cd391079fd30dd1c0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46713
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Peichao Wang <pwang12@lenovo.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Tigerlake FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Commit cf5d58328f had changed
the size from 8 to 9 Kib. This change adds Kconfig option to choose
vbt data size based on platform.
BUG=b:171401992
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: Ia294fc94ce759666fb664dfdb910ecd403e6a2e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47151
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Individual drivers check whether the concerned device is enabled before
filling in the SSDT. Move the check before calling acpi_fill_ssdt() and
remove the check in the individual drivers.
BUG=None
TEST=util/abuild/abuild
Change-Id: Ib042bec7e8c68b38fafa60a8e965d781bddcd1f0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Create SOC_INTEL_COMMON_FSP_RESET Kconfig to have IA common code block
to handle platform reset request raised by FSP. The FSP will use the
FSP EAS v2.0 section 12.2.2 (OEM Status Code) to indicate that a reset
is required.
Make FSP_STATUS_GLOBAL_RESET depends on SOC_INTEL_COMMON_FSP_RESET.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I934b41affed7bb146f53ff6a4654fdbc6626101b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols:
Change-Id: I8d79f97f8c12c63ce215935353717855442a8290
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change replaces the checks for dev->enabled with the helper
function `is_dev_enabled()`.
Change-Id: Iacceda396c9300bbfa124e76fb9c99d86313ea0f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46904
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops the PCI IDs for Jefferson Peak and Harrison Peak
CNVi modules from wifi/generic drivers as well as pci_ids.h. These IDs
actually represent the CNVi WiFi controller PCI IDs and are now
supported by intel/common/block/cnvi driver.
The only ID that is being dropped without adding support in
intel/common/block/cnvi driver is
PCI_DEVICE_ID_HrP_6SERIES_WIFI(0x2720) since this was not found in the
list of PCI IDs for any SoC.
Change-Id: I82857a737b65a6baa94fb3c2588fe723412a7830
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46866
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reorganizes drivers/wifi/generic to add a new
device_operations structure for dummy CNVi device. This is done to
make the organization of CNVi PCI device in devicetree consistent
with all the other internal PCI devices of the SoC i.e. without a chip
around the PCI device.
Thus, with this change, CNVi entry in devicetree can be changed from:
```
chip drivers/wifi/generic
register "wake" = "xxyyzz"
device pci xx.y on end # CNVi PCI device
end
```
to:
```
device pci xx.y on
chip drivers/wifi/generic
register "wake" = "xxyyzz"
device generic 0 on end # Dummy CNVi device
end
end # CNVi PCI device
```
The helper functions for ACPI/SMBIOS generation are also accordingly
updated to include _pcie_ and _cnvi_ in the function name.
Change-Id: Ib3cb9ed9b81ff8d6ac85a9aaf57b641caaa2f907
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46862
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change splits `wifi_generic_fill_ssdt()` into following two
functions:
1. `wifi_ssdt_write_device()`: This function writes the device, its
address, _UID and _DDN.
2. `wifi_ssdt_write_properties()`: This function writes the properties
for WiFi device like _PRW, regulatory domain and SAR.
This split is done so that the device write can be skipped for
CNVi devices in follow-up CLs. It will allow the SoC controller
representation for CNVi PCI device to be consistent with other
internal PCI devices in the device tree i.e. not requiring a
chip driver for the PCI device.
Because of this change, _PRW and SAR will be seen in a separate
block in SSDT disassembly, but it does not result in any functional
change.
Observed difference:
Before:
Scope (\_SB.PCI0.PBR1)
{
Device (WF00)
{
Name (_UID, 0xAA6343DC)
Name (_DDN, "WIFI Device")
Name (_ADR, 0x0000000000000000)
Name (_PRW, Package() { 0x08, 0x03 })
}
}
After:
Device (\_SB.PCI0.PBR1.WF00)
{
Name (_UID, 0xAA6343DC)
Name (_DDN, "WIFI Device")
Name (_ADR, 0x0000000000000000)
}
Scope (\_SB.PCI0.PBR1.WF00)
{
Name (_PRW, Package() { 0x08, 0x03 })
}
Change-Id: I8ab5e4684492ea3b1cf749e5b9e2008e7ec8fa28
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change reorganizes the WiFi generic driver to move the ACPI
functions to a separate file. This change is done to reduce the noise
in generic.c file and improve readability of the file.
Change-Id: If5fafb5452fb5bad327be730fcfc43d8a5d3b8ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change reorganizes the WiFi generic driver to move the SMBIOS
functions to a separate file. This change is done to reduce the noise
in generic.c file and improve readability of the file.
Change-Id: I38ed46f5ae1594945d2078b00e8315d9234f36d7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Move CPX and SKX read_msr_ppin() to common util.c file.
Update drivers/ocp/smbios #include to match.
Change-Id: I4c4281d2d5ce679f5444a502fa88df04de9f2cd8
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Bug=None
Test=Enabled the device on TGLY RVP and tested that the codec is
reflected in SSDT. Checked sound card binding works
and soundwire drivers are enabled in kernel.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ia7358927fe8531e609ebe070bef259a2bbc09093
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
`mrc_cache_needs_update` is comparing the "new size" of the MRC data
(minus metadata size) to the size including the metadata, which causes
the driver to think the data has changed, and so it will rewrite the
MRC cache on every boot. This patch removes the metadata size from
the comparison.
BUG=b:171513942
BRANCH=volteer
TEST=1) Memory training data gets written the on a boot where the data
was wiped out.
2) Memory training data does not get written back on every subsequent
boot.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I7280276f71fdaa492c327b2b7ade8e53e7c59f51
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Provide a way to get BMC revision.
Tested=On OCP Delta Lake, function can get BMC revision well.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Iaaa4e8bf181a38452b53c83a762c7b648e95e643
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
SMMSTORE version 2 is a complete redesign of the current driver. It is
not backwards-compatible with version 1, and only one version can be
used at a time.
Key features:
* Uses a fixed communication buffer instead of writing to arbitrary
memory addresses provided by untrusted ring0 code.
* Gives the caller full control over the used data format.
* Splits the store into smaller chunks to allow fault tolerant updates.
* Doesn't provide feedback about the actual read/written bytes, just
returns error or success in registers.
* Returns an error if the requested operation would overflow the
communication buffer.
Separate the SMMSTORE into 64 KiB blocks that can individually be
read/written/erased. To be used by payloads that implement a
FaultTolerant Variable store like TianoCore.
The implementation has been tested against EDK2 master.
An example EDK2 implementation can be found here:
eb1127744a
Change-Id: I25e49d184135710f3e6dd1ad3bed95de950fe057
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
With TGL FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Due to which cbfsf_decompression_info check failed
when trying to load vbt binary from cbfs because vbt
decompressed_size was greater than vbt_data size. This caused
Graphics init and fw screen issues. Increase the vbt_data to
9KiB to accommodate new vbt binary.
BUG=b:170656067
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: If6ffce028f9e8bc14596bbc0a3f1476843a9334e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When MRC_SAVE_HASH_IN_TPM is selected, we can just use the TPM hash to
verify the MRC_CACHE data. Thus, we don't need to calculate the
checksum anymore in this case.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I1db4469da49755805b541f50c7ef2f9cdb749425
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Pull selection of tpm hash index logic into cache_region struct. This
CL also enables the storing of the MRC hash into the TPM NVRAM space
for both recovery and non-recovery cases. This will affect all
platforms with TPM2 enabled and use the MRC_CACHE driver.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami and lazor
Change-Id: I1a744d6f40f062ca3aab6157b3747e6c1f6977f9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46514
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We need to extend the functionality of the mrc_cache hash functions to
work for both recovery and normal mrc_cache data. Updating the API of
these functions to pass in an index to identify the hash indices for
recovery and normal mode.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I9c0bb25eafc731ca9c7a95113ab940f55997fc0f
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This CL would remove these calls from fsp 2.0. Platforms that select
MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from
romstage (when data stashed to CBMEM) to ramstage (when data is
written back to SPI flash.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use this config to specify whether we want to save a hash of the
MRC_CACHE in the TPM NVRAM space. Replace all uses of
FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the
FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not
select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have
recovery MRC_CACHE.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
As ongoing work for generalizing mrc_cache to be used by all
platforms, we are pulling it out from fsp 2.0 and renaming it as
mrc_cache_hash_tpm.h in security/vboot.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This chip driver adds ACPI identifiers for multiplexed I2C bus that are
selected using GPIO. The multiplexed bus device defines the address
to select the I2C lines. These ACPI identifiers are consumed by the
i2c-mux-gpio kernel driver:
https://www.kernel.org/doc/html/latest/i2c/muxes/i2c-mux-gpio.html
BUG=b:169444894
TEST=Build and boot to OS in waddledee. Ensure that the ACPI identifiers
are added in appropriate context.
Scope (\_SB.PCI0.I2C3.MUX0)
{
Device (MXA0)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_ADR, Zero) // _ADR: Address
}
}
Scope (\_SB.PCI0.I2C3.MUX0)
{
Device (MXA1)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_ADR, One) // _ADR: Address
}
}
Change-Id: If8b983bc8ce212ce05fe6b7f01a6d9092468e582
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add identifiers in ACPI tables for GPIO based I2C multiplexer. The
multiplexer device defines the GPIO resource used to select the
adapter/bus lines. The multiplexer adapter device defines the address
to select the adapter/client lines. These ACPI identifiers are consumed
by the i2c-mux-gpio kernel driver:
https://www.kernel.org/doc/html/latest/i2c/muxes/i2c-mux-gpio.html
BUG=b:169444894
TEST=Build and boot waddledee to OS. Ensure that the ACPI identifiers
are added for I2C devices multiplexed using I2C MUX under the
appropriate scope. Here is the output SSDT:
Scope (\_SB.PCI0.I2C3)
{
Device (MUX0)
{
Name (_HID, "PRP0001") // _HID: Hardware ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0125
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x02)
{
Package (0x02)
{
"compatible",
"i2c-mux-gpio"
},
Package (0x02)
{
"mux-gpios",
Package (0x04)
{
\_SB.PCI0.I2C3.MUX0,
Zero,
Zero,
Zero
}
}
}
})
}
}
Change-Id: Ib371108cc6043c133681066bf7bf4b2e00771e8b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The USB4 retimer device needs to declare a _DSM with specific functions
that allow for GPIO control to turn off the power when an external
device is not connected. This driver allows the mainboard to provide
the GPIO that is connected to the power control.
BUG=b:156957424
Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DP link rates are reported in an array of LE16 values. The current code
tries to parse them as 8-bit which doesn't get very far, causing us to
always drop into the fallback path. This patch should fix the issue
(+minor whitespace cleanup).
BUG=b:170630766
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1e03088ee2d3517bdb5dcc4dcc4ac04f8b14a391
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
CBFS SAR and SAR tables in ACPI are currently supported only by Intel
WiFi devices. This change adds a check in `emit_sar_acpi_structures()`
to ensure that the PCI vendor for the device is Intel before
generating the SAR tables.
BUG=b:169802515
BRANCH=zork
Change-Id: Ibff437893a61ac9557cff243a70230f101089834
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46040
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change limits the scope of `wifi_generic_fill_ssdt()` and
`wifi_generic_acpi_name()` to generic.c since they are not used
outside of this file anymore. Also, since there is no need to split
SSDT generator into two separate functions,
`wifi_generic_fill_ssdt_generator()` is dropped and `.acpi_fill_ssdt`
directly points to `wifi_generic_fill_ssdt()`.
BUG=b:169802515
BRANCH=zork
Change-Id: I2cbb97f43d2d9f9ed6d3cf8f0a9b13a7f30e922e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46038
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, drivers/intel/wifi is a PCI driver (provides `struct
pci_driver`) as well as a chip driver (provides `struct
chip_operations`). However, there is no need for a separate chip
driver for the WiFi device since drivers/wifi/generic already provides
one.
Having two separate chip drivers makes it difficult to multi-source
WiFi devices and share the same firmware target without having to add
a probe property for each of these devices. This is unnecessary since
the WiFi driver in coreboot is primarily responsible for:
1. PCI resource allocation
2. ACPI SSDT node generation to expose wake property and SAR tables
3. SMBIOS table generation
For the most part, coreboot can perform the above operations without
really caring about the specifics of which WiFi device is being used
by the mainboard. Thus, this change drops the driver for intel/wifi
and moves the PCI driver support required for Intel WiFi chips into
drivers/wifi/generic. The PCI driver is retained for backward
compatibility with boards that never utilized the chip driver to
support Intel WiFi device. For these devices, the PCI driver helps
perform the same operations as above (except exposing the wake
property) by utilizing the same `wifi_generic_ops`.
This change also moves DRIVERS_INTEL_WIFI config to
wifi/generic/Kconfig.
BUG=b:169802515
BRANCH=zork
Change-Id: I780a7d1a87f387d5e01e6b35aac7cca31a2033ac
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46036
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the addition of CBFS SAR file from
intel/wifi/Makefile.inc to wifi/generic/Makefile.inc to keep it in the
same sub-directory as the Kconfig definition.
BUG=b:169802515
BRANCH=zork
Change-Id: I7ee33232b6a07bbf929f3a79fabe89130fb6fa6f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change drops the dependency of DRIVERS_WIFI_GENERIC on
HAVE_ACPI_TABLES as the driver provides operations other than the ACPI
support for WiFi devices. Since the dependency is now dropped, ACPI
operations in generic.c are guarded by CONFIG(HAVE_ACPI_TABLES).
BUG=b:169802515
BRANCH=zork
Change-Id: I16444a9d842a6742e3c97ef04c4f18e93e6cdaa9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46037
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support in generic WiFi driver in coreboot to
generate SMBIOS data for the WiFi device. Currently, this is used only
for Intel WiFi devices and the function is copied over from Intel WiFi
driver in coreboot. This change is done in preparation for getting rid
of the separate chip driver for Intel WiFi in coreboot.
BUG=b:169802515
BRANCH=zork
Change-Id: If3c056718bdc57f6976ce8e3f8acc7665ec3ccd7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
To avoid confusion with `flashconsole` (CONSOLE_SPI_FLASH), prefix this
option with `EM100Pro`. Looks like it is not build-tested, however.
Change-Id: I4868fa52250fbbf43e328dfd12e0e48fc58c4234
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The patch allows to configure sensors with a remote diode connected
and a on-chip local temperature sensor from the devicetree for the
board that uses this HWM. According to the documentation [1], this is
done by setting the corresponding bits in the Mode Selection Register
(22h). It is necessary for some Intel processors (Apollo Lake SoC)
that do not support PECI and the CPU temperature is taken from the
thermistor.
TEST = After loading the nct7802 module on the Kontron mAL-10 [2] with
Linux OS, we can see configuration of the HWM with one sensor in
the thermistor mode:
user@user-apl:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +41.0°C (high = +110.0°C, crit = +110.0°C)
Core 0: +40.0°C (high = +110.0°C, crit = +110.0°C)
Core 1: +40.0°C (high = +110.0°C, crit = +110.0°C)
Core 2: +41.0°C (high = +110.0°C, crit = +110.0°C)
Core 3: +41.0°C (high = +110.0°C, crit = +110.0°C)
nct7802-i2c-0-2e
Adapter: SMBus CMI adapter cmi
in0: +3.35 V (min = +0.00 V, max = +4.09 V)
in1: +1.92 V
in3: +1.21 V (min = +0.00 V, max = +2.05 V)
in4: +1.68 V (min = +0.00 V, max = +2.05 V)
fan1: 0 RPM (min = 0 RPM)
fan2: 868 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
temp1: +42.5°C (low = +0.0°C, high = +85.0°C)
(crit = +100.0°C) sensor = thermistor
temp4: +44.0°C (low = +0.0°C, high = +85.0°C)
(crit = +100.0°C)
temp6: +0.0°C
[1] page 30, section 7.2.32, Nuvoton Hardware Monitoring IC NCT7802Y
with PECI 3.0 interface, datasheet, revision 1.2, february 2012
[2] https://review.coreboot.org/c/coreboot/+/39133
Change-Id: I28cc4e5cae76cf0bcdad26a50ee6cd43a201d31e
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39766
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops maxsleep parameter from chip config and instead
hardcodes the deepest sleep state from which the WiFi device can wake
the system up from to SLP_TYP_S3. This is similar to how other device
drivers in coreboot report _PRW property in ACPI. It relieves the
users from adding another register attribute to devicetree since all
mainboards configure the same value. If this changes in the future, it
should be easy to bring the maxsleep config parameter back.
BUG=b:169802515
BRANCH=zork
Change-Id: I42131fced008da0d51f0f777b7f2d99deaf68827
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46033
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a call to `pci_dev_is_wake_source()` to determine and
log WiFi wake source to event log just like the Intel WiFi driver
does. This is done in preparation to merge the generic and Intel WiFi
drivers in follow-up changes.
BUG=b:169802515
BRANCH=zork
Change-Id: I20528ae1f72ca633da31e01d777c46fd5f4a337f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change uses the newly added `pci_dev_is_wake_source()` helper function
to determine and log WiFi wake source instead of assuming a hard-coded
register value to check. This is done in preparation to merge the
generic WiFi and Intel WiFi drivers in coreboot in follow-up changes.
BUG=b:169802515
BRANCH=zork
Change-Id: I9bdb453092b4ce7bdab2969f13e0c0aa8166dc0a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
HPD on this bridge chip is a bit useless. This is an eDP bridge so the HPD is
an internal signal that's only there to signal that the panel is done powering up.
But the bridge chip debounces this signal by between 100 ms and 400 ms (depending on process,
voltage, and temperate). One particular panel asserted HPD 84 ms after it was powered on
meaning that we saw HPD 284 ms after power on. Assume that the panel driver will have the
hardcoded delay in its prepare and always disable HPD.
Change-Id: Iea7dd75b57fa55ec182c0bee09b0f35208357892
Signed-off-by: Vinod Polimera <vpolimer@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Modify mrc_cache_load current to return the size of the mrc_cache
entry so that caller will know what the actual size of the data
returned is. This is needed for ARM devices like trogdor, which need
to know the size of the training data when populating the QcLib
interface table.
BUG=b:150502246
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_NAMI -x -a
Change-Id: Ia314717ad2a7d5232b37a19951c1aecd7f843c27
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
`pci_dev_init()` is used to load and run option ROM on VGA class
devices (PCI_CLASS_DISPLAY_VGA). WiFi device is not a VGA class device
and hence the call to `pci_dev_init()` is not required. This change
drops the call to `pci_dev_init()` from `wifi_pci_dev_init()` in Intel
WiFi driver.
BUG=b:169802515
BRANCH=zork
Change-Id: I6588ea0a5c848904088d05fd1cbdf677b2dc8ea9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
WiFi devices supported by the generic WiFi driver are PCIe devices
which need to be managed using the standard pci_dev_* operations to
read, set and enable resources. This change updates the
device_operations structure `wifi_generic_ops` to use the standard
pci_dev_* operations for these devices.
BUG=b:169802515
BRANCH=zork
Change-Id: I8b306259e205ecb963c0563000bd96ec6b978b8b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Angel Pons