TDA4VM: MCRC

Hello Daniel,

The MCRC_PAS_SECSIGREGL1 represents the lower 32 bits, and the MCRC_PAS_SEC_SIGREG1H represents the upper 32 bits, of the 64-bit PSA Sector Signature register.

For example code, we suggest looking into the PDK code provided in the PSDK RTOS release for TDA4VM. see:

[1] <PSDK_RTOS_PATH>/pdk_jacinto7_<version>/packages/ti/csl/src/ip/crc/V0/priv/crc.c

CRC with UDMA:

[2]  <PSDK_RTOS_PATH>/pdk_jacinto7_<version>/packages/ti/drv/udma/examples/udma_crc_test/udma_crc_test.c

Thanks.

Hello Praveen,

sorry that I interfere in the conversation. I'm supporting Daniel with this driver development.

We took a look the examples but unfortunately it didn't help a lot. I'll try to reformulate the question.

The idea is to use MCRC module for integrity check of the software binaries loaded from flash to RAM during processor start-up. Therefore beside using MCRC module, we would need to pre-calculate CRC64 for the binary files on host machine to put it inside of the binaries. Integrity check will be done by R5F core in MCU domain (in SBL).

To implement this host checksum calculation we want to understand how CRC is being calculated by MCRC module and here we face some difficulties.

Let's suppose we want to calculate CRC for the following data 11 22 33 44 55 66 77 88. I suppose that correct checksum would be 0xA854FBAB02FE5C43 in this case:

But we cannot obtain the same with the CRC module.

When we try to write 0x1122334455667788 as 64-bit value to address of MCRC_PSA_SIGREGL1, it seems that it is assessed as two operations:

• Writing 0x55667788 to MCRC_PSA_SIGREGL1
• Writing 0x11223344 to MCRC_PSA_SIGREGH1

And together with the following information from the TRM:

MCRC module compresses in fact something like: 00000000 55667788 11223344 00000000

This can be confirmed by the following result:

The same result is provided by MCRC module:

Writing two times to MCRC_PSA_SIGREGL1 does not help as well, cause we get checksum for 0x00000000 11223344 00000000 55667788.

So here is the question: How to avoid this padding? What is the intended way to use both registers concurrently? 

Otherwise we would need to pre-calculate checksum taking into account this 'artificial' padding, which seems a bit strange.

Best regards,
Dmitry

Hello Dmitry,

Understand your concern. Based on your explanation, the query is directly on the functionality of the MCRC module and we would need to look for the module owner to respond, but unfortunately, we do not have one and there would be delays. We will have to check internally and re-assign this thread accordingly.

Thanks.

Thank you, Praveen.

Looking forward to getting more insight.

Hello Praveen,

any updates on the topic?

Hi Dmitry,

As discussed in the call today, Glad to know that you can identify the issue that R5 can only handle 32-bit when you directly access MCRC and have to access it via UDMA to get the 64-bit CRC working.

One note on my side was to share the patch for the CSL fix for MCRC handling for 64-bit and below are the details, but we are not sure if it would apply to your case.

Note that for 64-bit access, the crcSingnatureRegAddr_t structure in the crc.h file has 32-bit pointer address instead of 64-bit pointer address, hence when accessed from the A72 core, it was getting a bad address.

The CSL file that the patch was applied was to  <RTOS_SDK>/pdk/packages/ti/csl/src/ip/crc/V0/crc.h

0001-CRC-Fix-crcSignatureRegAddr_t-for-QNX-A72.patch

Thanks.