Trying CI after a dummy change#12
Open
ShashiPJain wants to merge 12 commits into
Open
Conversation
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>
Signed-off-by: ShashiPJain <sjain@qti.qualcomm.com>
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.
No description provided.