The CryptoCape is now available at SparkFun Electronics

The CryptoCape, a collaboration between SparkFun and myself, is now available for purchase at SparkFun Electronics [1]. In short, the cape adds some hardware crypto chips, a RTC with battery, and an ATmega328p which is designed to be flashed from the Beagle. It will be officially announced on the “new products Friday” post tomorrow, but I think this group deserved an early announcement.

Thanks to for making a great platform and special thanks to Robert Nelson for backporting the TPM driver to 3.8.

This community is awesome; I’ve learned so much by following this list. Thanks to everyone who shares their time and knowledge.

There’s only 1 left :slight_smile:

Happy Hacking!



It’s a cape that has the following security ICs on the Beagle’s i2c2 bus:

  • Atmel TPM (RSA 2048)
  • Atmel ATSHA204 (SHA/HMAC256)
  • Atmel ATECC108 (ECDSA)
  • Atmel ATAES132 (AES-128-CCM)

Plus an EEPROM and a 5pmm RTC.

It also contains an ATmega328p, which is loaded with the 3.3V pro mini bootloader. The ATmega is also connected on the i2c2 bus so the Beagle and the 328p can communicate over i2c.

Also, you can upload sketches from the Beagle’s UART4 to flash the ATmega.

The SparkFun product page is here, with a hookup guide:

The eLinux page is here:

The SparkFun page talks about each IC in more detail.


ok, the data interface for all these chips sits in the i2c bus, so it looks like for much real encryption work this cape will be really slow, bottle necked and constrained by the chosen bus and it’s bandwidth. I might also suggest for a rev 2 adding a set of 3 way jumpers such that it can sit on either i2c1 or i2c2. the inclusion of solder jumpers for pullups or not on the i2c bus was a good choice. I also fail to see what this cape does or assists with that the AM3358/AM3359 does not already do with it’s on board cryptographic abilities which do at a minimum AES, SHA, & MD5, and possibly others.


Hey Eric, thanks for the question, where did I read that before :wink:

Thanks for the recommendation, I’ll look into the bus select option.

The goal of this board is not to provide cryptographic acceleration, because you are correct, the AM335x does have accelerators already (drivers in 3.13). The purpose rather, is to provide key isolation. So the RSA/ECC/MAC keys stay in the respective chips. For ECDSA for example, the private key never leaves the chip. In the AM335x case, you’d have to provide the key somehow in software.

Also, the AM335x doesn’t have any asymmetric crypto options. The TPM provides RSA-2048 and the ECC108: ECDSA with three NIST curves.

yes, yes, it may have been posted in 2 places… If you’d like to see the revised board files I’ll pass them along. It took all of 5 minutes in eagle to make the update and add 2 more 3 way solder jumpers (or change them to header type jumpers for ease of end user configurability for slightly increased parts cost… thinking I’ll go back and add both in parallel and the header version can remain unpopulated or filled later at user descretion.


How is the RTC implemented at the software level? More to the point perhaps, how early in the boot process does the system time get set from (presumably) rtc1?

About a month or so ago I setup a battery backed RTC, along with a fairly current systemd. Systemd have chosen to rewrite hwclock and last I looked it still only honored/used rtc0. Perhaps I didn't explain the situation good enough on the systemd mailing list, but I couldn't seem to get past anyone not understanding why a board wouldn't have a battery backed RTC on board. Having said all that I did get it working just using init.d scripts. Just seems like such an ugly hack when the whole point of systemd is to essential do away with all the scripts.

The board looks like something very interesting to explore. I'm sure one will find its' way here when cash flow permits.


The RTC uses the ds1307 kernel driver and you’re correct, it shows up as rtc1. It is loaded when the capemgr instantiates the device tree, since the driver is in the CryptoCape DTS file. So you shouldn’t need any init.d/systemd scripting it should "just work"TM.

You’ll have to set the clock once and then it should hold pretty well. In testing think I had a bum battery b/c it depleted rather quickly. Once I changed batteries it seems to be holding steady.

Yes, this is nearly identical to the setup I did. Created a dto for the ds1307, loaded it at boot, all good. The device is there, it has very good time. The system still needs to be told to use that time. If memory serves Robert updates a time value that gets loaded so if your on a fairly current image your time is somewhat current. I’ll be more than happy to RTFM, or experiment if pointed in the right direction. I’ve not seen any indication that simply adding a battery backed RTC, loading it via capemgr will cause the system (kernel) to use that device for obtaining a somewhat sane time value. Mike

Are you guys talking about the crypto cape or the RTC cape? The crypto capediscussed in this thread uses a ds3231 not a ds1307. Also why anyone needs the rtc cape I don’t get. just keep the rtc rail powered on the processor. That I believe is a software issue.



You are correct, the CryptoCape has the DS3231. However, it use accessed via software via the ds1037 kernel driver. That driver is compatible with the 3231:, line 36. I haven’t tried any of the other features like the Time of Day alarm so I’m not sure if that’s supported with this driver.

I put the battery on the CryptoCape so that the RTC will maintain time [1] when the cryptocape is physically removed from the Beagle and [2] when the Beagle is not connected to power.

Thanks for the questions!

The Cryptocape RTC is what I was specifically asking about. The ds1307 modules handles several rtc chips. enum ds_type { ds_1307, ds_1337, ds_1338, ds_1339, ds_1340, ds_1388, ds_3231, m41t00, mcp7941x, rx_8025, last_ds_type /* always last / / rs5c372 too? different address… */ }; I’d be happy to pursue keeping the rtc rail powered. I have no clue where this is or would be handled in software. I’m far from being any kind of good programmer, and know far to little about hardware at this level. Just a long time sys admin willing to learn it if pointed in the right direction. Mike

From TI User guide on the TPS65217 [1] I find this. TPS65217C is also targeted at the AM335x processor in the ZCZ package, but the DCDC1 output voltage is set to 1.5 V to supply DDR3 memory. Gerald has stated before that there isn’t a battery backed RTC available. Why would I even question this, faulty memory on my part perhaps? The question that still nags me is how does one set a sane time value from a battery backed RTC as early as possible during bootup. Systemd only supports setting the time from rtc0, no options to specify any other device. Sillyness IMNSVHO… I probably have already answered my own question, just use a shell script ala init.d and be done with it. Mike 1.

The documentation and datasheets on this seem contradictory at best. You are correct in quoting in that it states, “TPS65217C is also targeted at the AM335x processor in the ZCZ package, but the DCDC1 output voltage is set to 1.5 V to supply DDR3 memory. This version does not support AM335x RTC-only operation.” However reading the data sheet for the TPS65217C found here, , one finds on page 15 the difference between the sleep and the off modes of operation wherein the setting of the OFF bit in the STATUS register determines the state that is entered and what rails remain up. if one enters sleep, the RTC rail looks like it stays up with all other rails down (escentially hibernation) with darn near zero power usage. I’m hoping to find the relivant source in the next couple days (sources for pm-hibernate, pm-sleep, shutdown, halt, etc. and the kernel sources) that invoke these states. It looks like just maybe a bit of an appropriate software hack (never going to off state, but only to sleep) could eliminate the need for off board / off chip RTC.


I’m trying to interface to the ATECC108 but I’m not running linux. Main issue I’ve run into is trying to wake up the chip, which requires holding SDA low for at least 60 usec. This is tricky because the AM335x I2C controller won’t send any data to the bus without sending an address first, and if it doesn’t get an ACK after sending the address it won’t send any data, just aborts the transaction with a STOP condition.

In the libcrypti2c code you have a function ci2c_wakeup() that sends two 0 bytes to the device. How do you get the AM335x to send those bytes, if the device is asleep and thus won’t ACK the address? Or are you doing the same thing I’ve found, which is that the low bits in the device address happen to hold SDA low just long enough to wake up the chip? (I keep hoping there’s a better solution, not involving any bitbanging. Maybe there isn’t.)

Thanks for the question, but I don’t think you will like my answer:

the ci2c_wakeup as you have discovered is indeed a hack. I looked into to a cleaner way to do this. My conclusion was that to produce a “proper” wakeup signal I’d have to mux the SDA pin to a GPIO mode to pull it low and then mux it back to I2C to use the I2C controller.

I had also considered connecting a different GPIO pin to the SDA line with the sole purpose of pulling that low for the wakeup. But that seemed more hackish than what I was currently doing.

In the end, the two bytes of zeros seems to reliably, albeit hackishly, do the trick for me when I’m using linux.


'Sokay, it’s some comfort to know I’m not missing a glaringly obvious solution.

If you happen to have a scope on the bus someday, I’d be curious whether those two zero bytes actually get out to the bus though.
What clock rate are you running?

I’ve seen them get out on a logic analyzer. I think it’s using the fast speed of 400kHz? But I always get confused on the speed and like you said, I’d have to measure it to be sure.