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>
This config is a slightly stripped configuration of the Chromium OS
configuration used in production. Apparently the bootblock fills up
faster than usual on this device, resulting in address overflows.
Add this config here so we'll notice early in the future.
Change-Id: I3145bba63d32ddb9d00fd98d3cb774bf9ddd69a6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36923
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By removing this code, we get approximately back to
where the board was before the fmap cache feature
was added, which is small enough for the Chromium OS
default configuration for the board to fit into the
32KB that the bootblock can use on the chipset again.
Change-Id: I52c0c30a14929913ded144bf086c12938e9c2699
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Correct what looks to be errant characters in the makefile variable for
the Gigabit Ethernet Controller. This should have no effect on any
mainboards as none select the HUDSON_GEC_FWM symbol.
Change-Id: Icb861d872973aaf2b653440cae00057d5ad89b20
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Due to the way CAR teardown is handled in FSP 1.0, the results of
car_get_var_ptr() aren't always reliable, which can break things when
running with FMAP cache. It might be possible to fix this but would make
the code rather complicated, so let's just disable the feature on these
platforms and hope they die out soon.
Also allow this option to be used by platforms that don't have space for
the cache and want to save a little more code.
Change-Id: I7ffb1b8b08a7ca3fe8d53dc827e2c8521da064c7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With GCC 9.x has a new warning *address-of-packed-member*.
> -Waddress-of-packed-member
>
> Warn when the address of packed member of struct or union is
> taken, which usually results in an unaligned pointer value.
> This is enabled by default.
This results in the build errors below, for example, with GCC 9.2 from
Debian Sid/unstable.
src/southbridge/intel/common/spi.c: In function 'spi_init':
src/southbridge/intel/common/spi.c:298:19: error: taking address of packed member of 'struct ich7_spi_regs' may result in an unaligned pointer value [-Werror=address-of-packed-member]
298 | cntlr->optype = &ich7_spi->optype;
| ^~~~~~~~~~~~~~~~~
Therefore, explicitly disable the warning.
Change-Id: I01d0dcdd0f8252ab65b91f40bb5f5c5e8177a293
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36940
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
buffer_to_fifo32() is a simple wrapper to buffer_to_fifo32_prefix(), but
unfortunately its arguments are swapped. This patch fixes the issue.
Change-Id: I6414bf51dd9de681b3b87bbaf4ea4efc815f7ae1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36942
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves the traditional POSIX stdbool.h definitions out from
stdint.h into their own file. This helps for using these definitions in
commonlib code which may be compiled in different environments. For
coreboot everything should chain-include this stuff via types.h anyway
so nothing should change.
Change-Id: Ic8d52be80b64d8e9564f3aee8975cb25e4c187f5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch changes the ipq40xx Makefile.inc to follow established
coreboot practice of calling Python scripts directly rather than
invoking the 'python' interpreter explicitly. This has the added effect
of honoring the scripts shebang (which in this case is set to
'python2').
Change-Id: If96e8313527c411ef1bb6386e03b6a209c750131
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some types of Undefined Behavior can be determined statically at compile
time and gcc now has a set of flags that make it emit warnings in that
case instead of doing the __builtin_trap() / optimize / UD2-opcode dance
that silently breaks the resulting binary.
BUG=chromium:958270
BRANCH=none
TEST=abuild passes (probably not)
Change-Id: I3aa5ca00c9838cc7517160069310a1ef85372027
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32814
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IASL reports unnecessary/redundant use of offset operator. These
messages are only masking usefull messages.
Add -vw 2158 so this message isn't reported.
BUG=N/A
TEST=build
Change-Id: Ie8507d3b3cb6f2e75cb87cd3e4bcc4280df27f77
Signed-off-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36857
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some Sandy Bridge boards disabled the PCI-to-PCI bridge early to avoid
probing by the MRC. We can do that for all boards instead, based on the
devicetree setting.
Change-Id: Ie64774628fde77db2a379bdba6a921a31e52fa0d
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The integrated GbE port is toggled via the Backed-Up Control (BUC)
register. We already disable it according to the devicetree setting
but never enabled it. This could lead to the confusing situation
that it was disabled before (different build, vendor BIOS, etc.)
but shouldn't be anymore.
As we need a full reset after enabling GbE, do it in early PCH init.
Change-Id: I9db3d1923684b938d2c9f5b369b0953570c7fc15
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Nico Huber