For consistency with other Intel southbridges, program PC BEEP verbs.
None of the boards in the tree using this southbridge provide PC BEEP
verbs, so this change makes no difference.
Change-Id: I94d24999af819cf3951510586fd4864d1ed3f2f1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use the `azalia_program_verb_table()` function in preparation to
deduplicate Azalia init code.
With this change, the "Azalia: verb loaded." message is now printed when
programming the verbs failed. This will be addressed once `codec_init()`
has been deduplicated.
Change-Id: I5d9e0f19429620166f2a6ef48ec7c963ee64b59c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently all the power sequencing for FPMCU is done explicitly in
different stages of coreboot. This can all be done by adding ACPI power
resources for FPMCU and clean up the unused code. Here is the expected
power sequence:
PowerUp : Assert EN_PWR_FP -> 3 ms delay -> De-assert FPMCU_RST_ODL
Shutdown : De-assert EN_PWR_FP -> Assert FPMCU_RST_ODL
Reboot : Shutdown -> 200 ms delay -> PowerUp
BUG=None
TEST=Build and boot to OS in Guybrush. Ensure that the FP is able to
unlock the system after the first login attempt. Ensure that the FP is
able to wakeup the system. Observed that the power resource is added
correctly in the FPMCU ACPI object
Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
{
PR01
})
Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot
{
PR01
})
PowerResource (PR01, 0x00, 0x0000)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x01)
}
Method (_ON, 0, Serialized) // _ON_: Power On
{
\_SB.CTXS (0x0B)
\_SB.STXS (0x20)
\_SB.STXS (0x0B)
}
Method (_OFF, 0, Serialized) // _OFF: Power Off
{
\_SB.CTXS (0x0B)
\_SB.CTXS (0x20)
}
}
Change-Id: I52322eaecf6961ff9a196ca9ab2d58b7d4599d4f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
We need to put USB setting in mux order.
BUG=b:204230406
TEST=Type C mux configuration is correct.
Wrong:
added type-c port0 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
added type-c port1 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
Correct:
added type-c port0 info to cbmem: usb2:3 usb3:3 sbu:0 data:0
added type-c port1 info to cbmem: usb2:2 usb3:2 sbu:0 data:0
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I19338e162db6145dbeb5830de1a372cf98f779a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Add wifi sar for galtic/galtic360/galith360
Using convertible mode of SKU ID to load wifi table.
Each Project and SKU ID correspond as below
galtic (sku id:0x120000)
galith (sku id:0x130000)
gallop (sku id:0x150000)
galtic360 (sku id:0x260000)
galith360 (sku id:0x270000)
BUG=b:203741126
TEST=emerge-dedede coreboot chromeos-bootimage \
coreboot-private-files-baseboard-dedede
verify the SAR table is correct in each project
Signed-off-by: FrankChu <frank_chu@pegatron.corp-partner.google.com>
Change-Id: If4203d176dd717fa62c88d9b4fab8a53847213fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marco Chen <marcochen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
We are currently counting how long it takes to print the waiting
message, in addition to the actual time we spent waiting. This results
in inflating the measurement by 1.7ms when the serial console is
enabled. This CL makes it so the print happens before the stopwatch
starts.
BUG=b:179699789
TEST=No longer see printk time taken into account on serial console
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib48e37c1b2cb462d634141bf767673936aa2dd26
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
In both the Picasso PPR (rev 3.16) and the Cezanne PPR (rev 3.03) bit 16
of the misc I2C pad control registers is defined as BiasCrtEn, so rename
I2C_PAD_CTRL_BIOS_CRT_EN to I2C_PAD_CTRL_BIAS_CRT_EN.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If39ac17a433cb90c944fdde038cd246a995e193a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59028
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update charger performance control table of DPTF for bugzzy.
Since the EC change chromium:197776876 modified maximum charging current
to reduce skin temperature, this change adjusts the charging performance
table with the modified value.
BUG=b:197776876
BRANCH=dedede
TEST=emerge-dedede coreboot
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Change-Id: I33e176fcf5d380b315ff352c6c65af3b8b93c4b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This drops VBOOT_NO_BOARD_SUPPORT.
There is little impact of always having recovery_mode_switch()
implemented in bootmode.c. A weak write_protect_state() is not
necessary as there is no BOOT_DEVICE_SPI_FLASH with the emulation.
Call to fill_lb_gpios() is already guarded with CONFIG(CHROMEOS)
so the weak implementation would not be referenced.
Change-Id: I3c00b30c5233ae3556b7622f97c3166668c8ab12
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Technically, it's not depending on the hardware but on the software
(OS/payload), if the PM Timer is optional. OSes with ACPI >= 5.0A
support disabling of the PM Timer, when the respective FADT flag is
unset. Thus, drop this guard.
For platforms without hardware PM Timer (Apollo Lake, Gemini Lake) the
Kconfig `USE_PM_ACPI_TIMER` depends on `!NO_PM_ACPI_TIMER`.
As of this change, new platforms must either implement code for
disabling the hardware PM timer or select `NO_PM_ACPI_TIMER` if no such
is present.
Change-Id: I973ad418ba43cbd80b023abf94d3548edc53a561
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lance Zhao
In the non-XIP world, FSP is normally memmapped and then decompressed.
The AMD SPI DMA controller can actually read faster than mmap. So by
reading the contents into a buffer and then decompressing we reduce boot
time.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I28d7530ae9e50f743e3d6c86a5a29b1fa85cacb6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
AMD platforms pass in the base address to cbfs tool:
fspm.bin-options: -b $(CONFIG_FSP_M_ADDR)
There is no technical reason not to allow FSP-M to be relocated when
!XIP. By allowing this, we no longer need to pass in the base address
into cbfstool when adding fspm.bin. This enables passing in the
`--alignment` argument to cbfs tool instead. cbfstool currently has a
check that prevents both `-b` and `-a` from being passed in.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I797fb319333c53ad0bbf7340924f7d07dfc7de30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
