AM263P4: Issues related to the function implementations in `Hsmclient.c` for AM263P4

Part Number: AM263P4

I am currently writing a function for the R5 core (HsmClient) on the AM263P4 to issue service requests to the M4 core (HsmServer), following the `HsmClient_getRandomNum` function in the SDK. I have the following questions:**

Question 1:
After receiving the `RespMsg.args` returned from the HSM core, aside from performing cache coherence operations on the entire `getRandomNum` structure (i.e., `RespMsg.args`), is it necessary to perform cache coherence operations on all pointer variables within `args`? To be more specific: should I only perform coherence operations on the `resultPtr` (which holds the RNG output that this function is supposed to output) and not on `seedValue`?

image.png

Question 2:
When sending the SIPC message to the HSM core, aside from performing cache coherence operations on the entire `ReqMsg.args` (i.e., `getRandomNum`), do I also need to perform cache coherence operations on the pointer variables that are input to the HSM core, such as `resultPtr` and `seedValue`? If that's the case, is there an error in the following code 

image.png

  • Hi,

    Question 1:
    After receiving the `RespMsg.args` returned from the HSM core, aside from performing cache coherence operations on the entire `getRandomNum` structure (i.e., `RespMsg.args`), is it necessary to perform cache coherence operations on all pointer variables within `args`? To be more specific: should I only perform coherence operations on the `resultPtr` (which holds the RNG output that this function is supposed to output) and not on `seedValue`?

    This depends if you are using the seedValue again in the next iteration. The first cache invalidate is done for only the main struct. The subsequent pointers inside this main struct needs to invalidated/writeback based on the data being updated on the same and the usage of the same in the core.

    When sending the SIPC message to the HSM core, aside from performing cache coherence operations on the entire `ReqMsg.args` (i.e., `getRandomNum`), do I also need to perform cache coherence operations on the pointer variables that are input to the HSM core, such as `resultPtr` and `seedValue`? If that's the case, is there an error in the following code 

    I do not see the resultptr being used in HSM, thats why this was not invalidated here.

    Thanks and Regards,

    Nikhil Dasan

  • **Question 1:**
    Is it correct to summarize that, on the Cache RAM, when the master core sends data to the HSM core via SIPC, consistency operations must be performed on the necessary input pointer variables—where "necessary input" refers to the pointer variables that the HSM core needs for processing—to ensure that the data intended to be transmitted to the HSM core is consistent with what the HSM core actually receives? Similarly, after the HSM core finishes processing and sends data back to the master core via SIPC, consistency operations must be performed on the necessary output pointer variables, where "necessary output pointer variables" refer to the data that our master core will subsequently need.

    **Question 2:**
    Regarding `HsmClient_getRandomNum`, since the HSM core uses both the `seedValue` and `resultPtr` pointer variables, consistency operations are needed on the inputs. So, is there an issue with your answer 2?

    **Question 3:**
    For the `HsmClient_getRandomNum` function, in our current practice I only need the output `resultPtr`, which is where the RNG is stored. The `seedValue` will be refilled on the next request, so theoretically, is there no need to perform consistency operations on `seedValue`? Of course, I understand that performing consistency operations on pointer variables would not matter either way, right?

    **Question 4:**
    Regarding many functions in `hsmclient.c`, such as `HsmClient_getUID`, `HsmClient_readOTPRow`, etc., although consistency operations are performed on pointer variables before they are sent to the HSM core, no consistency operations are performed on the pointer variables after receiving data from the HSM core.Is there any consideration for this? Because I see that these pointer variables are also used in the HSM core processing function

    Hope to recover as soon as possible, thank you!!