Enable x86_64 support for MRC.bin:
- Add a wrapper function for console printing that calls into
long mode to call native do_putchar
- Remove Kconfig guard for x86_64 when MRC is being used
Tested: Booted Lenovo X220 using mrc.bin under x86_64 and
MRC is able to print to the console.
Change-Id: I21ffcb5f5d4bf155593e8111531bdf0ed7071dfc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add another mode_switch assembly function to call x86_64 code from
x86_32 code. This is particullary useful for BLOBs like mrc.bin or
FSP that calls back into coreboot.
The user must first wrap all functions that are to be called from
x86_32 using the macro prot2lm_wrapper. Instead of using the original
function the wrapped functions must be passed to the x86_32 BLOBs.
The assembly code assume that 0-3 32bit arguments are passed to
the wrapped function.
Tested:
- Called x86_64 code from x86_32 code in qemu.
- Booted Lenovo X220 using x86_32 MRC using x86_64 console.
Change-Id: Ib625233e5f673eae9f3dcb2d03004c06bb07b149
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch ensures `chromeos_get_factory_config()` returns an
unsigned integer value because factory config represents
bit-fields to determine the Chromebook Plus branding.
Additionally, introduced safety measures to catch future
"factory_config" bit-field exhaustion.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: I3021b8646de4750b4c8e2a2981f42500894fa2d0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79769
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On ChromeOS devices with updateable CSE firmware, the GPR0 (Global
Protected Range) register is used to ensure the CSE RO is write
protected even when the FLMSTR-based protection is temporarily disabled
by coreboot to allow updating the CSE RW. For more details see
Documentation/soc/intel/cse_fw_update/cse_fw_update.md
Therefore to allow modifying the CSE firmware from the CPU, the
descriptor must have both the FLMSTR-based protection disabled (which
can be done using ifdtool --unlock), and GPR0 disabled.
Add an ifdtool option for disabling GPR0. For now I've added support for
all platforms for which I have the SPI programming guide. Support for
more platforms can be added in the future if needed.
BUG=b:270275115
TEST=Run `ifdtool -p adl -g image.bin -O image-unlocked.bin` on a locked
craask image, check the GPR0 field is set to 0.
Change-Id: Iee13ce0b702b3c7a443501cb4fc282580869d03a
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79788
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To verify the boot chain, we will need to extend the PCR with the
firmware version. And the server will be able to attest the firmware
version of devices.
The "firmware version" here is the RW firmware anti-rollback version,
determined by the ChromeOS's signing infra, and will be verified in
vb2api_fw_phase3, by comparing it with the version stored in the TPM.
This version will be increased when there is critical vulnerability
in the RW firmware.
According to [1], PCRs 8-15 usage is defined by Static OS. Therefore
PCR_FW_VER is chosen to be within that range. Ideally the existing
PCR_BOOT_MODE and PCR_HWID should also be allocated in the same range,
but unfortunately it's too late to fix them. Because PCRs 11 and 13
have been used for other purposes in ChromeOS, here PCR_FW_VER is set
to 10.
[1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_05_3feb20.pdf
BUG=b:248610274
TEST=Boot the device, and check the PCR 10
BRANCH=none
Signed-off-by: Yi Chou <yich@google.com>
Change-Id: I601ad31e8c893a8e9ae1a9cdd27193edce10ec61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79437
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In DDR3 DLL-Off mode is an optional feature advertised by SPD.
Honor the SPD and only use DLL-Off mode when all DIMMs on the
same channel indicate support for it.
The same is done on MRC.bin.
Tested on Lenovo X220: Still boots fine.
Change-Id: Ief4bfb9e045cad7ff9953f6fda248586ea951a52
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79758
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To avoid code duplication and to also bring the mainboards using the
Picasso SoC more in line with Cezanne and newer, factor out the SoC-
specific code from the mainboard's dsdt.asl files to the SoC's soc.asl.
TEST=Timeless builds result in identical images for Bilby, Mandolin, and
Zork/Morphius
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4ed3a3d3cb55c8b3b474c66a7c1700e24fe908e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This patch introduces the 512KB SI_EC FMAP region for storing the EC
firmware, a necessary addition to support EC chips without internal
flash memory.
As a testing platform, the MTLRVP Chrome SKU is utilized in conjunction
with the Microchip EC1723, and the changes are verified.
Cq-Depend: chrome-internal:6691498
Cq-Depend: chrome-internal:6741356
BUG=b:289783489
TEST=build "emerge-rex coreboot chromeos-bootimage" is successful.
changes are verified.
EC Log:
23-11-06 17:46:49.564 --- UART initialized after reboot ---
23-11-06 17:46:49.564 [Image: RO, mtlrvpp_m1723_v3.5.142816-ec:6596a3,
os:f660f7,cmsis:42cf18,picolibc:6669e4]
23-11-06 17:46:54.609 D: Power state: S5 --> S5S4
23-11-06 17:46:54.620 D: Power state: S5S4 --> S4
23-11-06 17:46:54.620 D: Power state: S4 --> S4S3
23-11-06 17:46:54.642 I: power state 10 = S3S0, in 0x0087
23-11-06 17:46:54.642 ec:~>: Power state: S3S0 --> S0
Change-Id: I788dbeaad05e5d6904fb2c7c681a0bf653dc7d84
Signed-off-by: Deepti Deshatty <deepti.deshatty@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79209
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the first argument specifying the number of arguments pushed
to the stack. Instead always push the 3 arguments to stack and use
the first one as function pointer to call while in protected mode.
While on it add more comments and simplify register restore code.
Tested:
- On qemu can call x86_32 function and pass argument and return
value.
- Booted Lenovo X220 in x86_64 mode using x86_32 MRC.
Change-Id: I30809453a1800ba3c0df60acd7eca778841c520f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79752
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Remove pointers in argument list passed to MRC to make sure the struct
has the same size on x86_64 as on x86_32.
- Add assembly wrapper to call the MRC with argument in EAX.
- Wrap calling MRC in protected_mode_call_2arg, which is a stub on x86_32
Tested: Boots on Lenovo X220 using MRC in x86_32 and x86_64 mode.
Change-Id: Id755e7381c5a94360e3511c53432d68b7687df67
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
1. Set PCIe related GPIOs to NC if fw_config use "WIFI_CNVI".
2. Set CNVi related GPIOs to NC if fw_config use "WIFI_PCIE".
3. Remove "ALC5650_NO_AMP_I2S" case in
fw_config_gpio_padbased_override(). bt_i2s_enable_pads should not
relevant to audio codec/amp, and it is already enabled in "WIFI_CNVI"
case.
BUG=b:312099281
TEST=Build and test on karis
Change-Id: Ib1a32f1a38ae33cf992b80a3408aa8e2fa3ddab0
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79765
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
They always require special care so that line breaks and variable names
are escaped properly. One loop can be removed entirely because install
accepts multiple files to install in a target directories, the other
loops were filled by find which can just call the commands on its own.
Change-Id: I9f9dddfe3f3ceceb6a0510d6dd862351e4b10210
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79523
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements an API which relies on the
chromeos_get_factory_config() function to retrieve the factory
config value.
This information is useful to determine whether a ChromeOS device
is branded as a Chromebook Plus based on specific bit flags:
- Bit 4 (0x10): Indicates whether the device chassis has the
"chromebook-plus" branding.
- Bits 3-0 (0x1): Must be 0x1 to signify compliance with
Chromebook Plus hardware specifications.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: Iebaed1c60e34af4cc36316f1f87a89df778b0857
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This code leverages the TPM vendor-specific function
tlcl_cr50_get_factory_config() to fetch the device's factory
configuration.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: I34f47c9a94972534cda656ef624ef12ed5ddeb06
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch enables retrieval of factory configuration data from
Google TPM devices (both Cr50 and Ti50).
This patch utilizes vendor-specific command
TPM2_CR50_SUB_CMD_GET_FACTORY_CONFIG (68).
The factory config space is a 64-bit, one-time programmable.
For the unprovisioned one, the read will be 0x0.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: Ifd0e850770152a03aa46d7f8bbb76f7520a59081
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79736
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add `VBOOT_X86_RSA_ACCELERATION' Kconfig option to enable SSE2
instruction set implementation of modulus exponentiation which is part
of the RSA signature verification process.
BUG=b:312709384
TEST=Able to use SSE2 accelerated implementation on rex0
Change-Id: Ib6e39eb9f592f36ad3dca76c8eaf2fe334704265
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79289
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c0cb4bfa:
2023-12-08 signer: sign_android_image.sh should die when image repacking fails
to commit id 7c3b60bb:
2023-10-13 firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
This brings in 3 new commits:
7c3b60bb firmware/2lib: Use SSE2 to speed-up Montgomery multiplication
8bb2f369 firmware: 2load_kernel: Set data_key allow_hwcrypto flag
2b183b58 vboot_reference: open drive rdonly when getting details
6ee22049 sign_official_build: switch from dgst to pkeyutl
da69cf46 Makefile: Add support for make 4.3
Also update the implementations of the vb2ex_hwcrypto_modexp() callback
to match the API changes made in vboot.
Change-Id: Ia6e535f4e49045e24ab005ccd7dcbbcf250f96ac
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The FSP boot mode showing in serial log is a magic number.
In order to let user understand its meaning directly, add
the strings to describe the modes.
TEST=build, boot the device and check the logs:
without this change, the log is like:
[SPEW ] bootmode is set to: 2
with this change:
[SPEW ] bootmode is set to: 2 (boot assuming no config change)
Change-Id: I49a409edcde7f6ccb95eafb0b250f86329817cba
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Since we have chipset devicetrees for all SoCs that include this code in
the build, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5dcd92399e2d3f304352f2170dd3ef8761e86541
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79672
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since we have chipset devicetrees for both SoCs supported by the
Stoneyridge code, we can use the DEV_PTR macro instead of using
pcidev_path_on_root to get the device struct pointer. We can also use
the is_dev_enabled function instead of checking the value of the enabled
element of the device struct directly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifb787750ebc6aa2fef9d3be0e84e6afcffdc2ac1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79671
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
