Now that the PSP SMI handler for flash access is also implemented for
the PSP generation 1, the PSP SMI handler can be added to the
Stoneyridge code too. The actual PSP SMI handler code will only be added
to the build when SOC_AMD_COMMON_BLOCK_PSP_SMI is selected which isn't
the default case, so this patch doesn't change the current behavior
unless that option is also selected. This SMI handler mainly added for
completeness since the PSP firmware blobs released for Stoneyridge are
probably lacking the corresponding PSP-side code to send the PSP SMI to
the host. At least if I remember correctly the PSP bootloader release
for Stoneyridge has the ability to load the secure OS removed and since
the secure OS is the runtime component, some part of that is probably
what's sending those SMIs to the host. If there are some other PSP
bootloader builds that support loading the secure OS, this patch might
still be useful for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I78944e2de86bc1e8e277d22a7a8da517622f49a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84077
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that we have the local psp_smi_flash.h header, move the
psp_smi_spi_* function prototypes there.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I12cbbabf6a960836fe0c5dc1424c08550cb66a7a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84068
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Use the uint[8,16,32,64]_t data types everywhere instead of a mixture of
uint[8,16,32,64]_t and u[8,16,32,64] data types for consistency.
Suggested-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I36151ecf94619afaf690dbb73834fcff3c51fdac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Add helper functions to send the PSP commands to query the fTPM and
PSP capability bits as well as the HSTI state. All SoCs using any PSP
generation support the MBOX_BIOS_CMD_PSP_FTPM_QUERY command and some
generation 1 and all generation 2 PSP SoCs support the
MBOX_BIOS_CMD_HSTI_QUERY command, so implement those two in the common
psp.c. Only PSP generation 2 supports the MBOX_BIOS_CMD_PSP_CAPS_QUERY
command, so implement that one in psp_gen2.c.
This code is ported and modified from
github.com/teslamotors/coreboot/tree/tesla-4.12-amd
Document #54267 revision 1.06 was used as reference for the 1st PSP
generation and document #55758 revision 2.04 was used for the 2nd PSP
generation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4e17f994fb332690828c55742262da793e297d99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Rename MBOX_BIOS_CMD_PSP_QUERY to MBOX_BIOS_CMD_PSP_FTPM_QUERY to bring
it a bit more in line with document #55758 revision 2.04 and to avoid
confusion when another command is added in a follow-up patch. In
document #54267 revision 1.06 this command is called
MBOX_BIOS_CMD_PSP_QUERY and in document #55758 revision 2.04 it's called
MBOX_BIOS_CMD_FTPM_QUERY, so just name it MBOX_BIOS_CMD_PSP_FTPM_QUERY
in coreboot which should be the least confusing name for it that still
somewhat aligns with the documentation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id085b34363d39528bd125dfb77596d3ed13b6fa9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84065
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Implement the request buffer access functions for the PSP generation 1
case. In this case, only the SMI_TARGET_NVRAM is supported, so always
return this target NV ID and always return true in the validity checks
which in the PSP generation 2 case check if the target NV ID is valid.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7e141f846e930bab6972a281745c0180ac52c291
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84064
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The request buffer data structures differ between the PSP generation 1
and 2 in the way that the generation 2 added the 64 bit target NV ID
field right at the beginning of the request buffer data structures. In
order to make the data structure definitions common, remove the
target_nv_id struct element via the preprocessor in case the
SOC_AMD_COMMON_BLOCK_PSP_GEN2 option isn't selected. Since the request
buffer data structures are now common for both generations, also remove
the 'v2' from the struct names.
Document #54267 revision 1.06 was used as reference for the 1st PSP
generation and document #55758 revision 2.04 was used for the 2nd PSP
generation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe0bd2d8e6a5c39cc67a49e7bb3a51ce0900a39a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Factor out the code to access the request buffer into PSP generation
specific file. This is a preparation for adding PSP SMI flash access
support for the PSP generation 1 which has a slightly different request
buffer layout.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8e18f7ea53592d9fd413ad56e8d137cfc13ad5d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The existing comment on the mbox_default_buffer struct was outdated and
didn't reflect the current state, so rework it to keep it a bit more
generic and also add the document number for the newer generations of
CPUs. To better document which commands use non-default buffers, add the
names of the commands using the non-default buffers to those buffer
struct definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I510d953217240243392e8a415358524257bd28b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84061
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch removes the HAVE_ACPI_RESUME config option from the Google
Rex mainboard configuration. The Intel Meteor Lake SoC does not support
S3 (ACPI sleep state) entry/exit, and attempting S3 validation could
lead to abnormal platform behavior. This change ensures that `_S3` is
not listed as a valid wake source in the DSDT (Differentiated System
Description Table) after booting to the OS.
BUG=b:351025543
TEST=Booted google/rex successfully and verified that the `_S3` name
variable is not present in the DSDT.
Change-Id: I730ade628eea84c60ba003a0c871e729b0ee0a9f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84081
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This was adapted from CB:22693 from Iru Cai, which was based on
autoport. I do not physically have this system. Someone with physical
access to an E6230 running version A11 of the vendor firmware sent me
the VBT after running the command `intelvbttool --inlegacy --outvbt
data.vbt`. This new version of the port has not yet been tested.
The EC is the SMSC MEC5055, which seems to be compatible with the
existing MEC5035 code. As with the other Dell systems with this EC, this
board is assumed to be internally flashable using an EC command that
tells it to pull the FDO pin low on the next boot, which also tells the
vendor firmware to disable all write protections to the flash [1].
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Original-Change-Id: I8cdc01e902e670310628809416290045c2102340
Change-Id: I32927beea7c29b96a851ab77ed15b0160f16d369
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82153
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is QAL70/LA-7741P. I do not physically have this system;
someone with physical access to one sent me the output of autoport which
I then modified to produce this port. I was also sent the VBT binary,
which was obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running
version A21 of the vendor firmware. This port has not been tested.
The EC is the SMSC MEC5055, which seems to be compatible with the
existing MEC5035 code. As with the other Dell systems with this EC, this
board is assumed to be internally flashable using an EC command that
tells it to pull the FDO pin low on the next boot, which also tells the
vendor firmware to disable all write protections to the flash [1].
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I827826e9ff8a9a534c50250458b399104478e06c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is codenamed Vida. I do not physically have this system;
someone with physical access to one sent me the output of autoport which
I then modified to produce this port. The VBT was obtained using
intelvbttool while running version A14 (latest available version) of the
vendor firmware.
Tested and found to boot as part of a libreboot build based on upstream
coreboot commit b7341da191 with additional patches, though these do not
appear to affect SNB/IVB. The base E6430 patch was tested against
coreboot main.
The EC is the SMSC MEC5055, which seems to be compatible with the
existing MEC5035 code. As with the other Dell systems with this EC, this
board is assumed to be internally flashable using an EC command that
tells it to pull the FDO pin low on the next boot, which also tells the
vendor firmware to disable all write protections to the flash [1].
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I570023b0837521b75aac6d5652c74030c06b8a4c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82131
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is PAL70/LA-6611P. I do not physically have this system;
someone with physical access to one sent me the output of autoport which
I then modified to produce this port. I was also sent the VBT binary,
which was obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running
version A22 of the vendor firmware. This port has not been tested.
The EC is the SMSC MEC5055, which seems to be compatible with the
existing MEC5035 code. As with the other Dell systems with this EC, this
board is assumed to be internally flashable using an EC command that
tells it to pull the FDO pin low on the next boot, which also tells the
vendor firmware to disable all write protections to the flash [1].
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I5905f8c6a8dbad56e03bdeedc2179600d0c4ba46
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82130
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is Krug 14". I do not physically have this system; someone
with physical access to one sent me the output of autoport which I then
modified to produce this port. I was also sent the VBT binary, which was
obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running version
A02 of the vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I0283653156083768e1fd451bcf539b4e028589f4
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is PAL60/LA-6562P (UMA). The version with an Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port. I was also sent the VBT binary, which was obtained
from `/sys/kernel/debug/dri/0/i915_vbt` while running version A08 of the
vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ibdd40cc15642b8d404159d5962670ccc4167a9ec
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Based on autoport. data.vbt extracted from a running system
using "intelvbttool --inlegacy"
Like with 8200 SFF, OEM firmware write-protects itself, but not
the IFD, GBE or ME regions when FDO jumper is applied. Therefore,
ME can be shrunken with me_cleaner and BIOS region moved there.
Tested:
- Internal flashing from the latest endor BIOS (v2.33)
- Sandy Bridge Pentium G630 CPU
- RAM: 8+0, 8+4, 8+8 1866MHz DDR3
- SeaBIOS 1.16.2, metest86+ v6, coreinfo, nvramcui & tint payloads
- libgfxinit txtmode & corebootfb
- VGA, DisplayPort (DVI monitor through an adapter)
- Gigabit Ethernet
- All front and back USB ports
- Booting Void Linux
- Rebooting
- Mini-PCIe WLAN (PCIe)
- Both SATA ports: 2.5" & DVD
- PS/2 keyboard and mouse
- Fan control
- TPM settings in SeaBIOS
Untested:
- Second Mini-PCIe slot (or is it mSATA): connector not present on my unit
- MXM graphics
Not working:
S3: it sleeps for a few seconds and wakes up on its own
Change-Id: I1cba7a5e664758eba7ea2ab8a55658b307d1d173
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79583
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is Krug 15". I do not physically have this system; someone
with physical access to one sent me the output of autoport which I then
modified to produce this port. I was also sent the VBT binary, which was
obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running version
A14 of the vendor firmware.
This was originally tested and found to be working as a standalone
board port in Libreboot, but this variant based port in upstream
coreboot has not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ic9bfc028d4b8ae01ccc019157bb53e7764671134
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is PAL50/LA-6591P (UMA). The version with an Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port. I was also sent the VBT binary, which was obtained
from `/sys/kernel/debug/dri/0/i915_vbt` while running version A25 of the
vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ic48d9ea58172a5b13958c8afebcb19c8929c4394
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82126
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is QXW10/LA-7902P (UMA). I do not physically have this board;
someone with physical access to one sent me the output of autoport which
I then modified to produce this port. I was also sent the VBT binary,
which was obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running
version A21 of the vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
Change-Id: Idaf6618df70aa19d8e60b2263088737712dec5f0
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is QALA0/LA-7761P (UMA). The version with a Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port.
I was also sent the vbios obtained using intel_bios_dumper while running
version A22 of the vendor firmware, which I then processed using
`intelvbttool --inoprom vbios.bin --outvbt data.vbt` to obtain data.vbt.
This was originally tested and found to be working as a standalone board
port in Libreboot, though this variant based port in upstream coreboot
has not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I9fcd73416018574f8934962f92c8222d0101cb71
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Instead of using defines for command IDs and argument values, use enums
to provide more type safety. This also has the effect of moving the
command IDs to a more central location instead of defines spread out
throughout the header.
Change-Id: I788531e8b70e79541213853f177326d217235ef2
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Introduce a sandybridge-style devicetree setting for SPD addresses,
and use it instead of runtime code in mb_get_spd_map() for all
haswell boards without CONFIG(HAVE_SPD_IN_CBFS) - effectively all
boards except google/slippy.
Patch also covers recently added Z97 boards using Broadwell MRC.
Also update util/autoport to match.
abuild passes for all affected boards.
autoport builds, but otherwise untested.
Change-Id: I574aec9cb6a47c8aaf275ae06c7e1fb695534b34
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79025
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit aa6865291a.
Reason for revert: We applied this patch for touchpad stuttering issue
for XOl, but the same touchpad problem was reported. So we would revert
this change and apply kernel patch (crrev/c/5808335) to avoid the
touchpad issue.
Change-Id: I78139932e76dbd4128fb325dd70b7dcff3bcc81c
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
- Turn off L2C SRAM and reconfigure as L2 cache:
Mediatek SoC uses part of the L2 cache as SRAM before DRAM is ready.
After DRAM is ready, we should invoke disable_l2c_sram to reconfigure
the L2C SRAM as L2 cache.
- Configure DMA buffer in DRAM:
Set DRAM DMA to be non-cacheable to load blob correctly.
TEST=build pass, register(disable_l2c) read ok
BUG=b:317009620
Change-Id: I6a3cb63d3418f085f5d8d08b282dd59ea431c294
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83925
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
To reduce duplicate pad_func of MediaTek SoCs, move the pad_fun to a
common directory.
TEST=Build pass
BUG=b:317009620
Change-Id: I145233ef887a38251e8fc129b8357f236c5f7a2b
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
When the config of MCU firmware blob such as CONFIG_SPM_FIRMWARE is
non-empty, we should always expect the file to exist. Similarly, since
the device is unlikely to boot without the DRAM blob (assuming MRC_CACHE
doesn't contain valid memory training data), dram.elf should always
exist as well.
Therefore, remove the check for the existence of the blobs. Build would
fail if any of the blobs is missing.
Change-Id: I755e7c5a70b34b0c3d3915ab339c65263688aad7
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84053
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This will not succeed in compiling on all target and compiler
combinations but at least gets the ball rolling. The change is not
invasive.
Some notes:
- GCC has issues with LTO on ARM
- Clang uses LLD automatically on some arch
- Clang with LTO fails on x86 as it forwards the linking to GCC for some
reason
- SMM building succeeds but the binary is empty
Change-Id: Ieb9204777fd349542744a8946e2207731c37969c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add get_wifi_sar_cbfs_filename(). This function uses the FW_CONFIG
for WIFI_CATEGORY to choose the right wifi_sar hex file.
Below is the file mapping:
wifi_sar_0.hex = wifi6
wifi_sar_1.hex = wifi7
BUG=b:345596420
TEST=emerge-nissa coreboot chromeos-bootimage
Cq-Depend: chrome-internal:7607427
Change-Id: If8339a2a1d32d3e885ef87ea2ec2847f107f1fbd
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84051
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Iccmax of VccIn_Aux is 25A with MBVR design.
BUG=b:348258637
TEST=Local build successfully and boot to OS normally.
Change-Id: I59c420c03a8f01d185f616a2212798266b4251e0
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
EE change GPP_C1 from pull-up to OD&no pull-up in PCH GPIO Table.
BUG=b:358472598
TEST=Build and verified test result by EE team
Change-Id: I84d1b42a39bebbcd610cebc46f979018fc79238f
Signed-off-by: Roger Wang <roger2.wang@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83904
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some targets cannot be supported by clang as clang generates slightly
larger binaries which the hardware won't accept. This is usually the
case with CONFIG_CHROMEOS.
Change-Id: I88cf8ce16fb6c61c19d615e396f5871179b06fc8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69747
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCIE WLAN Bluetooth is on port8, need to correct USB port for PCIE WLAN
bluetooth companion device.
BUG=b:345596420
TEST=Build and test on nivviks, check BRDS is shown in SSDT.
Change-Id: I0908ff500434401bf89a5313427cf304f32cf929
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
PCIE WLAN Bluetooth is on port8, need to correct USB port for PCIE WLAN
bluetooth companion device.
BUG=b:345596420
TEST=Build and test on revin, check BRDS is shown in SSDT.
Change-Id: Ie8174567b863e1afe8b0a27e644e24e9d3de6d19
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84020
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
