Before 'handle_psp_command' calls any of the functions in this file, it
make sure that the 'size' field in the command buffer's header doesn't
indicate that the command buffer is larger than the SMM memory region
reserved for it.
The read/write command buffer has a 'num_bytes' field to indicate how
many bytes should be read from the SPI flash and put into the data
buffer within the command buffer or how many bytes from this buffer
should be written to the flash. While we should be able to assume that
the PSP won't send us malformed command buffer, we should still better
check this just to be sure.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib4e8514eedc3ad154a705c8a1e85d367e452dbed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83778
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use coreboot's SPI flash access infrastructure to do the flash read,
write, or erase operations as requested from the PSP.
This patch is a modified version of parts of CB:65523.
Document #55758 Rev. 2.04 was used as a reference.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I4957a6d316015cc7037acf52facb6cc69188d446
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Detect the block size of the SPI flash and number of flash blocks
reserved for the flash region corresponding to the 'target_nv_id' field
in the command buffer. This information is then written to the
corresponding fields in the command buffer. Since detecting the flash
chip still might result in accesses to it, make sure that it's available
for use and not currently used by an OS driver. Since this code is
inside the SMI handler, we don't have to worry about this code to be
interrupted, so we don't need to set some bit to tell other code that
we're currently using the SPI controller in the SMI handler.
This patch is a modified version of parts of CB:65523.
Document #55758 Rev. 2.04 was used as a reference.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I19041a27a9e8f901d42c3f60af834df625455ea6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83776
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SPI_SEMAPHORE_DRIVER_LOCKED bit in the SPI_MISC_CNTRL register
doesn't affect the hardware, but it re-used by AMD as a semaphore to
synchronize the access to the SPI controller between SMM and non-SMM
software like an OS-level driver. Since it doesn't affect the hardware,
it's marked as reserved in the PPRs. Add the 'spi_controller_available'
helper function to check this bit to see if some software or driver
outside of SMM is currently using the SPI flash controller to avoid
interfering with that operation.
This patch is a slightly reworked version of parts of CB:65523.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I49218e03a5dd555b2b2d34eaad86673e9fc908c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83775
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add 'find_psp_spi_flash_device_region' to get a pointer to the spi_flash
struct of the SPI flash used in the system and the region_device struct
for the target FMAP region specified by the target NV ID from the PSP
to x86 mailbox command. In order to have small patches, the newly added
static 'find_psp_spi_flash_device_region' function is marked as inline;
that inline will be removed in a following patch that calls this new
function.
This patch is a slightly reworked version of parts of CB:65523.
Document #55758 Rev. 2.04 was used as a reference.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I64b8fba2392de46ecd4c786cef0d5b6acdbd865a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83774
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add and use functions to validate the target non-volatile storage ID in
the different command buffer structs.
This patch is a slightly reworked version of parts of CB:65523.
Document #55758 Rev. 2.04 was used as a reference.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: Idda0166c862d41d380b2ed21345eead5e0a1c135
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83758
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the PSP wants to access the SPI flash during runtime, but isn't the
owner of the SPI flash controller, it sends an SMI to the x86 side. The
corresponding SMI handler then checks the P2C (PSP to core) mailbox for
the command and data, processes the command, and if needed puts the
requested data into the P2C buffer.
The P2C mailbox is a memory region in TSEG aka SMM memory. Both location
and size are communicated to the PSP via the PSP SMM info mailbox
command which is sent right after mpinit is done.
This commit adds the code to access the P2C mailbox to the PSP SMI
handler code, but the handling of the actual mailbox commands the PSP
sends to the SMI handler is added in later patches to keep the patch
size manageable.
This patch is a heavily reworked version of parts of CB:65523.
Document #55758 Rev. 2.04 was used as a reference.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I50479bed2332addae652026c6818460eeb6403af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83740
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Adjust Touchpad I2C fall time configuration such that it meets the
I2C fast mode specification(<= 400KHz).
BUG=b:328670295
TEST=Build Brox firmware and boot to OS. Confirm the I2C bus
frequency(375 KHz), rise(650 ns) and fall(330 ns) times meet the
specification.
Change-Id: I0006bfb9bb5839ffa1248d9f2ea055160ed0936e
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83755
Reviewed-by: Bob Moragues <moragues@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Clean up the devicetree by removing settings set to 0, which are
initialized with 0 anyway, remove superfluous disabled devices and also
remove comments duplicating the device alias names.
Change-Id: I07005ae1db7d92fd50e72351031a5eb491768d3e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83782
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that multiple TPM drivers may be compiled in, it is possible to
support switching between fTPM and dTPM.
The patch adds:
- Device tree entry for PC80 discrete TPM
- TPM PIRQ# GPIO active low routed to IOAPIC for TPM interrupt
- MEMORY_MAPPED_TPM option to board's Kconfig to enable PC80 TPM driver
When the ME is disabled, e.g. via HECI command, chipset will route the
TPM traffic to SPI automatically. When a SPI TPM is connected to the
JTPM1 on the board, it will be probed successfully and initialized
in place of inactive PTT/fTPM.
Change-Id: Ie6e7026b6f1cec842bce4ef40b6db7feb75200e3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80456
Reviewed-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When both CRB and pc80 TPM drivers are compiled in, building fails
because the tpm_config_t typedef has two incompatible definitions.
Given that typedefs are discouraged by the project's coding style,
simply get rid of the tpm_config_t typedef.
TEST=Compile MSI PRO Z690-A target with CRB and PC80 TPM chips enabled
in devicetree.
Change-Id: Id41717e265362303a17745303a907c9c8f4f4e12
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82057
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Clock Power Management, ASPM and L1 Substates have been
configured the same way since Skylake. The main control to
enable or disable is Kconfig, and then the level can be overridden
in devicetree.
Despite the UPDs remaining the same since Skylake, this is not the
case for Alder Lake, Raptor Lake and Meteor Lake.
Taking `starlabs/starbook` as an example, at the time of this
commit it has PCIEXP_CLK_PM, PCIEXP_ASPM and PCIEXP_L1_SUB_STATE
enabled.
On Comet Lake, this results in the correct configuration, verified
with the lspci command:
```
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit Latency L1 <8us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
```
On Raptor Lake:
```
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
```
Clock Power Management, ASPM and L1 Substates are also not configured
for CPU root ports.
Add helper functions to configure these correctly based on Kconfig, but
retain the capability to override the specific levels from devicetree.
Change-Id: I9db18859f9a04ad4b7c0c3f7992b09e0f9484a81
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81638
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add pad_own_reg_0 to `struct pad_community`. Pad ownership indicates
whether the GPIO is owned by host or Intel Management Engine. If owned
by host, then host ownership indicates whether the GPIO is owned by ACPI
or driver.
Change-Id: I30a934fd00a7a42cb156341da1954e4e4b1231d8
Signed-off-by: Yuchi Chen <yuchi.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83315
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Depending on how firmware image was passed to QEMU, it may behave as:
- ROM - memory mapped reads, writes are ignored (FW image mounted with
'-bios');
- RAM - memory mapped reads and writes (FW image mounted with e.g.
'-device loader');
- flash - memory mapped reads, write and erase possible through
commands. Contrary to physical flash devices erase is not required
before writing, but it also doesn't hurt. Flash may be split into
read-only and read-write parts, like OVMF_CODE.fd and OVMF_VARS.fd.
Combined size of system firmware must not exceed 8 MiB by default
(FW image(s) mounted with '-drive if=pflash').
This function detects which of the above applies and fills
region_device_ops accordingly.
Tested by starting QEMU with firmware passed as '-drive if=pflash',
'-drive if=pflash,readonly=on' and '-bios'. When started with firmware
passed through '-device loader', coreboot complains about corrupted
FMAP, but this is the same behavior as without this change:
[ERROR] Invalid FMAP at 0x40000
[EMERG] Cannot locate primary CBFS
Writable pflash support was added about 17 years ago, so it should be
supported by all QEMU versions currently in use. Since QEMU 5.0.0 it is
possible to change the limit of firmware size with `max-fw-size` machine
configuration option, up to 16 MiB, as bigger sizes would overlap with
default IO APIC memory range.
Change-Id: I3ab9f22c6165064a769881d4be5eab13a0a2f519
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82555
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Match PCIe root port allocation and associated comments to
boardview, as follows:
Z77 PCIe ports 1-4: PCIEX16_3 (x4)
Z77 PCIe port 5: PCIEX1_1
Z77 PCIe port 6: RTL8111F LAN
Z77 PCIe port 7: ASM1042 USB3
Z77 PCIe port 8: ASM1061 eSATA
CPU PCIe lanes 1-8: PCIEX16_1
CPU PCIe lanes 9-16: Multiplexed via 4x ASM1480 to PCIEX16_1 lanes 9-16
and PCIEX16_2 lanes 1-8
(CPU PCIe lanes are not covered by overridetree.cb.)
These are not hardware tested.
Change-Id: I472e28add254ea945b401d1ddfd03f29f46d8fd2
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The PSP can send SMIs to the x86 side to have the SMI handler service
requests from the PSP. This commit adds an empty PSP SMI handler; the
actual implementation is added in later patches to keep the patches
relatively small.
This patch is a slightly modified version of parts of CB:65523.
Test=When selecting SOC_AMD_COMMON_BLOCK_PSP_SMI, Mandolin still builds
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Change-Id: I65989ff529d728cd9d2cd60b384295417bef77ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83739
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Sandy/Ivy Bridge boards, this results in northbridge devices ending
up north of (above) southbridge devices. Which is the convention pretty
much all boards in the tree uses.
Change-Id: I9dc2ff13182ff9d92141b1736796749cea49d23a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Running autoport as root has the annoying side effect of making all
generated files owned by root. Prevent this by using sudo to invoke
log-making programs (lspci, dmidecode, acpidump, inteltool, ectool,
superiotool). These programs either need to be run as root or allow
collecting more information if run as root (lspci).
In case there's a valid reason not to use sudo, provide a prompt to
let autoport run the programs directly, as it originally did. There
might be someone trying to run autoport from an OS that lacks sudo.
Change-Id: I4bf4ddf8dd2cb930e9b7303e2ea986d8c072aa7a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The original approach to call external programs was rather convoluted
and would fall back to running executables inside the current working
directory if running them from the location specified in the code did
not succeed, swallowing any errors from the first invocation.
Rewrite the system around the `LogMakingProgram` concept, a struct to
represent a program. Each program has a name, prefixes to try running
it from and the arguments to pass to it (if any). Plus, collect error
information from failed executions, but only show it when none of the
prefixes resulted in a successful invocation.
In addition, look for programs in PATH instead of CWD: it is unlikely
that all utils will be in the CWD, but utils can be in the PATH after
one installs them (`sudo make install`). For coreboot utils, look for
them in the utils folder first as the installed versions might not be
up-to-date.
Furthermore, print out the command about to be executed, as there are
some commands (e.g. `ectool` on boards without an EC) that can take a
very long time to complete.
Change-Id: I144bdf609e0aebd8f6ddebc0eb1216bedebfa313
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82403
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently resource allocation starts top down from the default value
0xfe000000. This does not match what ACPI reports, so adapt
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT to reflect that.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I2ba0e96a7ab18d65b7fbbb38b1a979ea2ec6d1be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix potential undefined behaviour in the `get_pkg_power()` function:
- If `rapl_power_unit == 0`, `pkg_power_info / rapl_power_unit` is
invalid
- If `rapl_power_unit > 7`, the result of the shift doesn't fit into a
`uint8_t`
Signed-off-by: Mate Kukri <km@mkukri.xyz>
Change-Id: I48ef59c4fbeb0a55675ac24da31e6e0b194cb58d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83736
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
UART0 is already configured in coreboot, so this change sets SerialIo
config for UART0 to PchSerialIoSkipInit to skip initialization in FSP.
BUG=none
TEST=Able to build and boot google/rex0. Able to see all debug prints
over CPU uart.
Change-Id: I37744f05083eb82ba8ca579b628b69aa976e3d1f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83750
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
