Set the end of post GPIO to the BMC. This gets IPMI working on the BMC.
Change-Id: I1a0055cdfd4a973b5f42570723bd95f1844dd9a7
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update the FADT for fwts errors for the GPE entries.
Fix GPE0 access size and remove GPE1 address space ID.
Change-Id: Iea43b534fa119d17cb2bafef8f72d73bcba3a650
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If mainboard devicetree config defines lpc_lgmr, use it to
set up LPC Generic Memory Range register. Also set up
64KiB memory resource.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Iec94f7364c332789f75c2562e910ea5db4ffad23
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51717
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Watson v2 mainboard has hardware support and OpenBMC support for IPMI.
Add drivers/ipmi to the device tree of watson v2 mainboard.
Use original device tree for watson mainboard.
TESTED=booted watson v2 board, and tested ipmitool command:
0 | OEM record fb | 2800000000f0ffffffffffffff
Signed-off-by: Ravi Rama <rrama@arista.com>
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I1be653278dbfd704d24756cf82be73bdae4bb13c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51311
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For watson_v2 mainboard variant:
* Enable IPMI_KCS in config.
* In early_mainboard_romstage_entry(), enable LPC IO ports
for IPMI over KCS.
Signed-off-by: Ravi Rama <rrama@arista.com>
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ie0e718b44889678c49f3d61cccd0e33b306fc6f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51310
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
watson_v2 mainboard variant has its own code to be built in. Update
Makefile.inc of mainboard directory to include variant subdirectory.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I21ee1c575b3b6e4278955c12d6e4f7109eb75105
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51308
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the 4.11_branch to the 2020118 intel microcde release,
which is the current main HEAD.
Change-Id: Ic010594a59b692b18eb40656c283c080c34c4d2c
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50553
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the empty PWRB ACPI device. The power button is controlled by
the fixed power button model in PM1x_EVT_BLK and doesn't have a
control method. The only device in mainboard.asl was PWRB, so remove
the file.
This fixes the FWTS error:
acpi_pwrb: PWR_Button field in FACP should not be zero with ACPI PNP0C0C device.
Change-Id: Idd8c3588694b913b52ca6509332603e3525117b7
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Use smm_module_loaderv2 to support 16core/32thread Broadwell_DE.
Tested SMM handler loads on all 32 threads.
Change-Id: I3a6e17e8590a2af9b4e7c701f8fccfccfa3ea94b
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Xeon-SP Skylake Scalable Processor can have 36 CPU threads (18 cores).
Current coreboot SMM is unable to handle more than ~32 CPU threads.
This patch introduces a version 2 of the SMM module loader which
addresses this problem. Having two versions of the SMM module loader
prevents any issues to current projects. Future Xeon-SP products will
be using this version of the SMM loader. Subsequent patches will
enable board specific functionality for Xeon-SP.
The reason for moving to version 2 is the state save area begins to
encroach upon the SMI handling code when more than 32 CPU threads are
in the system. This can cause system hangs, reboots, etc. The second
change is related to staggered entry points with simple near jumps. In
the current loader, near jumps will not work because the CPU is jumping
within the same code segment. In version 2, "far" address jumps are
necessary therefore protected mode must be enabled first. The SMM
layout and how the CPUs are staggered are documented in the code.
By making the modifications above, this allows the smm module loader to
expand easily as more CPU threads are added.
TEST=build for Tiogapass platform under OCP mainboard. Enable the
following in Kconfig.
select CPU_INTEL_COMMON_SMM
select SOC_INTEL_COMMON_BLOCK_SMM
select SMM_TSEG
select HAVE_SMI_HANDLER
select ACPI_INTEL_HARDWARE_SLEEP_VALUES
Debug console will show all 36 cores relocated. Further tested by
generating SMI's to port 0xb2 using XDP/ITP HW debugger and ensured all
cores entering and exiting SMM properly. In addition, booted to Linux
5.4 kernel and observed no issues during mp init.
Original-Change-Id: I00a23a5f2a46110536c344254868390dbb71854c
Original-Signed-off-by: Rocky Phagura <rphagura@fb.com>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
(cherry picked from commit afb7a81478)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I76bb506de56c816f6c0635bfd990125b789c5877
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Rocky Phagura
Suggested by Nico Huber in CB:38765.
This placement makes the address calculation simpler and
makes its location indepedent of the number of CPUs.
As part of the change in the BIOS resource list address
calculation, the `size` variable was factored out of the
conditional in line 361, thus eliminating the else.
Original-Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d
Original-Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
(cherry picked from commit 076605bc92)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: Ie62e2bdccd2d09084cc39a0f2fe32df236c08cd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
To mitigate against sinkhole in software which is required on
pre-sandybridge hardware, the smm entry point needs to check if the
LAPIC base is between smbase and smbase + smmsize. The size needs to
be available early so add them to the relocatable module parameters.
When the smmstub is used to relocate SMM the default SMM size 0x10000
is provided. On the permanent handler the size provided by
get_smm_info() is used.
Original-Change-Id: I0df6e51bcba284350f1c849ef3d012860757544b
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/37288
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
(cherry picked from commit a3eb3df01c)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I4948639a513b196382eb38616fe872b72bb7e59e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Check to ensure that dual monitor mode is supported on the
current processor. Dual monitor mode is normally supported on
any Intel x86 processor that has VTx support. The STM is
a hypervisor that executes in SMM dual monitor mode. This
check should fail only in the rare case were dual monitor mode
is disabled. If the check fails, then the STM will not
be initialized by coreboot.
Original-Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Original-Change-Id: I518bb2aa1bdec94b5b6d5e991d7575257f3dc6e9
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/38836
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
(cherry picked from commit 5544f62746)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: I312570ca28329490006283251f69dd83ef64af40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
This update is a combination of all four of the patches so that the
commit can be done without breaking parts of coreboot. This possible
breakage is because of the cross-dependencies between the original
separate patches would cause failure because of data structure changes.
security/intel/stm
This directory contains the functions that check and move the STM to the
MSEG, create its page tables, and create the BIOS resource list.
The STM page tables is a six page region located in the MSEG and are
pointed to by the CR3 Offset field in the MSEG header. The initial
page tables will identity map all memory between 0-4G. The STM starts
in IA32e mode, which requires page tables to exist at startup.
The BIOS resource list defines the resources that the SMI Handler is
allowed to access. This includes the SMM memory area where the SMI
handler resides and other resources such as I/O devices. The STM uses
the BIOS resource list to restrict the SMI handler's accesses.
The BIOS resource list is currently located in the same area as the
SMI handler. This location is shown in the comment section before
smm_load_module in smm_module_loader.c
Note: The files within security/intel/stm come directly from their
Tianocore counterparts. Unnecessary code has been removed and the
remaining code has been converted to meet coreboot coding requirements.
For more information see:
SMI Transfer Monitor (STM) User Guide, Intel Corp.,
August 2015, Rev 1.0, can be found at firmware.intel.com
include/cpu/x86:
Addtions to include/cpu/x86 for STM support.
cpu/x86:
STM Set up - The STM needs to be loaded into the MSEG during BIOS
initialization and the SMM Monitor Control MSR be set to indicate
that an STM is in the system.
cpu/x86/smm:
SMI module loader modifications needed to set up the
SMM descriptors used by the STM during its initialization
Original-Change-Id: If4adcd92c341162630ce1ec357ffcf8a135785ec
Original-Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Original-Reviewed-on: https://review.coreboot.org/c/coreboot/+/33234
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: ron minnich <rminnich@gmail.com>
(cherry picked from commit ae438be578)
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Change-Id: Ic0131fcada9f43c9817c8a0a942d0419c7023130
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It was initially applied to Wedge100 and MonoLake in CB:30290
and the issue has now been observed on Watson as well.
Original change: [CB:30290][commit 817994c1be]
Signed-off-by: Deomid "rojer" Ryabkov <rojer9@fb.com>
Change-Id: Ica9557ff159321abed55f9402aee626f18fe526b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50307
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is consistent with how other binaries (e.g. FSP) are added via
Kconfig. This also makes it more visible that things need to be
configured.
Change-Id: I399de6270cc4c0ab3b8c8a9543aec0d68d3cfc03
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Include the soc uncore.asl for the uncore irq routing. Generates
the same asl.
Change-Id: I2062520a06626f86fb0d78e8b23533f987b37ca0
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Latest IASL version (20200717) leads to a build error on 4.11_branch.
dsdt.asl 1121: Device (UNC0)
Warning 3073 - Multiple types (Device object requires either a _HID or
_ADR, but not both)
This warning reported as error was ignored in older IASL versions.
The address object (_ADR) is not needed because a valid hardware ID
(_HID) for the device is available.
Change-Id: Iae5c91739ed9caea2dbb5996e2f093ed6fc47e93
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
The current size of RO_VPD (and RW_VPD) is too small. We have case that
adding VPD parameters silently corrupts the coreboot region next to
RO_VPD.
Increase the size of both RO_VPD and RW_VPD to 0x4000 bytes.
TESTED=build coreboot image for watson, add large size VPD parameter to
the image, boot watson server into target OS.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I428b7de6462b47492d9526042018395d2f99cb2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When INTEL_TXT is set, at romstage entry check if startup ACM worked correctly
by probing TXT_ERROR register.
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I6f423df8b05dc44220a9bad3674f687bac94e335
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42713
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add TXT ramstage driver:
* Show startup errors
* Check for TXT reset
* Check for Secrets-in-memory
* Add assembly for GETSEC instruction
* Check platform state if GETSEC instruction is supported
* Configure TXT memory regions
* Lock TXT
* Protect TSEG using DMA protected regions
* Place SINIT ACM
* Print information about ACMs
Extend the `security_clear_dram_request()` function:
* Clear all DRAM if secrets are in memory
Add a config so that the code gets build-tested. Since BIOS and SINIT
ACM binaries are not available, use the STM binary as a placeholder.
Tested on OCP Wedge100s and Facebook Watson
* Able to enter a Measured Launch Environment using SINIT ACM and TBOOT
* Secrets in Memory bit is set on ungraceful shutdown
* Memory is cleared after ungraceful shutdown
Change-Id: Iaf4be7f016cc12d3971e1e1fe171e6665e44c284
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
(cherry picked from commit 5f9f77672d)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42712
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Commit c1dc2d5e68 (mb/lenovo/t60: Switch to override tree) converted
these boards to override trees, but some device nodes were missed.
Said nodes are essential, as `chip` configuration data is always tied
to device nodes. The resulting `static.c` contained multiple copies
of the `chip` configuration structs, but the wrong ones were hooked up.
The therefore missing configuration of the clockgen led to general
instability, especially with SMP under Linux (probably due to the
attempt to enter lower C states on an idle core). Passing `maxcpus=1`
to the Linux kernel served as a workaround.
Change-Id: I6c26d633d1860cf9a5415994444e75ae1c2e59ad
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43065
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST=Use "dmidecode -t 16" in Linux to check if SMBIOS type 16 exists
Change-Id: Ie057742112f14447b226d432417d9301d4aea958
Signed-off-by: Morgan Jang <Morgan_Jang@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37233
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Select VPD, GENERATE_SMBIOS_TABLES, VPD_SMBIOS_VERSION so that
"firmware_version" key value in RO_VPD is reported in smbios type
0 as BIOS version.
TEST=Build coreboot image for WatsonV2, run "vpd -s
firmware_version=FB_OSF_1.2 -i RO_VPD -f build/coreboot.rom"
command to add firmware_version key value pair in RO_VPD,
flash the image to WatsonV2 and reboot it, run dmidecode to verify:
[root@localhost ~]# dmidecode -t 0
...
BIOS Information
Vendor: coreboot
Version: FB_OSF_1.2
...
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I31fb2cef01161175a0c01094c5445f7fa340f2d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: insomniac <insomniac@slackware.it>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
If VPD_SMBIOS_VERSION is selected, it would read VPD_RO variable that can
override SMBIOS type 0 version.
One special scenario of using this feature is to assign a BIOS version to
a coreboot image without the need to rebuild from source.
VPD_SMBIOS_VERSION default is n.
Tested=On OCP Delta Lake, dmidecode -t 0 can see the version being updated
from VPD.
Change-Id: Iee62ed900095001ffac225fc629b3f2f52045e30
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: insomniac <insomniac@slackware.it>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit c746a748c4)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42747
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Under certain conditions TXT can "lock" memory controller for security
purpose. This manifests itself in IMC's SMbus controller failing all SPD
data read requests. FSP does not detect error condition and fails boot
with "No memory found" issue.
TEST=tested on OCP monolake in 'locked' state
Change-Id: If4637e4293421794a89037ff107e87794c40114a
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Watson V2 is the 2nd board variant of Watson.
One aspect of the difference between watson V2 and watson (V1) is:
* Watson V2 has TPM2 chip instead of TPM1 chip.
* Watson V2 needs to have measured boot enabled.
TESTED=Made Watson V2 image, checked boot log and verfied that TPM2
is detected by both coreboot and target OS, that coreboot is measured.
TPM: Measured FMAP: COREBOOT CBFS: bootblock into PCR 2
TPM: Measured FMAP: COREBOOT CBFS: fallback/romstage into PCR 2
TPM: Measured FMAP: COREBOOT CBFS: fallback/ramstage into PCR 2
TPM: Measured FMAP: COREBOOT CBFS: cpu_microcode_blob.bin into PCR 2
TPM: Measured FMAP: COREBOOT CBFS: fallback/dsdt.aml into PCR 2
TPM: Measured FMAP: COREBOOT CBFS: fallback/payload into PCR 2
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Iabf4183dfeabb2f9946dbb5c98c60b7c0cdba711
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40575
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Facebook Watson (V1) board is the first variant of Watson mainboard.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I1164ee9f8d07cebf8d505ca1e164823c1cb5625c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
We haven't been able to update IASL in 8 months because of this
conflict. Ignoring it doesn't make things any worse than they are now.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Iced2e55e9f2aa7a262a5c1ffeff32af78acfa35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
(cherry picked from commit 12e9c5ee86)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38959
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GNU Make 4.3 is more picky about the $(spc) definition. It seems, the
variable ends up empty. The old definition worked for nearly 8 years,
RIP.
Tested with GNU Make 4.2.1 and 4.3.
Change-Id: I7981e0066b550251ae4a98d7b50e83049fc5586a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38790
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
(cherry picked from commit 0f6f70c394)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38958
SMBIOS type 1 data fields are overwritten by FRU product info
area data, SMBIOS type 2 fields are overwritten by FRU
board info area data.
Tested on OCP Mono Lake.
Change-Id: I58cbe95055dea053b115e99f354f40d5902c6a35
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Implemented according to IPMI "Platform Management
FRU Information Storage Definition" specification
v1.0 for reading FRU data Product Info Area and
Board Info Area.
SMBIOS data can be updated with the FRU data.
Tested on OCP Mono Lake.
Change-Id: Id6353f5ce3f7ddd3bb161b91364b3cf276d020b8
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Currently FMAP does not allocate all the usable space. This change
addresses that by removing unused section and expanding CBFS section.
TEST=tested on actual watson HW
Change-Id: I5f407c11031822d58f11f1a4684845d57653b190
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Current code uses CPUID leaf 0x1, EBX bits 16:23 to determine number for
"core count". However, it turns out this number has little to do with
real number of cores. According to SDM vol 2A, it stays for "maximum
number of addressable IDs for logical processors in this physical
package". This does not seem to take into account fusing of giving
processor.
The new code determines 'core count' by dividing thread-level cpus by
reported logical cores. This seems to be the only way to arrive
to number of cores as it is reported in official CPU datasheet.
TEST=tested on OCP monolake
Change-Id: Id4ba9e3079f92ffe38f9104ffcfafe62582dd259
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
(cherry picked from commit 515ef38db4)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37089
I2C bus does not guarantee data integrity. As result, sometimes
we end up detecting CRC errors and not adding DIMMs to SMBIOS tables.
This change adds re-tries on such errors.
TEST=let OCP monolake run without fan and try reading SPD data in tight
loop. CRC errors were reported but subsequent retries were error free.
Change-Id: I650c8cd80f75b603db332024748a91af6171f096
Signed-off-by: Andrey Petrov <anpetrov@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The code in cpu/x86/lapic/apic_timer.c for timer_monotonic_get() is not
SMP safe as LAPIC timers do not run as synchronised as TSCs. So the
reported times with LAPIC_MONOTONIC_TIMER=y at least were incorrect.
Since the approach for this improved times reporting was not completed
wrt. the output format either, revert it from 4.11_branch.
Change-Id: Ie7edae572cf4fee0b9d2497f7690145c2699a809
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested on OCP Mono Lake with dmidecode -t 1 and the expected
UUID is visible.
Change-Id: I0aab4df67b7aaba8be6ddbb13984fffb2b14fe6b
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
According to IPMI SPEC, it is recommended that BIOS includes provisions
for checking and reporting on the basic health of BMC by executing
the Get Self Test Results command and checking the result.
TEST=Check the result in response data to confirm the BMC status is fine
or not.
Change-Id: I20349cec2e8e9420d177d725de2a5560d354fe47
Signed-off-by: Morgan Jang <Morgan_Jang@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
(cherry picked from commit 5015502414)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37087
Fill in some stats using our repo analysis scripts in
util/release/, thank the contributors, add some prose
about notable achievements since 4.10.
Also start a new doc for 4.12.
Change-Id: I10a39081762d6e01f4040f717d36662975e4c8e9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36948
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The mainboard was accidently added due to bad rebase.
Change-Id: Ie7215e551651dbbc8d92316c48e455405923a30b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36077
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This uses less lines, is the original Markdown syntax, and for short
blocks better readable.
Change-Id: Id96ad0f65980dfb943eef3cde5626d56f97622f9
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35729
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Run
- make -C util/docker doc.coreboot.org to build the docker image
- make -C util/docker docker-build-docs to build the documentation
- make -C docker-livehtml-docs to serve autoupdated documentation over
http://0.0.0.0:8000
Change-Id: Ic07f216f8d90d6e212383250b852dc91575304c3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36104
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Marc Jones