This patch adds a new variant called Marzipan that is identical to Lazor
for now.
BUG=b:182181519,b:182018606
BRANCH=master
TEST=make
Change-Id: I92b667c63b0a06255d1e9511d7486293d8b4426a
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add support SPI_FLASH_GIGADEVICE for some project.
BUG=b:182246432
BRANCH=trogdor
TEST=emerge-strongbad and test with power on.
Signed-off-by: xuxinxiong <xuxinxiong@huaqin.corp-partner.google.com>
Change-Id: I6ab948909f4e17b4b992be6d699646f7a62bef7d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The X200 would undock itself when waking up from S3, requiring a
physical reconnection before the dock would work again.
Similar to 4611ad8, this reintroduces h8_mb_init() for the X200. A hook
function h8_mb_init() will be called at the end of h8_enable(), in place
of the ancient h8_mainboard_init_dock().
This should fix the regression the X201 and T410 also suffered from for
the X200.
Change-Id: Icb6dd145e56b90e0e04133810c5e9ac7b641ad68
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51123
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit c4aa24fc12 (doc/mb/lenovo/montevina: Clarify use of bincfg)
renamed a section, and the link referencing it by its old title no
longer works. Update the link, and remove the `a completely new one`
part from it as well, for consistency with the aforementioned commit.
Change-Id: I22e8b3237dafb3397bc901804a57e905f806839d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This will not enable M.2 SATA drive if the ME config was lost
(For instance after flashing a full flash factory image)
This is required so that the system can boot without FIA MUX error
during flash update procedure.
Change-Id: I55a8bcdc30bc67af2d3e9ccb8844eac599727108
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This includes the bg-prov tool.
Change-Id: Iba8efe3bcb67694da76ef78abaa0562d47f7850b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
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 argument provided to the function was always the same as the one
computed inside the function so drop the argument.
Change-Id: I14abf400dce1bd9b03e401b6619a0500a650fa0e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51527
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>
Remove variables that are either constants or are just assigned but
not used.
Change-Id: I5d291a3464f30fc5d9f4b7233bde575010275973
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50784
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>
Keep a copy of start32_offset into ramstage to avoid needing to pass
arguments, calling from assembly. Doing this in C code is better than
assembly.
Change-Id: Iac04358e377026f45293bbee03e30d792df407fd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50765
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
No need to do this assembly anymore.
Change-Id: I69b42c31e495530fe96030a5a25209775f9d4dca
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.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>
No need to restrict this further than the platform default,
and will be problematic with the addition of the upcoming
6C/12T Librem 14 board.
Change-Id: I1913992ec12578e1ad3bf6bf679d1a35a46d7370
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This I/O range is for a PM channel on the EC, not the PCH PMC.
Change-Id: I64422e537c1edcd0673cf87f16139fb117b10e75
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51604
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 artifacts can then be run on test system.
Change-Id: I2300af7b9be5fbb42a874566971854b93292885e
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51293
Reviewed-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
OIPG is a Package. Define the type so it doesn't default to UnknwonObj.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I068ed4ae95967aa884506c4971ee2e2dba7b5e4f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51537
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes the unknown reference errors for OIPG. Since Majolica
doesn't actually have any of the GPIOs ChromeOS uses, we leave
the arrays empty.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifeae84e0ccab187a4e7131cd6ea9e1336d79df67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51536
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIOs should be configured in ramstage even if they are configured in an
earlier stage.
BUG=b:180721208
TEST=builds
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: I9896db41dbe2812856357510bc4420482e73ab3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51547
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>
It is currently only used in this translation unit.
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: Ib779a38306fb45320f3e4eb71f63630023d59906
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51535
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
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>
In case the VPD variable cannot be read.
Change-Id: I79fae6f4b4aad91a4040387ca6ddee8dfcc34d90
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51559
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I2e4f1d1551141c6225e762631e52d71357112425
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Configure early GPIOs in verstage if it is run in PSP otherwise
configure them in bootblock.
BUG=b:182211161
TEST=builds
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ic1faeea59462319c1652c69034b4dde01669e13b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Mathew King <mathewk@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>
If the board settings aren't valid, Port E uses the settings for earlier
board revisions, which is undesired. Disable Port E by default on R04+.
Change-Id: I03bd50b915a2120283b77179debaa735bb7ef027
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51529
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
This is only consumed by the stub and not by the relocation handler or
the permanent handler, so move it out of the runtime struct.
Change-Id: I01ed0a412c23c8a82d88408be058a27e55d0dc4d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
Kevin Chiu