Expose configuration of Intel PAVP (Protected Audio-Video Path, a
digital rights protection/management (DRM) technology for multimedia
content) to Kconfig.
TEST=Able to boot Google/rex to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I416346995d744990054c8e0c839ada82c84b7550
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67423
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Follow the Thermal_paramters_list-0902.xlsx to modify DPTF parameters
and fan table.
1. Modify CRT of TSR0 - TSR3 to 97.
2. Modify TCC offset to 6.
3. Update new fan table.
BUG=b:244657172
TEST=emerge-brask coreboot
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: I751bc5442f64428c383034755cd5d74fbd0ea91e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67314
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify fan speed/duty table follow "Duty table.xlsx".
BUG=b:244262869
TEST=Boot to ChromeOS. Using SDV system, enter duty value, and then
system feedback fan speed.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Id5e885b96624d5fc31f1d42e3582c3ab01e08458
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67307
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-by: Ricky Chang <rickytlchang@google.com>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
The Kinox fan speed/duty table has 20 elements so raise the
DPTF_MAX_FAN_PERF_STATES from 10 to 20.
BUG=b:244262869
TEST=Boot to ChromeOS. Using SDV system, enter duty value, and then
system feedback fan speed.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: Iacd3ef0da926df5d174b215ab8ea4adc1a8b672e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67390
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Ricky Chang <rickytlchang@google.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
The PCIe WWAN module used on rex requires control over 4 signals to
successfully power it on. It is desirable to do this before passing
control to the payload, because the modem requires a ~10 seconds
initialization phase before it can be used.
The corrected sequence looks like:
1) Drive device into full reset and enable power in bootblock
2) Deassert FCPO in romstage, after power rails stabilize
3) Deassert WWAN_RST#, then WWAN_PERST# in ramstage
BUG=b:244077118
TEST=FM350 could be enumerated via lspci
Measured signals to check start-up Timing Sequence, tpr/ton1/ton2.
Tpr = 572mS
Ton1 = 6.3s
Ton2 = 6.3+4.17ms
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Change-Id: I6cda9348ef7f54efe5ba2358040596a1c2da1b13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67332
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable SRAM in devicetree so that resources are allocated properly
for it.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ibdd2ee455f5bf6cd95bba6bab8689da664bfcf54
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
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>
Daisuke Nojiri