This patch selects USE_UNIFIED_AP_FIRMWARE_FOR_UFS_AND_NON_UFS for
Orisa variant which intends to achieve a unified AP firmware
image across UFS and non-UFS skus.
BUG=b:345112878
TEST=Able to enter S0ix on Orisa eMMC sku after disabling UFS
during boot path.
Change-Id: I969b0c0c785ed4c408f6fc6de71e7d0c1a1ea27c
Signed-off-by: Amanda Huang <amanda_hwang@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch selects USE_UNIFIED_AP_FIRMWARE_FOR_UFS_AND_NON_UFS for
Google/Trulo variant which intends to achieve a unified AP firmware
image across UFS and non-UFS skus.
Note: Enabling this config would introduce an additional warm reset
during the cold-reset scenarios due to the function disabling of the
UFS controller as results we are expecting ~300ms higher boot time
(which might not be user visible because `cbmem -t` can't include
impacted boot time due to in-between resets).
BUG=b:355384185
TEST=Able to enter S0ix on Trulo eMMC sku after disabling UFS
during boot path.
Able to grep below debug prints while booting the eMMC sku.
[INFO ] FW_CONFIG value from CBI is 0x20000000
[INFO ] Disabling UFS controllers
...
[INFO ] fw_config match found: STORAGE=STORAGE_EMMC
Change-Id: I06a84fa8c3843edae5932e19d394b18b72ace422
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83654
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Amanda Hwang <amanda_hwang@compal.corp-partner.google.com>
System76 EC since system76/ec@80cfa91b9f ("acpi: Report RPM values
instead of raw tachometer values") performs the RPM calculation itself
and stores it in EC RAM where previously the raw tachometer values were
saved. The SBIOS is no longer required to make the conversion.
Change-Id: I82a4e25a8ce0f274b2d98e7ff2b12595acf6c3c5
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83308
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Currently we include a header file from the opensbi submodule.
That causes some issues, since we merge outside code with our own.
Most recently there have been made attempts to make the coreboot
codebase C23 ready. The code that we include from opensbi however causes
the build to fail, since it is not C23 ready.
This patch effectivily detaches the coreboot codebase from the opensbi
codebase and just copies the structure and definitions that we need from
opensbi into coreboot.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I9d8f85ee805bbbf2627ef419685440b37c15f906
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83641
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add sample DIMM slot configuration table for avenuecity CRB
and beechnutcity CRB. This table will be used to fill SMBIOS
type 17 table.
TEST=Boot on intel/avenuecity CRB
It will help to update Locator, Bank Locator and Asset Tag
with the value described in dimm_slot_config_table
Change-Id: I53556c02eb75204994a1bcb42eccb940e83bd532
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83326
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chromeec submodule is the largest submodule being pulled into the
coreboot tree, at over 400MB. The main branch also contains the majority
of these commits, so restricting it to a single branch still fetches
over 350MB.
Because there is only a single mainboard directory that enables the
build of the chromeec codebase by default, most people are fetching this
repo for no reason.
Based on this, we're going to change the way that the chromeec submodule
is used, fetching it the way we currently fetch external payloads. This
gives us 2 large advantages:
1) Only builds that actually need the chromeec repo will pull it down.
2) Each board that wants to build the chromeec codebase can use a
different commit, unlike submodules which all use the same "current"
commit.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I357c4c9b506dd3817a308232446144ae889bc220
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Now that we have a get_psp_mmio_base function that will work on all SoCs
that use the psp_gen2 code, we can move back to accessing the PSP
registers via their MMIO mapping. This sort-of reverts
commit 198cc26e49 ("soc/amd/common/block/psp/psp_gen2: use SMN access
to PSP").
When doing SMN accesses from the SMI handler after the OS has taken over
ownership of the platform, there's the possibility to cause trouble by
clobbering the SMN access index register from SMM. So that should be
either avoided completely or the SMI code needs to save and restore the
original contents of the SMN index register.
The PSP MMIO base will be set up by the FSP before the resource
allocation in coreboot and be treated like a fixed resource by the
allocator. The first SMI where corresponding handler calls
'get_psp_mmio_base' happens when ramstage triggers the APM_CNT_SMMINFO
SMI right after mpinit which happens after the resource allocation. So
the PSP MMIO base address is expected to be configured and so the
'get_psp_mmio_base' function will cache the base address and won't need
to do any SMN access in subsequent calls that might happen after the OS
has take over control.
This isn't currently an issue, since the only PSP mailbox command from
the SMI handler after coreboot is done and the OS has taken over will
be during the S3/S4/S5 entry, and this will be triggered by the OS as
the last step after it is done with all its preparations for suspend/
shutdown. There will however be future patches that add SMI-handlers
which can send PSP mailbox commands during OS runtime, and so we have
to make sure we don't clobber the SMN index register.
TEST=PSP mailbox commands are still sent correctly on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I25f16d575991021d65b7b578956d9f90bfd15f6c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83448
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add get_psp_mmio_base which reads the PSP MMIO base address from the
hardware registers. Since this function will not only be called in
ramstage, but also in SMM, we can't just look for the specific domain
resource consumer like it is done for the IOAPICs in the northbridge,
but have to get this base address from the registers. In order to limit
the performance impact of this, the base address gets cached in a static
variable if an enabled PSP MMIO base register is found. We expect that
this register is locked when it was configured and enabled; if we run
into the unexpected case that the PSP MMIO register is enabled, but not
locked, set the lock bit of the corresponding base address register to
be sure that it won't change until the next reset and that the hardware
value can't be different than the cached value.
This is a preparation to move back to using MMIO access to the PSP
registers and will also enable cases that require the use of the MMIO
mapping of the PSP registers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1d51e30f186508b0fe1ab5eb79c73e6d4b9d1a4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Instead of implementing the functions get_iohc_misc_smn_base and
get_iohc_fabric_id in the SoC code, move those functions to the common
AMD code, and implement get_iohc_info in the SoC code that returns a
pointer to and the size of a SoC-specific array of domain_iohc_info
structs that contains the info needed by the common code instead. This
allows to iterate over the domain_iohc_info structs which will be used
in a later patch to find the PSP MMIO base address in both ramstage and
smm.
TEST=Mandolin still boots and all non-PCI MIO resources are still
reported to the resource allocator
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifce3d2b540d14ba3cba36f7cbf248fb7c63483fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83443
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Move is_domain0 and is_dev_on_domain0 from the Intel Xeon SP code to the
common coreboot code so that it can be used elsewhere in coreboot too,
and while moving also implement it as functions instead of macros which
is more in line with the rest of helper functions in that new file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I954251ebc82802c77bf897dfa2db54aa10bc5ac4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83642
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In AMD platforms, the bit 4 of CMOS's Register A (0x0a) is DV0 bank
selection (0 for Bank 0; 1 for Bank 1) [1]. Since the MC146818 driver
accesses VBNV via Bank 0, the bit must be cleared before we can save
VBNV to CMOS in verstage.
Usually there's no problem with that, because the Register A is
configured in cmos_init() in ramstage. However, if CMOS has lost power,
then in the first boot after that, the bit may contain arbitrary data in
verstage. If that bit happens to be 1, then CMOS writes in verstage will
fail.
To fix the problem, define vbnv_platform_init_cmos() to call
cmos_init(0), which will configure the Register A and therefore allow
saving VBNV to CMOS in verstage.
[1] 48751_16h_bkdg.pdf
BUG=b:346716300
TEST=CMOS writes succeeded in verstage after battery cutoff
BRANCH=skyrim
Change-Id: Idf167387b403be1977ebc08daa1f40646dd8c83f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83495
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When we tried to add CMOS support to PSP verstage (CB:83495), the clang
builds failed on boards with cezanne SoC (such as Guybrush), due to
over-sized verstage. On the other hand, there is no such problem for gcc
builds on the same boards.
Building PSP verstage by clang generates much larger verstage size (81K)
compared with using gcc (67K). To unblock adding features to verstage,
temporarily enable -Oz for clang builds.
Change-Id: I033458556986ade88fb8e68499b632deae4dd419
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Updating from commit id 48f1bc9f5:
2024-05-02 10:13:54 +0200 - (Merge "feat(zynqmp): remove unused pm_get_proc_by_node()" into integration)
to commit id c5b8de86c:
2024-07-22 18:07:11 +0200 - (Merge "feat(debugv8p9): add support for FEAT_Debugv8p9" into integration)
This brings in 447 new commits.
Change-Id: I0a24e2b2b83d18d5ce8f3b1af710b5acde996ad0
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Updating from commit id b6f44e62:
2024-07-01 04:30:14 +0000 - (futility: updater: Increase try count from 8 to 10)
to commit id 4b12d392:
2024-07-17 01:47:56 +0000 - (scripts: Add a script to convert a vbprivk to a PEM)
This brings in 9 new commits:
4b12d392 scripts: Add a script to convert a vbprivk to a PEM
033d7bfa futility: updater: Increase try count from 10 to 11
f63e088e treewide: Ensure a space after if/for/while keywords
17a45712 2auxfw_sync: Clear display request before EC reset
e529f947 2ec_sync: Reactivate VB2_CONTEXT_EC_SYNC_SLOW
ca2d42d1 Android: Explicitly disable v1/v2 signing when using apksigner
fc7a7a5d futility: flash: Print ro_start and ro_len for debug
86542905 Migrate to new Android.bp build system
aa35a020 host/lib/host_p11_stub: Add missing includes
Change-Id: Ida8a27dcb0acf83022aff0118827e3d310fae1a5
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83612
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST=Build and boot on archercity CRB
No changes in boot log and 'dmidecode' result under centos
TEST=Build and boot on avenuecity CRB
It will add DMI type 16,17,19,20
Change-Id: I2f5b7a4ffabed033d54d4724b3c41246503166fe
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83325
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It is a new incoming Protectli product based on Alder Lake-P SoC.
More details and documentation will be added later.
TEST=Boot Ubuntu 22.04 LTS and Windows 11 on VP6670.
Change-Id: If4ae5b14b69806b6b0727d1ca1dcf56f47cfcd8e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80501
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Xol has a shutdown issue on our reliability test environment:
- High temperature
- No battery condition
It needs to have margin for the PL2 and PL4 values from the adapter
power, this will limit the PL2/PL4 values up to 30W/40W for xol's
45W power adapter. The new values are confirmed by our power team.
BUG=b:353395811
BRANCH=brya
TEST=built and verified MSR PL2/PL4 values.
Intel doc #614179 introduces how to check current PL values.
[Original MSR PL1/PL2/PL4 register values for xol]
cd /sys/class/powercap/intel-rapl/intel-rapl\:0/
grep . *power_limit*
constraint_0_power_limit_uw:18000000 <= MSR PL1 (18W)
constraint_1_power_limit_uw:55000000 <= MSR PL2 (55W)
constraint_2_power_limit_uw:114000000 <= MSR PL4 (114W)
[When connected 60W adapter without battery]
Before:
constraint_0_power_limit_uw:18000000
constraint_1_power_limit_uw:55000000
constraint_2_power_limit_uw:60000000
After:
constraint_0_power_limit_uw:18000000
constraint_1_power_limit_uw:30000000
constraint_2_power_limit_uw:40000000
[When connected 45W adapter without battery]
Before:
constraint_0_power_limit_uw:18000000
constraint_1_power_limit_uw:45000000
constraint_2_power_limit_uw:45000000
After:
constraint_0_power_limit_uw:18000000
constraint_1_power_limit_uw:30000000
constraint_2_power_limit_uw:40000000
Change-Id: Ic19119042ffdcc15c72764d8c27bcdce9f229438
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
It looks like some unused artifact: The PPC64 Makefile.mk doesn't
pick it up. Also, the only other architecture using this (x86) has
linker flags there, not compiler flags.
Change-Id: I734542db9ee5b62d9a39d303d4092cd83dfef54b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
One smbios type 4 should be provided for each CPU instance.
Create SMBIOS type 4 entry according to socket number, with a
default value of 1.
TEST=Boot on intel/archercity CRB
No changes in boot log and 'dmidecode' result under centos
Change-Id: Ia47fb7c458f9e89ae63ca64c0d6678b55c9d9d37
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83331
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If user continues to use the touchpad for over 3 minutes on Xol, the
pointer movement is stuttering.
Touchpad I2C transaction should appear during the interrupt signal level
is low, but we could see some more I2C transaction after the interrupt
signal(GPP_F14) went to high.
We found experimentally that changing the interrupt type to GPIO_INT
from APIC_IRQ improved this issue. We are still investigating, would
like to apply this change first for Xol's dogfooding.
BUG=b:350609957
BRANCH=brya
TEST=built and verified there's no stuttering issue on touchpad movement
Change-Id: Ie1b59355a694e5a42367a20e03f6c5f93225e79c
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
