Make sure the bytes in RTC cmos used by CBNT don't collide with the
option table. This depends on what is set up in the BPM, Boot Policy
Manifest. When the BPM is provided as a binary the Kconfig needs to be
adapted accordingly. A later patch will use this when generating the
BPM.
Change-Id: I246ada8a64ad5f831705a4293d87ab7adc5ef3aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Global variables are located in .bss and not on the CPU stack.
Overwriting them a per CPU case is bound to cause race conditions. In
this case it is even just plainly wrong.
Note: This variable is set up in the get_smm_info() function.
Change-Id: Iaef26fa996f7e30b6e4c4941683026b8a29a5fd1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The permanent handler module argument 'save_state_size' now holds the
meaning of the real save state size which is then substracted from the
CPUs save state 'top' to get the save state base.
TESTED with qemu Q35 on x86_64 where the stub size exceeds the AMD64
save state size.
Change-Id: I55d7611a17b6d0a39aee1c56318539232a9bb781
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With the smm_module_loaderv2 the save state map is not linear so copy
a map from ramstage into the smihandler.
TESTED on QEMU q35: Both SMMLOADER V1 and V2 handle save states properly.
Change-Id: I31c57b59559ad4ee98500d83969424e5345881ee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50769
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move out smm_create_map as this was not run if concurrent_save_states
is 1. The cpus struct array is used in the smm_get_cpu_smbase()
callback so it is necessary to create this.
TEST: run qemu/q35 with -smp 1 (or no -smp argument)
Change-Id: I07a98bbc9ff6dce548171ee6cd0c303db94087aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50783
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The parameters that the permanent handler requires are pushed directly
to the permanent handlers relocatable module params.
The paremeters that the relocation handler requires are not passed on
via arguments but are copied inside the ramstage. This is ok as the
relocation handler calls into ramstage.
Change-Id: Ice311d05e2eb0e95122312511d83683d7f0dee58
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
struct smm_loader_params is a struct that is passed around in the
ramstage code to set up either the relocation handler or the permanent
handler. At the moment no parameters in the stub 'smm_runtime' are
referenced so it can be dropped. The purpose is to drop the
smm_runtime struct from the stub as it is already located in the
permanent handler.
Change-Id: I09c1b649b5991f55b5ccf57f22e4a3ad4c9e4f03
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of passing on parameters from the stub to the permanent
handler, add them directly to the permanent handler.
The parameters in the stub will be removed in a later patch.
Change-Id: Ib3bde78dd9e0c02dd1d86e03665fa9c65e3d07eb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With CBnT a digest needs to be made of the IBB, Initial BootBlock, in
this case the bootblock. After that a pointer to the BPM, Boot Policy
Manifest, containing the IBB digest needs to be added to the FIT
table.
If the fit table is inside the IBB, updating it with a pointer to the
BPM, would make the digest invalid.
The proper solution is to move the FIT table out of the bootblock.
The FIT table itself does not need to be covered by the digest as it
just contains pointers to structures that can by verified by the
hardware itself, such as microcode and ACMs (Authenticated Code
Modules).
Change-Id: I352e11d5f7717147a877be16a87e9ae35ae14856
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50926
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The purpose of this is to eventually move the FIT table out of the
bootblock, generate it separately as a cbfs file and then have the FIT
pointer point to that cbfs file.
TESTED: extracted a FIT table using dd, added it as a cbfs file and see
that the FIT pointer correctly points to it. Also test that trying to
add a non valid FIT cbfs file results in an error.
Change-Id: I6e38b7df31e6b30f75b0ae57a5332f386e00f16b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
elemi does not use the GPP_B7/GPP_B8, so config to NC.
Currently, there is no functional impact.
BUG=b:182981460
TEST=emerge-volteer coreboot, boot into OS, and suspend/resume
successfully.
Change-Id: I7b491fd595b0e77e6dcce08e3172dbe592f63c37
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Mainboards do not need to know about `pei_data` to tell northbridge code
where to find the SPD data. Adjust `mb_get_spd_map` to take a pointer to
a struct instead of an array, and update all the mainboards accordingly.
Currently, the only board with memory-down in the tree is google/slippy.
Mainboard code now obtains the SPD index in `mb_get_spd_map` and adjusts
the channel population accordingly. Then, northbridge code reads the SPD
file and uses the index that was read in `mb_get_spd_map`, and copies it
to channel 0 slot 0 unconditionally. MRC only uses the first position of
the `spd_data` array, and ignores the other positions. In coreboot code,
`setup_sdram_meminfo` uses the data of each SPD index, so `copy_spd` has
to account for this.
Tested on Asrock B85M Pro4, still boots and still resumes from S3.
Change-Id: Ibaed5c6de9853db6abd08f53bbfda8800d207c3e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51448
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MRC only uses the SPD data for the first index, and ignores the rest.
Moreover, index 1 corresponds to the second DIMM on the first channel,
which does not exist on ULT (only one DIMM per channel is supported).
Copy the SPD to the first DIMM on channel 1 instead. Adjust northbridge
code to retrieve the serial number from the correct SPD data block.
Tested on Google Wolf, both channels are still correctly detected.
Change-Id: Ic60ff75043e6b96a59baa9e5ebffb712a100a934
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SLP_S0_GATE# signal is used in conjunction with the PCH's SLP_S0# to
provide an indication to the rest of the platform when the system is
entering its software-initiated low-power state (i.e. S0ix). This lets
the platform distinguish between opportunistic S0ix entry and the runtime
suspend mechanism.
BUG=b:180401723
TEST=abuild
Change-Id: I7fe2e3707465778baf56283617a8485a94f2dbca
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50881
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When running coreboot unit tests on a recent clang version, it helpfully
throws an error on memset(..., 0xAA, 0) because it thinks you probably
made a typo and meant to write memset(..., 0, 0xAA) instead. I mean, who
would ever memset() a buffer of zero bytes, right? Unfortunately, unit
tests for memset() want to do exactly that. Wrapping the argument in
parenthesis silences the warning.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I21aeb5ec4d6ce74d5df2d21e2f9084b17b3ac6e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Don't use 'is' and 'is not' for comparison with literals. This fixes
warnings like:
.../mbn_tools.py:1097: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(off) is not 0:
Change-Id: Idd68acfcbd1a07cbbb9ab41d9581c4850a431445
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The data needed to compute the permanent smbase for a core, when
relocating, is present in the ramstage data which the stub located at
DEFAULT_SMBASE (0x30000) calls back to. There is no need to fetch this
from via the stub params.
Change-Id: I3894c39ec8cae3ecc46b469a0fdddcad2a8f26c4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50763
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These stub params need to be synced with the code in smm_stub.S and
are consumed by both the smmloader and smmloader_v2. So it is better
to have the definition located in one place.
Change-Id: Ide3e0cb6dea3359fa9ae660eab627499832817c9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50761
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We are currently writing invalid ACPI tables. We are missing the GPP
ACPI names. There is an assert in acpi_device_write_pci_dev that checks
to see if we have a scope, but by default asserts don't halt, so we were
writing a NULL scope.
BUG=b:171234996
TEST=Boot majolica and dump ACPI tables
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I6a861ad1b9259ac3b79af76e18a9354997b0491e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In pursuit of the goal of eliminating the proliferation of raw region
devices to represent CBFS files outside of the CBFS core code, this
patch removes the get_spd_cbfs_rdev() API and instead replaces it with
spd_cbfs_map() which will find and map the SPD file in one go and return
a pointer to the relevant section. (This makes it impossible to unmap
the mapping again, which all but one of the users didn't bother to do
anyway since the API is only used on platforms with memory-mapped
flash. Presumably this will stay that way in the future so this is not
something worth worrying about.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iec7571bec809f2f0712e7a97b4c853b8b40702d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
