Hardware accelerated CRC16

[MVass.1]

Hi,

We wish to add CRC16 checksum to our communication payloads,

and I see in the stm32mp157 datasheet CRC module section that it should support CRC32,16,8 and 7 bits.

"""

25.4.3 CRC control register (CRC_CR)

Bits 4:3 POLYSIZE[1:0]: Polynomial size

These bits control the size of the polynomial.

00: 32 bit polynomial

01: 16 bit polynomial

10: 8 bit polynomial

11: 7 bit polynomial

"""

But I do not see this being utilized in the ST CRC driver ("stm32-crc32.c") - Linux 5.10

from a quick look at the ST CRC driver, I see only CRC32 support.

To be clear, CRC32 works, and I have already tested it with a userspace application using AF_ALG to request kernel support to calculate CRC32.

But we would like to use CRC16 instead.

1) Am I understanding it correctly that only CRC32 algorithm is supported by the ST drivers ? Or am I wrong ?

2) If I understood it correctly, and the ST driver does support only CRC32, does the actual HW support CRC16, or am I misunderstanding the datasheet, and the HW module supports CRC16 only as well ?

Thanks,

Michael

[OlivierK · Accepted solution]

Hi MVass.1 (Community Member)

You are indeed correct. So far the stm32-crc linux driver supports CRC32 only whereas it should support also 16,8.7 bits since h/w knows to do it.

The changes to support CRC16 would be quite easy to implement in the driver however it is not sure that the linux framework could pass it easy to userspace.

Regards,

Olivier

[Tesla DeLorean]

There are typically several polynomial, initialization, shift direction, and endian issues to get right with CRCs

On the MCU side these have frequently given people headaches.

Software table methods can also be relatively efficient, especially if you cost in overheads for driver calls.

[OlivierK]

Hi MVass.1 (Community Member)

What about the use of CRC16 in s/w ? What sort of performance are you looking for and for what purpose?

Rgds,

Olivier

[MVass.1]

Hi @OlivierK​ 

Thanks for confirming my understanding of the CRC driver

Yes, we will probably end up using s/w CRC16 which is also fine.

From my testing of HW CRC32 via AF_ALG interface to kernel, the device is able to calculate 161147 bytes of data each millisecond at 8KB buffer size

(22k bytes per ms at 256 byte chucks)

which is really good, and the MPUs promotional material mentioned CRC7,8,16,32 HW capabilities.

We are just a little sad we can't utilize it for our needs, that's all.

BTW,

from my testing, HW SHA256(AF_ALG) also out performs SW SHA256(wolfssl) at 512 byte chunks and above.

BUT, HW AES 256 CBC is not worth at any chunk size (half the speed), and causes the MPU's performance to drop by 32X while running --> we will use SW encryption due to this.

(I am seeing same issues as https://community.st.com/s/question/0D53W00001JUAMJSA5/issues-with-crypto-ip-core)

BR,

Michael

[Tesla DeLorean]

>>.. the MPUs promotional material mentioned CRC7,8,16,32 HW capabilities.

But this wouldn't be the first time ST puts features in the sell-sheets and slides, but fails to deliver actual working code and demonstrations of features they claim.