plat-qcom: Add BOBCAT architecture/IPQ Platforms support#13
Closed
zelvam95 wants to merge 14 commits into
Closed
Conversation
Contributor
Author
Add Command Database (CMD_DB) driver for Qualcomm platforms. CMD_DB provides resource address and priority lookup from a shared memory database populated by the Always-On Processor (AOP). This database contains mappings between resource identifiers (e.g., "mx.lvl" for MX voltage rail) and their hardware addresses, which are required by RPMH for power management operations. The driver supports: - Resource address queries by resource ID - Priority level queries for different driver IDs - Validation of database integrity (magic number, version) This is a prerequisite for RPMH client driver functionality. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add Resource Power Manager Hardened (RPMH) client driver for Qualcomm platforms. RPMH provides a communication interface to the Always-On Processor for power management operations. It uses Trigger Command Sets (TCS) to send resource state requests (e.g., voltage levels, clock states) to the AOP, which then programs the hardware accordingly. The driver implements: - Client handle management for Secure driver ID - Active set command submission (sleep/wake not needed for Secure DRV) - TCS hardware sequencing and completion barriers - Resource command tracking and caching - Hardware abstraction layer for register access This driver is essential for controlling voltage rails during QFPROM fuse provisioning, which requires precise voltage levels (0.95V on MX rail) to safely program one-time-programmable fuses. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add support for Qualcomm QFPROM (Fuse Programmable Read-Only Memory), a one-time programmable memory used for storing security credentials and device configuration. QFPROM stores critical security data including: - Root of trust public key hashes for secure boot - Hardware key derivation keys (primary and secondary) - Anti-rollback version counters - OEM configuration and feature flags - Device-specific encryption keys The driver provides: - Read operations from corrected (FEC) and raw address spaces - Write operations with hardware sequencing and timing control - FEC (Forward Error Correction) calculation for protected regions - Hardware mutex synchronization for multi-core safety - Voltage and clock control via RPMH for safe fuse programming - Region-based access control and permission checking Fuse programming requires precise timing (5µs hold time) and voltage (0.95V) to ensure reliable one-time programming without hardware damage. This implementation also introduces a generic clock rate setting API (qcom_clock_set_rate) that allows drivers like QFPROM to directly manage their clocks without going through the clock group abstraction. The QFPROM driver uses this API directly for its clock configuration needs. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add support for secure fuse provisioning using sec.elf V2 format. Fuse provisioning is performed once during device manufacturing to program security credentials and configuration that cannot be changed after provisioning. This includes: - Secure boot public key hashes - Hardware-backed encryption keys (SHK, OEM keys) - OEM configuration and feature enables - Access permission controls (read/write disable bits) The implementation: - Parses and validates sec.elf format with SHA256 verification - Supports multiple fuse regions (general, secure boot, OEM, etc.) - Handles special operations (random key generation for SHK) - Implements FEC encoding for error-protected regions - Provides OEM spare region provisioning with random data option Provisioning is triggered at boot time if sec.elf is present in DDR, allowing factory programming without requiring runtime APIs. Once complete, a device reset is required for fuses to take effect. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add Kodiak-specific QFPROM configuration with 31 fuse region definitions including base addresses, sizes, FEC settings, and permission masks. Regions include security keys, anti-rollback counters, OEM configuration, and calibration data. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add QFPROM driver support for Lemans platform with 37 fuse regions including security keys, anti-rollback counters, OEM configuration, and calibration data. Add Lemans-specific clock driver header with QFPROM clock register definitions (GCC_SEC_CTRL_CFG_RCGR, GCC_SEC_CTRL_CMD_RCGR). Move platform-specific fuse region enums from common header to target-specific headers to allow per-platform customization. Implement conditional MX voltage rail workaround using CFG_QFPROM_MX_RAIL_WA configuration flag. This workaround is required for Kodiak platform but not needed for Lemans. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Enable QFPROM Fuse Provisioning support for Kodiak platform along with its required dependencies (CMD_DB, RPMH_CLIENT, QFPROM drivers). The drivers are conditionally enabled based on CFG_QCOM_QFPROM_FUSEPROV, which defaults to 'y' for secure builds and 'n' for insecure builds. This ensures the fuse provisioning infrastructure is only included when needed, reducing the attack surface in production builds. Note: Actual fuse programming operations require CFG_QFPROM_PROGRAMMING to be explicitly enabled. This config is disabled by default as a safety measure and must be enabled during provisioning to allow write operations to the OTP fuses. Platform configuration additions: - AOP MSG RAM base and size for CMD_DB metadata - RPMH RSC base address for power management - Security Control base for QFPROM access - TCSR Hardware Mutex for synchronization - Secure ELF DDR region for fuse provisioning data Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Enable QFPROM Fuse Provisioning support for Lemans platform with required driver dependencies (CMD_DB, RPMH, QFPROM, CLK). Move common platform definitions to shared section and organize platform-specific definitions (GCC_BASE) into respective platform sections. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Implement a diagnostic ring buffer driver that preserves crash logs in IMEM across reboots for post-mortem analysis. The driver provides a write-only circular buffer that captures console output during normal operation and crash scenarios. Key features: - Write-only circular buffer in IMEM for crash log preservation - DLOAD mode detection to disable logging during download mode - Automatic buffer wraparound with overflow tracking Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Integrate the diagnostic ring buffer driver into the platform: - Add IMEM memory region definitions (platform_config.h) * Kodiak: 0x14680000, size 0x19000 * Lemans: 0x14680000, size 0x32000 - Enable CFG_QCOM_DIAG_LOG in debug builds (conf.mk) * Automatically enabled when CFG_TEE_CORE_DEBUG=y - Hook into trace infrastructure * Initialize DIAG during plat_trace_init() * Mirror console output via plat_trace_ext_puts() This enables crash log preservation for debugging production issues when debug builds are deployed. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Introduce an architecture-centric structure for Qualcomm platform configuration to improve scalability and maintainability. Chipsets are now grouped by architecture family (e.g., Kodiak and Lemans under HOYA). Configuration is split into three levels: 1. Platform-wide (conf.mk): Maps chipsets to architecture families 2. Architecture-level (hoya/arch.mk, hoya/arch_config.h): Base platform requirements common across all chipsets in the family (CPU, cores, TZDRAM, RAMBLUR, PRNG) 3. Chipset-specific (hoya/kodiak/target.mk, hoya/lemans/target.mk): Advanced features like clock drivers, diagnostic logging, and fuse provisioning The conf.mk uses variable-based includes to automatically load the correct architecture and chipset configurations, eliminating conditional logic from architecture files. This structure allows new chipsets to start with minimal base platform support and incrementally add advanced features. It also simplifies adding new architecture families in the future. No functional changes - pure refactoring with identical configuration values and hardware addresses. Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Member
|
Please rebase this series as qcom-next has been rebased to pick fixes merged upstream. |
zelvam95
force-pushed
the
feature/ipq-base-platform-support
branch
from
a6a04e7 to
f7a9033
Compare
Contributor
Author
Contributor
Author
|
Changes for upstreaming TF-A also be pushed sometime soon. Until then, if anyone is interested, they can pick the TF-A changes from below CLO branch. CodeLinaro / trusted-firmware / tf-a / trusted-firmware-a · GitLab |
zelvam95
force-pushed
the
feature/ipq-base-platform-support
branch
from
1dec6e4 to
efdf8df
Compare
Contributor
Author
zelvam95
force-pushed
the
feature/ipq-base-platform-support
branch
from
efdf8df to
ea8eb95
Compare
zelvam95
changed the title
Member
Sorry for the delay as I have been travelling for the conference. I would rather suggest you push this patch-set alongside the re-org patch you are already pushing upstream here: OP-TEE/optee_os#7826. Actually, this patch-set will give answer the "why" part for the re-org. Also, we will be able to do a collective review in upstream. |
Contributor
Author
No issues, Thanks Sumit. I have included this series to the upstream PR for refactoring as suggested One doubt though - For qcom-next -> Can we merge this change as it is & do further reviews in upstream? Or shall we wait for PR to be merged upstream and then rebase this PR based on what's merged upstream and include "DIAG LOG/additional stuffs" as required in qcom-next? How shall we plan for this? |
zelvam95
force-pushed
the
feature/ipq-base-platform-support
branch
from
ea8eb95 to
def377e
Compare
Introduce support for the BOBCAT chipset family, starting with the IPQ96xx platform. This extends the architecture-based hierarchy previously established for HOYA to accommodate the new family. BOBCAT Architecture Framework: The conf.mk is updated to detect BOBCAT chipsets alongside HOYA and load the appropriate architecture and chipset configurations using the same variable-based include mechanism. Architecture-level configuration common to all BOBCAT chipsets is placed in bobcat/arch_config.h, while per-chipset differences are captured in chipset-specific target.mk and target_config.h files. IPQ96xx Platform Configuration: IPQ96xx is a 5-core SoC (4x Cortex-A55 + 1x Cortex-A78) with the following configuration: - 5 CPU cores with GICv3 interrupt controller - TZDRAM at 0x8A680000 (2.5MB) - Dual DRAM regions (2GB + 14GB) - GENI UART at 0x01A98000 - IMEM at 0x8600000 (128KB) - DIAG logging support (debug builds only) DIAG Logging Migration: As part of this change, DIAG logging configuration macros are moved from the common diag_log.h to architecture-specific arch_config.h files. This enables each chipset family to define their own DIAG memory layout and register addresses: - HOYA: IMEM_DIAG_OFFSET=0x720, DIAG_SIZE=0x3000 - BOBCAT: IMEM_DIAG_OFFSET=0x730, DIAG_SIZE=0x6000 Signed-off-by: Harikrishna <hart@qti.qualcomm.com> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Certain Qualcomm SoCs seems to have a custom implementation of the GICv2 specification. It's mostly compliant but unfortunately it looks like a mistake was made with the GICD_PIDR registers. PIDR2 is defined to be at offset 0xFE8, but the Qualcomm implementation has it at 0xFD8. It looks like the entire PIDR0-3/4-7 block is swapped compared to the ARM implementation: PIDR0 starts at 0xFD0 (instead of 0xFE0) and PIDR4 starts at 0xFE0 (instead of 0xFD0). Allow overriding it in platform headers as workaround. Similar change is already available in TF-A for reference: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/12889 Signed-off-by: Harikrishna <hart@qti.qualcomm.com> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
Add IPQ52xx chipset support to the BOBCAT architecture family. IPQ52xx is a 4-core Cortex-A53 SoC using GICv2 for interrupt control, unlike other BOBCAT chipsets which use GICv3. The platform configuration includes: - 4 CPU cores (Cortex-A53) with GICv2 interrupt controller - TZDRAM at 0x87D80000 (2.5MB) - Dual DRAM regions (2GB + 2GB) - GENI UART at 0x01A84000 - IMEM at 0x8600000 (96KB) - DIAG logging support (debug builds only) - GICv2 support added to main.c with conditional compilation This commit extends the platform initialization code to support both GICv2 and GICv3 interrupt controllers based on the CFG_ARM_GICV3 configuration flag, enabling compatibility across the BOBCAT chipset family. Signed-off-by: Harikrishna <hart@qti.qualcomm.com> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka@qti.qualcomm.com>
zelvam95
force-pushed
the
feature/ipq-base-platform-support
branch
from
def377e to
c2c2ee4
Compare
Member
|
@zelvam95 please rebase this PR to qcom-next as it is recently rebased to tip of upstream.
Please post the DIAG buffer support upstream as well.
Let me give your BOBCAT patch-set in upstream a review today. Hopefully you will be able to carry any changes in this PR too. |
Contributor
Author
OP-TEE/optee_os#7839 -> Thanks Sumit, The upstream refactor + bobcat change is merged & I have posted the DIAG Log for review upstream now. |
Member
|
This PR can be closed now as the BOBCAT support landed upstream and qcom-next has been rebased to include that support. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR introduces support for the BOBCAT chipset family, extending the architecture-based hierarchy previously established for HOYA. The series adds 2 platform variants: IPQ96xx, and IPQ52xx.
Architecture Framework
The BOBCAT architecture framework follows the same organizational pattern as HOYA:
bobcat/arch_config.hbobcat/<chipset>/target.mkandtarget_config.hconf.mkPlatform Support
IPQ96xx
IPQ52xx
Key Changes
DIAG Logging Migration: Moved DIAG configuration macros from common
diag_log.hto architecture-specificarch_config.hfiles, enabling per-family customization:GIC Support: Extended platform initialization to support both GICv2 (IPQ52xx) and GICv3 (IPQ96xx) based on
CFG_ARM_GICV3flag.License: All new files use BSD-2-Clause license for upstream compatibility.
Testing