AM2632: Keywriter integration issue.

Hi Tristan,

From your logs, it looks like the hsmrt is loaded correctly from the OTP-KW version logs, but it looks like the certificate is not passed correctly. 

In the TI provided SBL project, the certificate is passed as gCustKeyCert, and is filled in a struct called certHeader, which is passed to the HSM side with the API HsmClient_keyWriter().

Could you please confirm at your end if you are passing a valid certificate at this stage?

Thanks and Regards,

Nikhil Dasan

Hi Nikhil,

Thanks for your response. I agree with your opinion that it looks like the certificate is not passed correctly. And I rechecked the code of passing key certificate at my end. It's quite the same with sbl_keywritter demo project. The only difference is that gCustKeyCert in sbl_keywritter demo project is placed in .rodata.custKeyCert section, while gCustKeyCert in my code is just defined to aligned(CacheP_CACHELINE_ALIGNMENT), not particularly placed in certain section. The return value of HsmClient_keyWriter() interface is SystemP_SUCCESS. 

The certificate in my project is the same with the one used in sbl_keywritter demo project (which already tested to be valid in above log), it's not likely an invalid certificate passed.

I wonder why the certificate not passed correctly, below is my code.

Is there any potential issue not recognized in the code? Looking forward to your reply.

Best regards,

Tristan

Hi Nikhil,

I try to define gCustKeyCert in .rodata.custKeyCert section as sbl_keywritter demo project did, and hsmrt response as expected. It turns out there is restriction for gCustKeyCert variable storage/loading addr.

When I checked the linker file, The gCustKeyCert is placed .rodata.custKeyCert which is in L2 OCRam location named as HSM_RT and in the MPU configuration, this region is cached

In your case, could you check where is the certificate placed in your case?

Can you check if the certificate is placed in TCMA or TCMB region of R5 which is not accessible by HSM?

Thanks and Regards,

Nikhil Dasan

The certificate is placed in OCRAM and the region is config the same with yours.

If I create section .rodata.custKeyCert and configuration as below(same with sbl_keywriter demo project). It seems hsmrt gets the key certificate successfully and the printed log is the same with  sbl_keywriter demo project.

If I change the Load Memory of section .rodata.custKeyCert as below. It seems hsmrt couldn't get the key certificate correctly, and nothing output.

In both configuration, I check the map file after compiling. The address of gCustKeyCert is in OCRAM, not in TCMA or TCMB.

And I cannot find any settings in the section related to hsm access permission.

Is there any way to find out the exact restriction for memory address of gCustKeyCert ?

Hi,

I tried this at my end, i.e. the only change I did in the standard OTP KW is that I changed the section of .rodata.custKeyCert from MSRAM_HSMRT to MSRAM_0, 

I ran the above change in DRY_RUN MODE and was able to get the Keywriter based logs similar to the standard KW flow.

Could you compare the standard offering with your changes and check if there are any other changes at your end?

Note: OTP KW is a one-time process, so I would suggest you go with the standard offering.

Thanks and Regards,

Nikhil Dasan

Hi,

I tried the same change in sbl_keywriter demo project and ran on AM263X Launch Board. While the result is different from yours.

Before modify, the log is as expected.

Modify the Load Memory of section rodata.custKeyCert

And the log is below, the same with the original issue.

It's confusing that the result is different and is it possible for you to check the source code of keywriter hsmrt？

Best regards,

Tristan

Hi Tristan,

I had tried it on the AM263x-CC board. Let me try the same on the LP board and get back to you by Monday.

Thanks and Regards,

Nikhil Dasan