It was ok up to Linux 6.18.2_1.0.0 to compile CAAM driver in CONFIG =y mode. With more recent Linux 6.18.20_2.0.0 and Linux 6.18.37_2.1.0 this leads to kernel build-in certificates errors.
I tried changing CAAM settings like CRYPTO_DEV_FSL_CAAM_PKC, secure, trusted keys on/off, which should make certificates part independent of CAAM, but sill certificates are broken until I turn CAAM driver to =m mode.
Is it possible to use CAAM driver as =y? I'm using i.MX7. Thanks
Please disable "CONFIG_TRUSTED_KEYS_CAAM" to configure it as "n" to check whether this problem exists.
In SDK default build configuration, I found the following.
# CONFIG_TRUSTED_KEYS_CAAM is not set
Perhaps it wasn't working already with 6.18.2, I'm not sure. I'm sure it worked with 6.12.x.
With enabled CAAM_DEBUG and
zcat /proc/config.gz | grep CAAM
# CONFIG_CRYPTO_DEV_FSL_CAAM_DMA is not set
CONFIG_TRUSTED_KEYS_CAAM=y
CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON=y
CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC=y
CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API_DESC=y
CONFIG_CRYPTO_DEV_FSL_CAAM_KEYBLOB_API_DESC=y
CONFIG_CRYPTO_DEV_FSL_CAAM_SECVIO=y
CONFIG_CRYPTO_DEV_FSL_CAAM=y
CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG=y
CONFIG_CRYPTO_DEV_FSL_CAAM_JR=y
CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9
# CONFIG_CRYPTO_DEV_FSL_CAAM_INTC is not set
CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_PRNG_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN=y
CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API=y
# CONFIG_CRYPTO_DEV_FSL_CAAM_TK_API_TEST is not set
# CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_TEST is not set
CONFIG_CRYPTO_DEV_FSL_CAAM_SM=y
CONFIG_CRYPTO_DEV_FSL_CAAM_SM_SLOTSIZE=7
CONFIG_CRYPTO_DEV_FSL_CAAM_SM_TEST=m
I get this in dmesg
[ 0.600724] caam 30900000.crypto: entropy-delay property missing in DT
[ 0.600757] caam 30900000.crypto: device ID = 0x0a16030000000000 (Era 8)
[ 0.600776] caam 30900000.crypto: job rings = 3, qi = 0
[ 0.609580] sdhci-esdhc-imx 30b40000.mmc: Got CD GPIO
[ 0.614915] caam algorithms registered in /proc/crypto
[ 0.615107] caam 30900000.crypto: caam pkc algorithms registered in /proc/crypto
[ 0.615138] caam 30900000.crypto: rng crypto API alg registered prng-caam
[ 0.615157] caam 30900000.crypto: registering rng-caam
[ 0.615184] 01: operation
[ 0.615198] 02: fifo_store
[ 0.615217] rng job desc@: (ptrval): b0800004 82500002 60340010 81cf2500 ......P...4`.%..
[ 0.615405] 01: operation
[ 0.615423] 02: fifo_store
[ 0.615440] rng job desc@: (ptrval): b0800004 82500002 60340010 8126fac0 ......P...4`..&.
[ 0.616325] Device caam-keygen registered
[ 0.620411] caam-snvs 30370000.caam-snvs: ipid matched - 0x3e
[ 0.620477] caam-snvs 30370000.caam-snvs: violation handlers armed - non-secure state
[ 0.621041] hid: raw HID events driver (C) Jiri Kosina
[ 0.621217] usbcore: registered new interface driver usbhid
[ 0.621230] usbhid: USB HID core driver
[ 0.624128] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 (8000000f) counters available
[ 0.627983] NET: Registered PF_INET6 protocol family
[ 0.629380] Segment Routing with IPv6
[ 0.629471] In-situ OAM (IOAM) with IPv6
[ 0.629630] NET: Registered PF_PACKET protocol family
[ 0.629705] Bridge firewalling registered
[ 0.629717] can: controller area network core
[ 0.629795] NET: Registered PF_CAN protocol family
[ 0.629810] can: raw protocol
[ 0.630378] Key type dns_resolver registered
[ 0.637395] imx-cpufreq-dt imx-cpufreq-dt: cpu speed grade 2 mkt segment 1 supported-hw 0x4 0x2
[ 0.638671] Registering SWP/SWPB emulation handler
[ 0.649825] Loading compiled-in X.509 certificates
[ 0.650591] 07: operation
[ 0.651164] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using ADMA
[ 0.674771] 01: operation
[ 0.674791] 02: fifo_store
[ 0.674811] rng job desc@: (ptrval): b0800004 82500002 60340010 8126fac0 ......P...4`..&.
[ 0.679492] Problem loading in-kernel X.509 certificate (-22)Yes, CAAM can in principle be =y on i.MX7. I would treat the =m workaround as evidence of a dependency/build regression, not as an i.MX7 CAAM requirement.
If you paste the exact first certificate error from the LF6.18.20_2.0.0 build, I can trace which Kconfig/Makefile dependency is causing it and determine whether there is a specific NXP/upstream patch that needs to be backported.