pci_rom_probe() can allocate memory when mapping a CBFS
file, so pci_rom_free() should be called before leaving
the function.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ie6fbbfd36f0974551befef4d08423a8148e151e7
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74779
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
It adds simple function, which frees the memory which
could be allocated by pci_rom_probe(). In the next step
it will be modified to free only memory, which was mapped
from CBFS.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ibc9aad34b6bf101a3a0c06b92ed2dc6f2d7b9b33
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74778
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move microcode load/unload to pre_mp_init and post_mp_init callbacks.
It allows to make sure that ucode is freed only if all APs updated
microcode.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The phoenix SoC does not support multiple EFS locations. Set the default
to the only valid value and prevent mainboard overrides by making the
option non-user-configurable.
TEST=build birman-phoenix
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0f720dbadf2d28a3c39daa4bd653a407be4893d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
For a unification of the naming convension, change from pascal case to
snake case style for parameter 'SataPortsEnable'.
Change-Id: I0df35125360eb42a03d5445011d72842cb2b8d7e
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75553
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Passing this option tells amdfwtool to create a text file, containing
the versions of the blobs below:
- PSP bootloader (type 0x01),
- SMU firmware (type 0x08),
- AGESA bootloader 0 (type 0x30),
- PSP bootloader AB (type 0x73).
Created file can be embedded into CBFS which allows to read the version
of blobs at runtime. This way version of blobs used to build the
coreboot image can be verified at runtime and also from the binary file.
Format of manifest file is following:
$ cat build/amdfw_manifest
type: 0x01 ver:00.35.00.13
type: 0x08 ver:00.5a.23.a6
type: 0x30 ver:2a.14.b0.10
type: 0x73 ver:00.35.00.13
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: Idaa3a02ace524f44cfa656e34308bd896016dff6
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Iadbce3124a88cf5be0aebde4a76ec6fd4b670216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Follow the eKTH7B18U_Product_Spec_V1.1 to add the device.
BUG=b:284381267
TEST=Check touch screen can detect in coreboot.
[INFO ] \_SB.I2C1.H010: ELAN Touchscreen at I2C: 02:10
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I4bd521410953892a477020a872de0d882001b178
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Follow the data sheet SA577C-12C0, Rev. 1.1 to add the device.
BUG=b:284381266
TEST=check touch pad can detect in coreboot.
[INFO ] \_SB.I2C0.D015: ELAN Touchpad at I2C: 01:15
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I0eb0ee1e6cb9c15bfe3964af6ce2ed02eee370a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Follow the schematic_0502 to add the audio codec and amp.
BUG=b:270109435
TEST=Check device can detect in coreboot.
[INFO ] \_SB.I2C3.RT58: Realtek RT5682 at I2C: 04:1a
[INFO ] \_SB.I2C3.D029: Realtek SPK AMP R at I2C: 04:29
[INFO ] \_SB.I2C3.D02A: Realtek SPK AMP L at I2C: 04:2a
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Icfec8d99be8fde986c5516e0c4cd50dae1edfa98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75477
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are only SSD connected to SATA ports on this mainboard. To prevent
misbehavior, set the correct hard drive type for enabled SATA ports.
BUG=none
TEST=Boot into OS and check the stability of the SSD
Change-Id: I2c2b0548865e87859a1d742295e09a731bfb3f76
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Intel's APL FSP offers the possibility to select the connected hard
drive type to SATA ports. One has the option to choose between HDD ('0'
- default) and SSD ('1').
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I52c3566fb3c959ada6be33f0546ac331f4867d10
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Due to mainboard restrictions a SATA link at Gen 3 can cause issues as
the margin is not big enough. Limit SATA speed to Gen 2 to achieve a
more robust SATA connection.
Change-Id: Ifdea4542836b9c75b5507324fbb06b9566a6fe1d
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75365
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In cases where there are limitations on the mainboard it can be
necessary to limit the used SATA speed even though both, the SATA
controller and disk drive support a higher speed rate. The FSP parameter
'SpeedLimit' allows to set the speed limit.
It should be noted that Gen 3 equals the default value '0'. This means
that inside FSP the same code is executed.
This patch provides a chip config so that this FSP parameter can be
set as needed in the devicetree on mainboard level.
Change-Id: I9c3eda0649546e3a40eb24a015b7c6efd8f90e0f
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75364
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check existence of crashlog records in CBMEM before copying them
to BERT, otherwise it can lead to NULL pointer access.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4288011866283a3a5fb8ec9e10cd51b794052b4e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75528
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Do not copy the crashlog record if the record is 0xdeadbeef
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I0edbf6902685a882876d525e63c5b602c1590ea1
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Check pmc_record_size variable for collecting PMC records,
instead of cpu_record_size variable.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4c35ba2bcf757231aa2872802eb82d4d50742cd9
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75526
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new Kconfig LINUXPAYLOAD_CMDLINE_VPD_OVERWRITE that can overwrite
Linux payload's kernel command line from VPD. Currently only overwrite
Linux kernel command line 'loglevel' via VPD key 'kernel_log_level'.
TESTED=On OCP Delta Lake, with kernel_log_level set to 0, warm reboot
time can see about 10 seconds improvement comparing to kernel log level
7.
Change-Id: Idf06c7ab9958c940fc3b23d560bb9dade991a6da
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
When the default pci_domain_read_resources() is used,
keep 32-bit memory resources below the limit given by
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a
workaround for missing/wrong reservations of chipset
resources.
This will help to get more stable results from our own
allocator, but is far from a complete solution. Indvi-
dual platform ASL code also needs to be considered, so
the OS won't assign conflicting resources.
Most platforms have reserved space between 0xfe000000
and the 4G barrier. So use that as a global default.
In case of `soc/intel/common/`, use 0xe0000000 because
this is what is advertised in ACPI and there are traces
of resources below 0xfe000000 that are unknown to core-
boot's C code (PCH_PRESERVED_BASE?).
Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top-
down allocation. Fixes EHCI w/ top-down in QEMU.
Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the power sequence of the panel [1] and PMIC datasheet [2],
the power on T2 sequence VSP to VSN should be large than 1ms, but it's
-159us now, and the power off T2 sequence VSP to VSN should be large
than 0ms, but it's less than 0 now. Let's modify the power sequence
to meet the datasheet requirement.
[1] HX83102-J02_Datasheet_v03.pdf
[2] TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=power sequence T2 pass
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Ib1625c6a211f849071393f69eaf5c649a8e7f72e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75298
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TPS65132S is designed to supply positive/negative driven
application. It communicates through standard I2C compatible interface,
and it intergrates a EEPROM whose contents will be loaded into the
register at startup. Since TPS65132S is used in staryu and geralt
projects, we move the implementation to mediatek/common.
The datasheet: TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=boot starmie to firmware screen
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Iad2c9bdea5824455efcef18b44876111061cfa1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75488
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DPTF parameters were verified by the thermal team.
BUG=b:282598257
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I1f38ef52d3906960f8b692595fcc3b39bc000243
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Use the proper format specifier for unsigned integers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5e39377d62981229531027b3153d5b343a0a7538
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75400
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't assume only one IO and one MEM domain resource.
Currently the code is awkward for bridge devices where loops over
resources are done twice. This would be avoided on top of other patches
that improve the allocator (topic:allocator) by adding a top-down mode.
However those patches break the tree and having the option to have
multiple resources per type would make it easier to get those patches in
without breaking the tree.
Change-Id: I3d3a60c9a4438accdb06444e2b50cc9b0b2eb009
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67018
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
This patch refers and backport some of previous work from Linux Kernel
(https://lore.kernel.org/all/1561689337-19390-3-git-send-email-ricardo.
neri-calderon@linux.intel.com/T/#u) that optimizes the MTRR register
programming in multi-processor systems by relying on the CPUID
(self-snoop feature supported).
Refer to the details below:
Programming MTRR registers in multi-processor systems is a rather
lengthy process as it involves flushing caches. As a result, the
process may take a considerable amount of time. Furthermore, all
processors must program these registers serially.
`wbinvd` instruction is used to invalidate the cache line to ensure
that all modified data is written back to memory. All logical processors
are stopped from executing until after the write-back and invalidate
operation is completed.
The amount of time or cycles for WBINVD to complete will vary due to the
size of different cache hierarchies and other factors. As a consequence,
the use of the WBINVD instruction can have an impact on response time.
As per measurements, around 98% of the time needed by the procedure to
program MTRRs in multi-processor systems is spent flushing caches with
wbinvd(). As per the Section 11.11.8 of the Intel 64 and IA 32
Architectures Software Developer's Manual, it is not necessary to flush
caches if the CPU supports cache self-snooping (ss).
"Flush all caches using the WBINVD instructions. Note on a processor
that supports self-snooping, CPUID feature flag bit 27, this step is
unnecessary."
Thus, skipping the cache flushes can reduce by several tens of
milliseconds the time needed to complete the programming of the MTRR
registers:
Platform Before After
12-core (14 Threads) MeteorLake 35ms 1ms
BUG=b:260455826
TEST=Able to build and boot google/rex.
Change-Id: I83cac2b1e1707bbb1bc1bba82cf3073984e9768f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch removes the wbinvd call preceding CR0.CD setting in
disable_cache() to improve the boot time performances. According to
some experimental measurements, the wbinvd execution takes between 1.6
up and 6 milliseconds to complete so it is preferable to call it only
when necessary.
According to Intel Software Developer Manual Vol 3.A - 12.5.3
Preventing Caching section there is no need to flush and invalidate
the cache before settings CR0.CD. The documented sequence consists in
setting CR0.CD and then call wbinvd.
We also could not find any extra requirements in the AMD64
Architecture Programmer’s Manual - Volume 2 - Memory System chapter.
This extra wbinvd in coreboot disable_cache() function does not seem
documented and looking into the history of the project got us all the
way back to original commit 8ca8d7665d ("- Initial checkin of the
freebios2 tree") from April 2003.
Even the original disable_cache() implementation (see below) is a bit
curious as the comment list two actions:
1. Disable cache cover by line 74, 75 and 77
2. Write back the cache and flush TLB - Line 78
But it does not provide any explanation for the wbinvd call line 76.
68 static inline void disable_cache(void)
69 {
70 unsigned int tmp;
71 /* Disable cache */
72 /* Write back the cache and flush TLB */
73 asm volatile (
74 "movl %%cr0, %0\n\t"
75 "orl $0x40000000, %0\n\t"
76 "wbinvd\n\t"
77 "movl %0, %%cr0\n\t"
78 "wbinvd\n\t"
79 :"=r" (tmp)
80 ::"memory");
81 }
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I08c6486dc93c4d70cadc22a760d1b7e536e85bfa
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Registered DIMM should be 'FORMFACTOR_DIMM' with 'DETAIL_REGISTERED'
instead of 'FORMFACTOR_RIMM', RIMM has been EOL for so many years.
Memory form factor info is now correct on 4th Gen Xeon server platform
with registered DIMM.
Signed-off-by: Ziang Wang <ziang.wang@intel.com>
Signed-off-by: Kehong Chen <kehong.chen@intel.com>
Change-Id: I1eea4717a2d60c6100c262a2284a2ac5109f114a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Set tcc_offset value to 20 in devicetree for Thermal Control Circuit
(TCC) activation feature for proto phase.
BUG=b:282865187
BRANCH=None
TEST=Build FW and test on Screebo board
Change-Id: I3a929aa20a700376d2a0a150911fed34e67f78eb
Signed-off-by: Wentao Qin <qinwentao@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75360
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Incorrect filename "MakeFile.inc" cause gpio.c can not be complied.
Rename to "Makefile.inc" and confirm gpio.c can load correctly.
BUG=b:281620454
BRANCH=dedede
TEST=build and confirm gpio.c can be loaded
Signed-off-by: Kevin Yang <kevin3.yang@lcfc.corp-partner.google.com>
Change-Id: I39947c66de04695e5242ab1affc328894f34f9f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75520
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable drivers for SoundWire codecs and define the topology in
the devicetree for the rex0 variant with the SoundWire daughter
board connected.
+------------------+ +--------------------+
| | | Headphone Codec |
| Intel Meteor Lake| +--->|Cirrus Logic CS42L42|
| SoundWire | | | ID 0 |
| Controller | | +--------------------+
| | |
| Link 0 +----+ +-------------------+
| | | Left Speaker Amp |
| Link 1 | +--->| Maxim MAX98363 |
| | | | ID 0 |
| Link 2 +----| +-------------------+
| | |
| Link 3 | | +-------------------+
| | | | Right Speaker Amp |
+------------------+ +--->| Maxim MAX98363 |
| ID 1 |
+-------------------+
This was tested by booting the firmware and dumping the SSDT table
to ensure that all SoundWire ACPI devices are created as expected with
the properties that are defined in coreboot under \_SB.PCI0:
HDAS - Intel Meteor Lake HDA PCI device
HDAS.SNDW - Intel Meteor Lake SoundWire Controller
HDAS.SNDW.SW00 - Cirrus Logic CS42L42 - Headphone Codec
HDAS.SNDW.SW20 - Maxim MAX98363 - Left Speaker Amp
HDAS.SNDW.SW21 - Maxim MAX98363 - Right Speaker Amp
BUG=b:269497731
TEST=Verified SSDT for SNDW in the OS. Playback and recording are also
validated on google/rex.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I3e11dc642ff686ba7da23ed76332f7f10e60fade
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73280
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The FBVDD_PWR_EN signal should be inverted in its control level
on Agah v.s. Hades. The original change covered the Hades
implementation, but needs to be updated to invert for Agah. This
change can be removed once we drop support for Agah.
BUG=b:280467267
TEST=built for Hades and Agah
Change-Id: I7f90c03b8d9b859004e5c124bf0a1f7b59921c3d
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75530
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Document how to modify the Broadwell refcode to support
the Intel GbE device.
Change-Id: I4f4f1e1c4ec2d79b3eb9f9c35fdc0330208e8509
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75418
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add ACPI DmaProperty for WLAN device. `is_untrusted` is eventually
ended up by adding DMA property _DSD which is similar to what
`add_acpi_dma_property` does for WWAN drivers, hence it makes sense to
have a unified name across different device drivers.
BUG=b:279676191
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I6d898a939aa0be31a671d2436a81c34f7a1ec030
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75460
Reviewed-by: Shou-Chieh Hsu <shouchieh@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Add 'common_config.acp_config' to the device tree, so we have the
correct pin configuration.
BUG=b:225320579
TEST=USE=fwconsole emerge-skyrim ... ; verify 'devbeep' works in
depthcharge console
TEST=Boot into ChromeOS, verify YouTube sound works with internal
speakers and headphone jack
TEST=Boot into ChromeOS, verify microphone with Google Meet
Change-Id: Ie2d79408104273d8a53214b683800fa0663c14d3
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Improve boot time performances by replacing the wbinvd instruction
with multiple clflush to ensure that the SIPI data is written back to
RAM.
According to some experimental measurements, the wbinvd execution
takes between 1.6 up and 6 milliseconds to complete. In the case of
the SIPI data, wbinvd unnecessarily flushes and invalidates the entire
cache. Indeed, the SIPI module is quite small (about 400 bytes) and
cflush'ing the associated cache lines is almost instantaneous,
typically less than 100 microseconds.
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I0e00db8eaa6a3cb41bec3422572c8f2a9bec4057
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Suggested-by: Erin Park <erin.park@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75391
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This brings the ACPI code more in line with both what the new code for
the AMD SoCs will do and also what the current Intel code does. This was
mainly done to have a reduced delta to the new AMD domain resource
handling functions to debug it, but it might still be useful to upstream
this change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487
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>
With the coreboot build process, `UniversalPayloadBuild.sh` calls
`UniversalPayloadBuild.py`. That Python script will unconditionally
build DXE as 64-bit, but accepts an argument for the entry point:
parser.add_argument('-a', '--Arch', choices=['IA32', 'X64'],
help='Specify the ARCH for payload entry module. Default build X64
image.', default ='X64')
Currently, ` -a IA32 -a X64` is passed, and the Python script will
use the `X64` argument, resulting in a payload that won't work with
coreboot.
Remove the `-a X64`, so the resulting build is a 32-bit entry point,
and 64-bit DXE, which works with coreboot.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I8a557d6e155a2938b44036d98f9274cc8b38f156
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73668
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This function can be called to more easily add a file to CBFS.
Additional file attributes can be added later:
cbfs-files-y += pagetables
pagetables-file := $(objcbfs)/pt
pagetables-type := raw
pagetables-compression := none
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
becomes
$(call add-cbfs-file-simple, pagetables, $(objcbfs)/pt, raw, none )
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
This is especially useful inside macros where you may want to add
an unknown number of entries.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I72bb2f21fb22f650b7970c7a37a48c10a4af0ed5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Incorrect memory part was used in CB:74745 to generate the DRAM Strap
ID. Amend the memory_parts_used.txt and regenerate the DRAM Strap ID.
BUG=b:272746814
TEST=Generate the DRAM Strap ID.
Change-Id: I0668d7e02345610a11f9113d8bbe99a474f33f1a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
The acpigen_resource_[bus_number,io,mmio*] functions didn't make it very
clear that they are generating resource producer ranges and not resource
consumer ranges. To clarify this, change the function names to
acpigen_resource_producer_[bus_number,io,mmio*] and explicitly add the
ADDR_SPACE_GENERAL_FLAG_PRODUCER flag which evaluates to 0, so this
doesn't change the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I334f38aa8ab418d5577f92b980ff750504e2bb4e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Grzegorz Bernacki