The currently used panel type could work with 500 ms but increasing
the value to 1 second allows to use a wider range of LVDS LCD panels,
as many of them specify the delay of 1 s as minimum.
The patch has already been made for mc_ehl3 and serves the purpose of
standardization.
commit c0221aa980 ("mb/siemens/mc_ehl3/lcd_panel.c: Set LVDS re-power
delay to 1 s")
Change-Id: Ife26ff27b41298ceeed7d9aed0c1ae5553ab5ff8
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
This patch refactors GPR0 unlock function to add few important
logic as below
1. Perform GPR0 unlock if GPR0 is locked.
2. While unlocking dump the GPRD PCH strap details
3. Additionally, print the GPR start and end range if GPR0
protection is enabled.
TEST=Able to test GPR0 protection on google/rex and google/yahiko.
Exp 1: Trying to unlock GPR0 protection for a locked image
> ifdtool -p mtl -g image.bin -O image.bin_unlock
File image.bin is 33554432 bytes
Value at GPRD offset (64) is 0x83220004
--------- GPR0 Protected Range --------------
Start address = 0x00004000
End address = 0x00322fff
Writing new image to image.bin_unlock
Exp 2: Trying to unlock GPR0 protection for a unlocked image
> ifdtool -p mtl -g image.bin_unlock -O image.bin_unlock
File image.bin_unlock is 33554432 bytes
GPR0 protection is already disabled
Change-Id: Id35ebdefe83182ad7a3e735bdd2998baa0ec3ed7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80216
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This is causing an assertion error on the devices that don't have CNVi
enabled because CNVi is hidden behind a FW_CONFIG flag in the
overridetree now.
BUG=b:319188820
BRANCH=None
TEST=emerge-brox coreboot chromeos-bootimage
make sure we can boot to kernel on device.
Change-Id: Ifcfbc04825d4d4e7f2874a4c52f9c5cf3e657856
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80211
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds the ability to add a flat-binary using menuconfig.
Test: boot hifive-unmatched mainboard with the following config:
CONFIG_PAYLOAD_NONE=n
CONFIG_PAYLOAD_ELF=y
CONFIG_PAYLOAD_FILE="~/repos/linux-riscv/arch/riscv/boot/Image"
CONFIG_PAYLOAD_IS_FLAT_BINARY=y
CONFIG_PAYLOAD_OPTIONS="-l 0x82000000 -e 0x82000000"
CONFIG_COMPRESSED_PAYLOAD_LZMA=y
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I48c6b53a0c9f5b173c89f1a294a0c37fa1a58f31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79950
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds APCB blobs to the mainboard directory and it replaces
CB:76445 Also this brings onyx_poc mainboard inline with how APCB are
included in other AMD mainboard: commit 95d05d8301 ("mb/google/zork:
Add and use APCB configuration data"), commit I352f58e0d39 ("mb/google/
skyrim: Add and use APCB configuration data") and commit I1c34528fa0f
("mb/amd/onyx_poc: Add and use APCB configuration data").
BUG=none
TEST=build/boot onyx_poc
Change-Id: I1c34528fa0fd15b847c22c995713078c60ac3873
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80204
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As with other devices with only an external display, the Librem mini/
mini-v2 need a few extra seconds (vs an internal panel) for display init in order for the edk2 boot splash to be visible before the
default boot target is booted.
TEST=build/boot Librem Mini v2 w/edk2 payload, verify splash screen
shown / user has time to enter setup menu.
Change-Id: I9d2d514719a9918ee58cc63969b3adae44ac1632
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2a6a4d1eb7e0d0cd32c8690caf3eff340cdb0d8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80124
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id09eafd293a54198aab87281f529749325df8b07
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add an ACPI stub containing the SATA device in proper scope, along with
the device status, so that there exists a device to be referenced from
the PEPD LPI constraint list. Fixes a Windows BSOD INTERNAL_POWER_ERROR
on devices with enabled SATA ports.
TEST=build/boot Win11 on google/puff (kaisa).
Change-Id: I951c62d09609ed73079fe97ea9ce49fdee333272
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
This reverts commit d64b66ba26:
"soc/intel/cannonlake: Add missing min sleep state for thermal device."
Reverting because commit e00523aae2 ("soc/intel/cannonlake: Drop
entries from soc_acpi_name()") removed the ACPI device name for the PCH
thermal device, since there is no ACPI device defined for it. Removing
the name without removing the minimum sleep state caused an invalid LPI
entry to be created, which caused a Windows BSOD: INTERNAL_POWER_ERROR.
TEST=build/boot Win11 on google/puff (wyvern).
Change-Id: I2dfe76d5f72cde7742cee338fa24eaafb84c4604
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80057
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
When the device right below the MPIO chip driver has downstream devices
without another chip in between, those downstream devices will also have
their chip_ops entry set to vendorcode_amd_opensil_genoa_poc_mpio_ops.
To avoid adding the same MPIO descriptor again for those additional
downstream devices, make sure that the chip_info pointer of the device
isn't the same as the one of the parent device, since that's only the
case for those additional downstream devices.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6ba90fdc83ba089127e6722778bfef29dd480bb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80149
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Call setup_opensil, opensil_entry, and fch_init in the right order from
the init method of the SoC's chip operations. This brings this SoC both
more in line with the other SoCs and avoids using boot state hooks for
this which also makes the sequence in which those functions are called
easier to understand. Previously the boot states were used so that
setup_opensil was run before configure_mpio which was run before
opensil_entry(SIL_TP1), but since configure_mpio is called from
setup_opensil, this is no longer necessary.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same. The FCH init code now runs
before the resource allocation like on the AMD SoCs that rely on FSP.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic752635da5eaa9e333cfb927836f0d260d2ac049
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79985
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of calling configure_mpio from the init function of the MPIO
chip struct for the first device that has this struct as chip_ops, call
if from setup_opensil. This will allow to do the calls into openSIL from
the SoC's chip_ops init function instead of having to rely on boot state
hooks. configure_mpio needs to be called after the xSimAssignMemoryTp1
call which sets up the openSIL data structures, but before the
opensil_entry(SIL_TP1) call for which the MPIO data structures need to
be filled for it to be able to initialize the hardware accordingly.
Since the vendorcode_amd_opensil_genoa_poc_mpio_ops struct now no longer
assigns configure_mpio to the init function pointer, we have to check
if the device's chip_ops pointer points to
vendorcode_amd_opensil_genoa_poc_mpio_ops instead of checking if the
chip_ops' init function is configure_mpio to match for the devices below
the MPIO chips in the devicetree.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If37077c879e266763fd2748a1a8d71c63c94729b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since we pass va_list list to the print function, we need to use vprintk
instead of printk. Earlier versions of this code used vsnprintf and a
local buffer, but when that code was reworked to not need the temporary
buffer, it was replaced by printk instead of the correct vprintk.
TEST=Now the console output from openSIL looks as expected:
Example line from openSIL's console output when it prints the MPIO
configuration from a log some commits before this patch:
Host PCI Address - -1352681400:-1353251983:7
Same line with this patch applied looks how it's supposed to:
Host PCI Address - 0:0:0
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Ia931cc80dea5b7eabb75cfb19f8baa9a09cd2dbf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80203
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some variants added the generic gfx driver with an LCD device without
specifying the address, which is required for the backlight controls
to be functional under Windows. Add the address value where missing.
Address value used (0x80010400) is same as on other Brya variants which
did properly set it, and is taken from the ACPI 6.5 spec section B.4.2,
_DOD (display output device enumeration), table B-2:
- bit 31 = use the ACPI-defined (vs vendor-defined) bit scheme for bits
15-0
- bit 16 = platform firmware can detect the device
- bit 10 = display type is internal/integrated flat panel (aka LCD)
TEST=build/boot Win11 on google/brya (osiris), verify ACPI backlight
controls functional.
Change-Id: Id24e330cfb7c993d12665a704e1ca78e2e38874f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
There was a mistake in the gpio spreadsheet provided by the HW team
and the GPIO assignments for the EC INT and WAKE signals got switched
from what it was in the schematics. The correct assignments are:
GPP_D0 = EC_PCH_INT_ODL
GPP_D1 = EC_PCH_WAKE_ODL
BUG=b:311450057,b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Will try to boot OS image on device and see if there are any
ec errors.
Change-Id: I02057aeb5d82218dbbe4c939d4feb87a4d3da678
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79886
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4790adb41cb62c8c8dd44261a2926dfb6350955a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80111
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Icfdadfa6705a64655b38aca25be0818ec26429f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80110
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ib8a2ae26ed4380592d15e1a7b2d682639413af01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80109
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I85cda24aa7dec82d23e8a321dac03ec737f4c503
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80108
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I92f8bd7e1c9fc6e4120fb94c2299a266304e19de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80107
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I134acc26c0a79d974a6dd0a3b257f961db7e2d86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80106
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
