Use the BIT() macro instead of reinventing the wheel.
TEST=timeless builds are identical
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I873013feebd30c86290dda692c7b137d5f3c4729
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add the missing spaces to two log message, like the one below.
WARNING: Device PCI: 03:00.0 requests a BAR with34 bits of address space, which coreboot is notconfigured to hand out, truncating to 29 bits
Change-Id: If933d8fb0db5b58ff12f043cc73172a3f6ffc624
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Missing power limit setting for Alder-Lake-N 7W soc.
Document reference: 645548 and 646929
BUG=b:245440443
BRANCH=None
TEST=Build FW and test on nivviks board and there is no error
message "unknown SA ID: 0x4617, skipped power limits configuration."
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Change-Id: Iefe17f5b574cc319fe9aad3850401a8aa8e31270
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
This area relates to storing of AP RO verification information.
CONFIG_VBOOT_GSCVD is enabled by default for TPM_GOOGLE_TI50 and
guybrush is using TPM_GOOGLE_CR50.
Signed-off-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Change-Id: I896b871bf2ac64e334514b979add9b8ac2c43945
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Change the name of the CALIBRATION_REGION definitions used in two
separate locations. This conflict was causing an error for the
lint-001-no-global-config-in-romstage test.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If6734f2a7d9be669586ea350fb9979fcd422b591
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, the "loading FSP-S" timestamp is added in fsp_silicon_init().
However, most Intel platforms actually load FSP-S earlier than this, in
soc_fsp_load(). So the timestamp is added in the wrong place.
Add the timestamp in fsps_load() instead, after the load_done early
return so that it will only be added for the first call.
Before:
949:finished CSE firmware sync 961,833 (17,998)
17:starting LZ4 decompress (ignore for x86) 1,018,328 (56,495)
18:finished LZ4 decompress (ignore for x86) 1,018,797 (469)
30:device enumeration 1,035,096 (16,298)
971:loading FSP-S 1,048,082 (12,986)
954:calling FspSiliconInit 1,049,331 (1,249)
After:
949:finished CSE firmware sync 959,355 (16,370)
971:loading FSP-S 978,139 (18,784)
17:starting LZ4 decompress (ignore for x86) 1,015,796 (37,656)
18:finished LZ4 decompress (ignore for x86) 1,016,271 (475)
30:device enumeration 1,032,567 (16,295)
954:calling FspSiliconInit 1,046,867 (14,300)
BUG=b:239769975
TEST="loading FSP-S" is added in the right place on nivviks (see above).
Change-Id: Ib26cf96ae97766333fe75ae44381d4f7c6cc7b61
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Having a CSE Lite SKU's firmware is not necessarily depending
on the underlying hardware nor on having ChromeOS installed as
already mentioned in commit f3419b29b7 ("soc/intel/common/cse:
Drop dependency on CHROMEOS for SOC_INTEL_CSE_LITE_SKU").
For example RVP Boards sometimes have a CSE LITE FW, if Chrome board
related stuff is tested, which doesn't necessarily imply a ChromeOS
being used. It is therefore changed to an option, which can be
changed in menuconfig.
Change-Id: I4da7feab881ae43528c9d852cc842ac93fa9c6de
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67078
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To test the linters, we want to invert the results so that any test that
passes shows up as a failure. This will allow us to verify that all of
the linters are working correctly.
This will be tested nightly as well as on changes to the lint tools.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia8024c6ab0c91fd9f630f37dc802ed3bc6b4608c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Enable the APOB_HASH feature. This improves boot times by ~10ms.
BUG=b:193557430
TEST=boot to OS and verify boot time improvement
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9628b67cd3206ffdbef23162c453dc183c69e5a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67377
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Comparing the APOB in RAM to flash takes a significant amount of time
(~11ms). Instead of comparing the entire APOB, use a fast hash function
and compare just that. Reading, hashing, and comparing the hash take
~70 microseconds.
BUG=b:193557430
TEST=compile and boot to OS in chausie with and without this option set
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I241968b115aaf41af63445410660bdd5199ceaba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67301
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Add xxhash functions. This is a very fast hash function, running at RAM
speed limits.
This code was adapted from the linux kernel with minor modifications to
make it fit in coreboot.
BUG=b:193557430
TEST=compile
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I8108af5ab14d8e6c6f5859bd36155c7d254e892c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
coreboot unit-tests framework requires tests to use
cb_run_group_tests() instead of cmocka_run_group_tests() for Jenkins
to work correctly. Wrapper ensures that each test has its own report
file and does not overwrite results of other tests.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Iead63cab0465f37b2da0c7b3ef256057e3a191a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67371
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates the SPD utility and generated SPDs for LP5X to use memory
type code 0x15 (LPDDR5X) instead of 0x13 (LPDDR5). This is done based on
Intel Tech Advisory Doc ID #616599 dated May 2022, page 15.
SPDs were regenerated with:
"util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5"
This only affects the SPDs for 2 memory parts for Intel SoCs and the
only board referencing these is rex.
BUG=b:242765117
TEST=inspected SPD hex dump
Change-Id: Iadb4688f1cb4265dab1dc7c242f0c301d5498b83
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67265
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
dptc_enable is being treated as a bool, so convert to explicitly be a
bool.
BRANCH=none
BUG=b:217911928
TEST=Build zork
TEST=Build guybrush
TEST=Build skyrim
Change-Id: I0e93d892b3b8016221812c8b9ec6c257dcf13ef5
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67188
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to layout restrictions on mc_ehl2, the SD-card interface is limited
to operate in DDR50 mode. The alternative modes SDR104 and SDR50 are not
supported. Limit the capabilities in the SD card controller to DDR50
mode only so that the SD card driver in OS will choose the right mode
for operation even if the attached SD card supports higher modes.
Change-Id: Idc7f1466ec71f4218f6b957cadeeffadd069eb2d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Since the new RTC is located in I2C bus 1 now, set the bus speed to
100 kHz as well.
Change-Id: Ica9468e559bc654545592a9b4d23f3164eafca8a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67102
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the latest redesign a new RTC was introduced on mc_ehl2. Instead
of the old RX6110SA the new Micro Crystal RTC RV3028 is used now. Since
the address of this new RTC conflicts with an EEPROM on I2C bus 2, the
new RTC was moved to I2C bus 1.
As the mainboard is not finished yet, there are no incompatibility
issues with this change. Every new mainboard will have the new RTC and
the older mainboards are not delivered yet.
Change-Id: I3dd00855b8c9b22bdea21d3c8563cdb392868751
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
With a redesign of mc_ehl2 the used RTC was changed. In order to be able
to select a different RTC type for every variant move the RTC Kconfig
switch into the variant's Kconfig file.
Change-Id: Ia24703ede6a935e3b9886df87237857baec7d6a0
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67100
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a driver for a new RTC from Micro Crystal. Supported
features are:
* configure backup voltage switchover via devicetree
* configure backup capacitor charging mode via devicetree
* set date if a voltage drop on backup voltage was detected
to either a user definable (devicetree) or coreboot build date
Change-Id: I37176ea726e50e4e74d409488981d7618ecff8bb
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Updating from commit id e0a6a512b:
2022-02-03 22:59:34 +0100 - (Merge changes from topic "msm8916" into integration)
to commit id 7805999e6:
2022-09-05 16:42:34 +0200 - (Merge changes from topic "st-nand-updates" into integration)
This brings in 1030 new commits.
Change-Id: I981956fbdcbcfa4ce185652478b9bb30d40f5686
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The implementations of register_reset_to_bl31() are the same for
MedaiTek platforms, so we extract them to soc/common/bl31.c.
BUG=None
TEST=build pass
Change-Id: I297ea2e18a6d7e92236cf415844b166523616bdf
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Some of the pll settings are incorrect, which cause problems in GPU
after booting into kernel.
- MFGPLL opp_ck_en bit isn't located at MFGPLL_CON1, so we need to fix
it to enable MFGPLL properly.
- Switch SPMI clock muxes to 260M to avoid kernel hang while probing
SPMI kernel driver.
TEST=GPU bringup correctly.
BUG=b:233720142
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Change-Id: I971109a5f72e3307899daaf5a5f26022124b559b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67355
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
The T4 of ANX7625 power on sequence should be larger than 0ms, but it's
-59ms now. So add 70ms delay between DSI_TE and LCM_RST.
BUG=b:242352915
TEST=The sequence T4 is larger than 0ms when power on.
Change-Id: I6b888707ec3c0612e396564e77c4cdbe92614dc5
Signed-off-by: Zanxi Chen <chenzanxi@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67315
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: wen zhang <zhangwen6@huaqin.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This reduce the difference with linux v6.0-rc3.
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I15e1a935665c38b8a2109d412b1d16f935cbb402
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Add a test to make sure that the linter fails correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I971951d4248dd10abe4c622025fdaf86e014c6cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The rules.h & compiler.h includes were removed in previous commits, so
add the checks to keep them out to the linter.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: If4964ff26f5e83abbbdd26c2b1cd9a2eab5a0a0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The header file `compiler.h` is automatically included in the build by
the top level makefile using the command:
`-include $(src)/commonlib/bsd/include/commonlib/bsd/compiler.h`.
Similar to `config.h`, 'kconfig.h`, and 'rules.h`, this file does not
need to be included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5d3eb3f5e5f940910b2d45e0a2ae508e5ce91609
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The header file `rules.h` is automatically included in the build by the
top level makefile using the command:
`-include src/soc/intel/common/block/scs/early_mmc.c`.
Similar to `config.h` and 'kconfig.h`, this file does not need to be
included manually, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I23a1876b4b671d8565cf9b391d3babf800c074db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67348
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without these, all SuperSpeed ports are wired to EHCI #2.
"superspeed_capable_ports" and "xhci_switchable_ports" should fit both
CMT and SFF variants, while "xhci_overcurrent_mapping" should be
consistent with the first 4 elements of mainboard_usb_ports[].
With this commit, SuperSpeed devices plugged in SuperSpeed ports are
wired to the XHCI on my own Z220 SFF.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: Ifddecfd1d32ed6ab84d7eed8dc2d85d83cbebbcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67089
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, if for some reason, the file-size command is called on an
empty string, the build will hang waiting for stdin input to cat.
Since wc accepts a file, this cat was unnecessary anyway. Put the file
name in quotes so an empty string will result in calling wc on an
actual null file instead of just leaving the filename blank. This
results in an error, and will probably halt the build.
BUG=214790407
TEST=Build default build.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I3dacf1968ed897a8ebd00f95583c2f254a7fb55a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The top-down allocation feature was merged prematurely before
platforms that don't report their resources correctly were fixed.
Let's turn it off by default.
Change-Id: I982e6d7355b9e689de10357d6c16ed718705270e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67328
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
git submodules should be ignored when parsing the coreboot tree for
lint errors. Those should be handled in their own commit checks.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I62b58f0c536312fe4677855bca8f44bc7d3ebc85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This reverts commit 117e436115.
Depends on top-down allocation to keep the behavior to place
hot-plug reservations above 4G. The latter was merged prema-
turely, though.
Change-Id: I5721cb84b29fc42240dff94f49a94461d88e7fbc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67329
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch fixes a hidden issue present inside FSP-S while coreboot
decides to skip performing MP initialization by overriding FSP-S UPDs
as below:
1. CpuMpPpi ------> Passing `NULL` as coreboot assume FSP don't need
to use coreboot wrapper for performing any
operation over APs.
2. SkipMpInit -----> Set `1` to let FSP know that coreboot decided
to skip FSP running CPU feature programming.
Unfortunately, the assumption of coreboot is not aligned with FSP when
it comes to the behaviour of `CpuMpPpi` UPD. FSP assumes ownership of
the APs (Application Processors) upon passing `NULL` pointer to the
`CpuMpPpi` FSP-S UPD.
FSP-S creates its own infrastructure code after seeing the CpuMpPpi
UPD is set to `NULL`. FSP requires the CpuMpPei module, file name `UefiCpuPkg/CpuMpPei/CpuMpPei.c`, function name `InitializeCpuMpWorker`
to perform those additional initialization which is not relevant for
the coreboot upon selecting the SkipMpInit UPD to 1 (a.k.a avoid
running CPU feature programming on APs).
Additionally, FSP-S binary size has increased by ~30KB (irrespective of
being compressed) with the inclusion of the CpuMpPei module, which is
eventually not meaningful for coreboot.
Hence, this patch selects `MP_SERVICES_PPI_V2_NOOP` config
unconditionally to ensure pass a valid pointer to the `CpuMpPpi` UPD
and avoid APs getting hijacked by FSP while coreboot decides to set
SkipMpInit UPD.
Ideally, FSP should have avoided all AP related operations when
coreboot requested FSP to skip MP init by overriding required UPDs.
TEST=Able to drop CpuMpPei Module from FSP and boot to Chrome OS on
Google/Redrix, Kano, Taeko devices with SkipMpInit=1.
Without this patch:
Here is the CPU AP logs coming from the EDK2 (open-source)
[UefiCpuPkg/CpuMpPei/CpuMpPei.c] when coreboot sets `NULL` to the
CpuMpPpi UPD.
[SPEW ] Loading PEIM EDADEB9D-DDBA-48BD-9D22-C1C169C8C5C6
[SPEW ] Loading PEIM at 0x00076F9A000 EntryPoint=0x00076FA24E2
CpuMpPei.efi PROGRESS CODE: V03020002 I0
[SPEW ] Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
[SPEW ] Notify: PPI Guid: F894643D-C449-42D1-8EA8-85BDD8C65BDE,
Peim notify entry point: 76FA0239
AP Loop Mode is 2
GetMicrocodePatchInfoFromHob: Microcode patch cache HOB is not found.
CPU[0000]: Microcode revision = 00000000, expected = 00000000
[SPEW ] Register PPI Notify: 8F9D4825-797D-48FC-8471-845025792EF6
Does not find any stored CPU BIST information from PPI!
APICID - 0x00000000, BIST - 0x00000000
[SPEW ] Install PPI: 9E9F374B-8F16-4230-9824-5846EE766A97
[SPEW ] Install PPI: 5CB9CB3D-31A4-480C-9498-29D269BACFBA
[SPEW ] Install PPI: EE16160A-E8BE-47A6-820A-C6900DB0250A
PROGRESS CODE: V03020003 I0
With this patch:
No instance of `CpuMpPei` has been found in the AP UART log with FSP
debug enabled.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8ebe0bcfda513e79e791df7ab54b357aa23d295c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66706
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In order to fix the USB port of type-C dongle has no function after
reboot/shutdown, modify ufp which is in google_chromeec_usb_pd_get_info
from the bit1 of type-c role (PD_CTRL_RESP_ROLE_DATA).
BUG=b:239138412
TEST=Built coreboot image and verified that using this patch can detect
usb drive after reboot.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: I73a4a6ec37129388783599125f067068d155d93f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67168
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GSPI0 pads required muxing to NF8. Support for extended
native functions was added in
commit b6c32d7fe4
BUG=b:244610269
TEST=build and booted on Rex
Change-Id: Iab4e0bc6890cd8e976c513fe87dda0da9b5f2ee0
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67317
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
index I/O argument to getopt_long is not the index to argv. Instead it
is an index into the optlong array corresponding to the parsed option.
Also getopt() uses a global variable optind to track the index of the
next argument to be processed. Use the optindex variable as an index to
extract the filename from argv.
BUG=None
TEST=Build and use amdfwread to read the Soft-fuse bits from Guybrush
BIOS image. Observed no changes before and after the changes.
Change-Id: I33c74a0c8e12c5af76954524cf7294b7541d286b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66553
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds source file dependencies to utilities so that they are rebuilt
when the source is changed. Previously, binaries were only built if they
did not already exist and never rebuilt to reflect source file changes.
BUG=none
TEST=verified binaries are rebuilt when source files are touched.
Change-Id: I4775fe0e00e0f5d4f8b4b47331d836aba53c0e69
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Add multiple fan support for dptf policies
BUG=b:235254828
BRANCH=None
TEST=Built and tested on Redrix system for two fans
Change-Id: I96ead90e3b805bd20de03e4bef4fa4b9fbaaaedd
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Update DPTF parameters from internal thermal team.
BUG=b:244373677
BRANCH=firmware-dedede-13606.B
TEST=Build image and verified by thermal team.
Change-Id: I8415e0d25a79764f0c1d11688728b7caa3b3d6a4
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
We currently have two competing mechanisms to limit the placement of
resources:
1. the explicit `.limit` field of a resource, and
2. the IORESOURCE_ABOVE_4G flag.
This makes the resource allocator unnecessarily complex. Ideally, we
would always reduce the `.limit` field if we want to "pin" a specific
resource below 4G. However, as that's not done across the tree yet,
we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint
to implicitly lower the `limit` of a resource. In this patch, this
is done inside the effective_limit() function that hides the flag
from the rest of the allocator.
To automatically place resources above 4G if their limit allows it,
we have to allocate from top down. Hence, we disable the prompt for
RESOURCE_ALLOCATION_TOP_DOWN if resources above 4G are requested.
One implication of the changes is that we act differently when a
cold-plugged device reports a prefetchable resource with 32-bit
limit. Before this change, we would fail to allocate the resource.
After this change, it forces everything on the same root port below
the 4G line.
A possible solution to get completely rid of the IORESOURCE_ABOVE_4G
flag would be rules to place resources of certain devices below 4G.
For instance, the primary VGA device and storage and HID devices
could be made available to a payload that can only address 32 bits.
For now, effective_limit() provides us enough abstraction as if the
`limit` would be the only variable to consider. With this, we get
rid of all the special handling of above 4G resources during phase 2
of the allocator. Which saves us about 20% of the code :D
Change-Id: I4c7fcd1f5146f6cc287bd3aa5582da55bc5d6955
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65413
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `IORESOURCE_ABOVE_4G` flag was only explicitly set for our dummy
device that reserves resources behind a hotplug port. The current re-
source allocator implicitly extends this to all devices below the port,
including real ones. Let's make that explicit, so future changes to the
allocator can't break this rule.
Change-Id: Id4c90b60682cf5c8949cde25362d286625b3e953
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66719
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add option to resource allocator v4 that restores the top-down
allocation approach at the domain level.
This makes it easier to handle 64-bit resources natively. With
the top-down approach, resources that can be placed either above
or below 4G would be placed above, to save precious space below
the 4G boundary.
Change-Id: Iaf463d3e6b37d52e46761d8e210034fded58a8a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Fred Reitberger