MCF5271 SKHA and MDHA endian

[matthewc]

Hello,

I am currently trying to setup the 5271 SKHA to do AES encryption/decryption and the MDHA to do SHA-1 hashing. But I am not getting the correct data out.

I saw a related post about the SKHA that says it is expecting little endian data, Coldfire SEC and SKHA Benchmarks, does anyone have more info about this, or know where to find more detailed info? Is it the input/output FIFOs that are expecting the reversed endian, or is it also the IV and Key?

Thanks.

[TomE · Accepted solution]

I wrote that other post. Asking the programmer who got it working, everything needs to be byte-reversed, keys and all FIFO data..

It looks like the SKHA was a piece of IP that was designed to be little-endian (possibly for matching CPUs) and it was dropped into the big-endian Coldfire without any consideration being given to the problems that causes. Or even mentioning this anywhere in the documentation.

Chapter 30 in the MCF5235 manual looks to be almost identical to Chapter 28 in the MCF5271 manual. The only difference is that the MCF5235 chapter warns that the MCF5232-4 don't have the SKHA. So they're the same hardware.

Searching Freescale for "SKHA" doesn't find any little-endian chips with an "SKHA" in them. Searching for "Encryption" finds this training course:

Training Information Page

The above includes the text:

In order to help increase performance some new features have been added to the HAs.

These changes are available starting with the MCF532x and MCF537x family

devices. The updated modules are programmable for big or little endian modes,

where the original HA implementations only supported little endian data.

Programmable DMA request capability has also been added to the SKHA

and MDHA blocks.

It also refers to the SKHA (in the MCF54xx chips) in the Performance Graph as "Talitos".

Searching for that finds ONE mention of that name in the "MPC185 Security Co-Processor User's Manual". So it looks like the SKHA design might have come from the MPC line. The word "Talitos" also finds other MPC and DSP core documents.

Reading through THAT manual:

NOTE

The execution units used in the MPC185 are identical to those used in previous

security processors, and are natively little endian. Register values are shown in

a big endian format to assist in debug in a 60x (big endian) environment. Much

of the following detail is required only for debug and operation of the MPC185

in target mode. When operating as an initiator, the device drivers abstract

register-level operations, and the crypto-channels and controller operate the

execution units

So if you want to know how to use the MCF SKHA you should start by reading the MCP150 manual. This is a standalone encryption chip rather than a module inside a micro.

Except the above effectively says "you don't have to worry about which way around the bytes are as the device drivers handle all that for you". Device drivers?

Maybe MQX or the Processor Expert has drivers for this hardware. Does anyone know?

Tom

[matthewc]

Hi Tom,

Thanks for the quick reply.

Looks like you're exactly right. When loading the SKCRn registers, the SKKDRn registers, and the input FIFO (and when reading from the SKCRn and the output FIFO) the bytes need to be reversed. The other registers, such as the key size (SKKSR) and the data size (SKDSR), appear to expect big endian.

It's a shame there was never an errata or notice covering this, but I guess that's what forums are for.

Thanks again,

Matt.

[TomE]

I suspect the reason the SKHA is little-endian in a big-endian CPU is that the protocols are little-endian in the way the bit manipulation works.

At least in the MCF532x there's the option of using DMA and having it reverse the data order on transfer.

We have a different problem with the SKHA. Given that there's no example code to copy we've had to write our own from the manual. We load up all the registers, load up the FIFO and set the "GO" bit.

It doesn't work. We've found we have to load up the FIFO, sit in a "for (i = 0; i < 20; i++)"  loop to waste some time and THEN set the "GO" bit or it never finishes (apparently never starts). There's nothing suggesting this is needed.

It might be that we're polling for completion and the high load of the register polling may be upsetting it. It might also be that we've misunderstood the "GO" bit as detailed in this post on the MHDA (which is similar to the SKHA)::

MCF5329 - Using the Message Digest Hardware Accelerator (MDHA)

I've just used Google with every keyword I can think of and I can't find any code anywhere that handles the SKHA. I'm getting hits on "MCF_SKHA_SKCMR" where it is defined in various copies of "mcf532x_skha.h" and "mcf523x_skha.h" out there, but no code at all in any publicly available sources. Nothing "#includes" the "mcf532x_skha.h" file either. So either it isn't used or code that does use it is "secret".

I've just found a bug in the MCF5329 manual (Revision 3, 2008, latest version). Luckily the MCF5235 manual is correct. In the MCF5329 manual the MDMR bits are described as:

Bit 10, diagram "SSL",              description "10 SSL Secure Socket Layer MAC"

Bit 9, Diagram "MAC FULL",    description MISSING

Bit 8, Diagram "SWAP,              description "8 SWAP Message Authentication Code Full"

Bit 7, Diagram "OPAD",             description "7 OPAD Swap message digest"

Bit 6, Diagram "IPAD",               description "6 IPAD Inner padding of message.

Tom