For LTO we want to link everything in one go.
Change-Id: If2c186eb87072e0b80c7e8998b2a0d9bdfddf740
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84037
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When clang supports linking bare metal targets it defaults to LLD for
linking which linking those raw data structures used to generate CBFS
page tables does not fare well.
Change-Id: I66fb374a456ea752a97a41426c5a98e6747f3a92
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We have to reset the USB hub as early as possible. Otherwise the USB3
hub may not be usable in the payload. This design has been introduced
since Cherry.
TEST=build pass.
BUG=b:317009620
Change-Id: Iea793b4b04bd009d0354e2331604bccf30466a23
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84024
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to RDC#646929 Power Map, there are two expected values of
VccInAuxImonIccImax and the value has to align with HW design.
But in current code, vccin_aux_imon_iccmax is hard code to 27000 (27A),
hence, provide a config for projects modification.
BUG=b:330117043
BRANCH=firmware-nissa-15217.B
TEST=Modify the register and add a printk to output a debug message
to observe whether the value is changing as expected.
Change-Id: I0651f0eb8a5c32b27c524e43bbf6f2a184b95657
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
This allows better debugging of the build by writing all the commands
run by the build into a file by replacing the standard shell.
Run with:
make SHELL="${PWD}/util/scripts/capture_commands.sh"
This will allow us to verify that the commands being run are posix
compliant.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I67efc5096747c2e746642639f88273132e070e49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
With `probe unprovisioned` fw_config rule, there is no need to define an
explicit STORAGE_UNKNOWN option. Hence remove it.
BUG=None
TEST=Build Lotso FW image.
Change-Id: Ia170a6e006cb51e95fbaf3efe1106ca907165eca
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84094
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Bob Moragues <moragues@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This feature is not required in Brox devices. Hence disable the
concerned device.
BUG=None
TEST=Build Brox firmware and boot to OS. Ensure that the concerned
device is disabled in the OS.
Change-Id: I355852c780c552e6f9b2c28508f53580f392c1b9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84093
Reviewed-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
`boot_dev` can be const, and we can use MEM_REGION_DEV_INIT() as all
the values are known at compile time.
Change-Id: Icd3757ba4b5e8bfbee9e9c9d18bf0ee71520a8ac
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84089
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Panel CSOT MNB601LS1-3 will flicker once during enter Chrome login
screen, it is because it inserts 12 blank frames if it receives the
unmute in VB-ID.
Always override the mute in VB-ID to avoid Tcon EC detected the
audiomute_flag change.
BUG:b=357764688
BRANCH=firmware-nissa-15217.B
TEST:Verfied on Anraggar and cannot reproduce the issue
Change-Id: I711dfd0803440e4b04f02849fed529c3872e023d
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This allows clang to link x86 bare metal targets.
TESTED: Qemu i440fx and q35 boot to payload with both 32 and 64bit code
compiled with clang and LTO enabled with updated linker script.
Change-Id: I943215c8714e392e52ea35667f2bf21e517c4255
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84032
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that driver skips
initial probe during kernel boot and prevent privacy LED blink.
TEST=Build and boot nivviks. Monitor the camera LED blinking
during boot.
Change-Id: I979207d1b6d55f78dea20d3366ef4a833ee9c86d
Signed-off-by: Sowmya V <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch eliminates the LPC_IOE_COMA_EN and LPC_IOE_COMB_EN IO enables
from the io_enables variable in the pch_early_iorange_init() function
because lpc_io_setup_comm_a_b() is intended to activate legacy COM
ports like COM-A (0x3F8 - 0x3FF) and COM_B (0x2F8 - 0x2FF).
These COM ports are being activated unconditionally, which is
undesirable for the Intel Alder Lake platform and causes traffic over
the IO bus.
As a result, this code is being removed and platforms that select
DRIVERS_UART_8250IO can activate legacy COM ports.
BUG=b:354066052
TEST=Able to boot google/redrix to the operating system and confirm
that there was no traffic over legacy COMs while being monitored
using the eSPI analyzer.
Change-Id: I7a6e38bd151f823d37c07ee89a800489122cc209
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84080
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes the SOC_INTEL_GFX_MBUS_JOIN configuration option.
Support for fast modeset joining has been added to the mainline i915
kernel driver (https://patchwork.freedesktop.org/series/130480/),
making this coreboot-specific workaround unnecessary.
BUG=b:291885733
TEST=Successful build and boot of google/marasov with single and dual
displays, no redundant boot splash.
Change-Id: I53c08a0e7a40b24db7cc910c5b9adc2376a9bb17
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paz Zcharya <pazz@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
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>
Move config PAYLOAD_FIT_SUPPORT out of the `if !PAYLOAD_NONE'. It's
independent of the choice to add a payload right away.
Change-Id: I4b9cd13bf017d4afc30d1599ecc2faaf87bf0213
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This makes it easy to switch between x86_32 and x86_64 in payloads.
Change-Id: I3ac5f24d83dc80db924e92b53403c477e6256c44
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
The value used is not acceptable to BFD linker.
Change-Id: I0f134a96c596d69e10dd441b96184b119e9f1908
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84013
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows nvramcui to be build with clang.
Change-Id: I5e56ead81fc92b7ba4fb63a2c098b0e10b01ca53
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84010
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
