On 5/11/2022 2:54 PM, Michael Walle wrote: > Am 2022-05-11 12:28, schrieb Horia Geantă: > >>>>>> For non-E variants, it might happen that Blob protocol is enabled, >>>>>> but >>>>>> number of AES CHA are zero. >>>>>> If the output of below expression is > 0, then only blob_present >>>>>> should be marked present or true. >>>>>> For era > 10, you handled. But for era < 10, please add the below >>>>>> code. >>>>> >>>>> Are there any CAAMs which can be just enabled partially for era < >>>>> 10? >>>>> I didn't found anything. To me it looks like the non-export >>>>> controlled >>>>> CAAM is only available for era >= 10. For era < 10, the CAAM is >>>>> either >>>>> fully featured there or it is not available at all and thus the node >>>>> is removed in the bootloader (at least that is the case for >>>>> layerscape). >>>>> >>>> Qouting from our previous discussion in U-boot: >>>> https://patchwork.ozlabs.org/project/uboot/patch/20200602150904.1997-1-michael@xxxxxxxx/#2457448 >>>> >>>> " >>>> Based on previous (NXP-internal) discussions, non-E crypto module is: >>>> -fully disabled on: LS1021A (ARMv7), LS1043A, LS1088A, LS2088A >>>> (and their personalities) >>>> -partially [*] disabled on: LS1012A, LS1028A, LS1046A, LX2160A >>>> (and their personalities) >>>> " >>>> >>>> From the partially disabled list, LS1028A and LX2160A have CAAM Era >>>> 10, >>>> while LS1012A and LS1046A integrate CAAM Era 8. >>> >>> Thanks for clarification. Do you know it that is a layerscape feature? >>> I had a look at the imx8mn which have a era 9 and it doesn't have the >>> PKHA_VERSION register which indicates the partially disabled PKHA >>> block. Thus I concluded that there is no partially disabled feature >>> on era < 10. >>> >> Unfortunately when moving from Era 9 to Era 10, the register map >> is not 100% backwards-compatible. >> This is why you're not seeing PKHA_VERSION register for i.MX8MN. >> >> For Era >= 10, the CHA version and CHA number fields are conveniently >> found >> found in the same *_VERSION register, e.g. PKHA_VID and PKHA_NUM are >> both >> located in PKHA_VERSION. >> >> For Era < 10, these fields are scattered: >> CHAVID_LS[PKVID] >> CHANUM_LS[PKNUM] > > Ok, but there is only the number of instances. I couldn't find a > similar bit to the PKHA_VERSION[PKHA_MISC[7]] bit, which indicates > PKHA decryption/encryption capability is disabled. That seems to > be only for era >= 10, right? That was what caused my confusion, Yes, there's no corresponding information for PKHA_MISC on CAAM versions earlier than Era 10. Only starting with Era 10 PKHA can be _partially_ disabled on non-E CAAM. > because until now I was under the impression that non-E variants > will always have that bit. > > Rereading your comment, you don't mention PKHA at all. So for > era <10 if you blow the EXPORT_CONTROL fuse, you'll have zero > in any *NUM except for MDNUM, RNGNUM and CRCNUM. Is that correct? > Partially true. For some SoCs, CAAM does not support CRCA at all, irrespective of the state of the fuse. > In that case, I agree, we should also check CHANUM_LS[AESNUM] for > era < 10. > Btw, newer manuals have the subsection "SEC/ CAAM implementation" -> "SEC/CAAM Versions with Encryption Disabled" which details what happens in case encryption is disabled. Horia
