Difference between TMS320DM8148SCYE1 and TMS320DM8148CCYE1

kiran patil96658 said:

What is the difference between TMS320DM8148SCYE1 and TMS320DM8148CCYE1.

The main differences are the DM814xS devices support additional ISS features (CSI2, IPIPE and H3A), Face Detect Engine, as well as Security features and the DM814xC do not support these features.

DM814xC CONTROL_STATUS[10:8] DEVTYPE should be 0x3 (GP device)

DM814xS CONTROL_STATUS[10:8] DEVTYPE should be 0x5 (HS device)

kiran patil96658 said:

how does it impact on development

Does not impact the development if you are not planning to use the above features:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/366464/1287957.aspx#1287957

BR
Pavel

Hi Pavel,

Thanks for quick reply.

We are designing custom board, where FPGA will drive YUV data on VIP0 port. In order to select proper part number, want to understand what do you mean by Security features.

Regards,

Kiran S patil

kiran patil96658 said:

want to understand what do you mean by Security features

Presuably some form of secure boot and such. Public info is basically nil.

I did notice the Cortex-M3 in the Security Subsystem is not available for general purpose use on such devices: the initial part of its ROM shows it performs general-purpose boot (allowing free use) only on Test(0)/EMUL(1)/HSL(2)/GP(3) devices, while on HS(5)/EMU(6) devices it jumps to ROM code which is not readable (on GP devices). Considering where it is situated, it probably acts like a TPM of sorts on such devices, or some kind of embedded crypto smartcard.

Pavel Botev said:

cryptography, firewalls

The hardware crypto accelerators are also fully usable on GP devices; linux drivers have been publicly released for some of them and getting the remaining ones to work would just require effort.  (The public-key accelerator is the most enigmatic of them, but I've already managed to poke it into performing a multiplication, so it's definitely functioning.)

The firewalls are also usable on GP devices with some limitations.  Some settings are only obtained from values exported from the control module, but the location of those registers isn't documented and I don't know if they can be modified.  A more annoying limitation is that I haven't fonud any way to configure which security domain (MReqDomain) is assigned to which initiator: the secss cortex-m3 has id 1 (and maybe the crypto DMA too, haven't checked yet) while every other initiator (afaik) has id 0.  This is especially annoying since this is the only identifying information proxied by EDMA (and also used for the built-in memory protection to its registers).

I would personally actually regard configuring the firewalls as good practice even if not needed for security for the same reason memory protection is useful to isolate processes:  it helps to catch bogus reads/writes due to software bugs sooner rather than later (and identifies which core is misbehaving, while a crash due to corrupted state typically doesn't).

Poor documentation is an issue though: the L4 firewalls are documented in the TRM, but the L3 firewalls aren't, although they are very similar to those in the OMAP4/5, which are documented in their TRMs.  And although crypto acceleration would be useful for many purposes, the security subsystem is basically only "documented" through the (incomplete) drivers that have been released.  I really don't understand this situation: witholding this documentation won't make the processor any more secure.  Note in comparison that ARM's TrustZone functionality is fully documented by them.

Hi Pavel/Matthjis,

Thanks for your detailed information.

One last question - In our requirement, we want to use cryptographic accelerator and SRTP(Secure RTP), which part number TMS320DM8148SCYE1 and TMS320DM8148CCYE1, would be suitable for these requirements.

Regards,

Kiran S Patil

Sorry for typo mistake.

which part number TMS320DM8148SCYE1 or TMS320DM8148CCYE1, would be suitable for our requirements.

Kiran,

The HW crypto accelerators can be used on both HS (SCYE1) and GP (CCYE1) device.

http://processors.wiki.ti.com/index.php/DM814x_Software_Design_Guide#Download.2C_Purchase.2C_or_Install_Additional_Packages_.2F_Dependencies

http://processors.wiki.ti.com/index.php/Installing_AM387x_C6A814x_DM814x_Crypto_Support

I will further check regarding the SRTP.

BR
Pavel

According to SRTP's specifications, it uses HMAC-SHA1 for integrity protection and AES in either "counter mode" (AES-CTR) or "f8 mode" for encryption.

HMAC-SHA1 and AES-CTR are standard algorithms supported by the crypto accelerators.

"f8 mode" is somewhat problematic since it not standard, but it could be viewed as encrypting a counter-stream in CBC mode and then xoring the result into the plaintext, so with a bit of creativity it might still be possible to let the AES accelerator do the majority of the work, albeit with some loss of efficiency compared to a standard mode of operation.

Note however that using the crypto accelerators from linux tends to incur a substantial penalty due to the overhead of the kernel driver, making it worthwhile mostly for "bulk" encryption rather than small packets.  Assuming the SRTP stream carries low-latency audio/video data that itself does not originate from linux (but e.g. the hardware video inputs) I would personally consider letting the Cortex-M3 processor in the security subsystem perform the SRTP framing since it has low-latency access to the crypto accelerators and on GP devices (8148CCYE) normally has no particular duties.  This would however require investing the effort of making (or acquiring) an SRTP implementation suitable for running on a cortex-M3 while making use of the crypto accelerators. On HS devices (8148SCYE) I don't think you can run custom software on the security subsystem cortex-M3 so then this is not option, but I'm not 100% sure since I'm not really familiar with HS devices.

Of course it's possible that ready-made SRTP solutions are already available, but I'm personally not doing anything with video so I'm not familiar with software offerings available for the 814x. Maybe Pavel's inquiry will yield something with regard to that.

Matthijs van Duin said:

This would however require investing the effort of making (or acquiring) an SRTP implementation suitable for running on a cortex-M3 while making use of the crypto accelerators.

and of course, given the state of public documentation I already complained about earlier, this assumes you can convince TI to provide documentation (under NDA presumably) or find a programmer who isn't afraid of having to do some empirical science to figure out how things work in SecSS (I can give some pointers on how to get started if desired).

Matthijs van Duin said:

"f8 mode" is somewhat problematic since it not standard,

I have to correct myself:  Cameron Moree in this topic pointed me to this this post which lists f8 as supported by the AM335x AES engine; and this is the same one as on the DM814x/AM387x.  I then actually remembered having seen "f8" and "f9" as options, but — having never heard of these modes — I incorrectly assumed they were just generic placeholders ("function 8", "function 9") reserved for future use.

All cryptographical aspects of SRTP therefore appear to be supported by the hardware crypto modules.