2016/12/07

CryptoCell

発表されたnRF52840に載っているCryptoCell-310
CryptoCell-310なのか、CryptoCell-CC310なのかわからないが、長いのでCC310としよう。

ものとしては、ARMCryptoCell-300シリーズというものがあるらしい。


これは、暗号化のコプロセッサらしい。
コプロセッサということは、データを突っ込めば、マイコン側は使わずに計算してくれるということだろう。

暗号化か。。。
JTAGデバッガなどで強引にデータを見られても大丈夫、というよりも、暗号化してデータ保存するのが容易になるよ、というところだろうか?
しかし、暗号化するキーを埋め込んでいたら、それを読み取られると意味がないしなぁ。

 

Nordicのサイトの方には、CC310が提供する特徴として「Key Management Infrastructure」という項目がある。
このKeyは、暗号化キーのことだろうか。

一覧にKey agreementという項目もあるが、この方面に詳しくないので、ぱっと見てわからん。
DHは鍵交換のやり方だったと思うので、これのことを指しているのか。。

 

 

【後藤弘茂のWeekly海外ニュース】ARMの新セキュリティアーキテクチャ「ARMv8-M TrustZone」 - PC Watch

【後藤弘茂のWeekly海外ニュース】ARMがセキュリティ機能を統合した新プロセッサ「Cortex-M23/M33」を発表 - PC Watch

この辺りを読むと、ARMv8-Mにならないとメモリの暗号化までは行かないようだ。
そこまでやりたければ、Cortex-M23/33を使ったマイコンの登場を待つしかないか。

[nrf52]nRF52840

まだnRF52832をあまり使っていないのだが、それに+8したnRF52840というチップがリリースされたようだ。

nRF52840 / Products / Home - Ultra Low Power Wireless Solutions from NORDIC SEMICONDUCTOR

Cortex-M4Fで64MHzというところは同じで、Flashが512KB→1MB、RAMが64KB→256KBと増えている。
電圧は、1.7~3.6V→1.7V~5.5Vと広がっている。

TrustZoneと書いてある。
無理やりデータを引っこ抜かれるときの対策をどうしようか?というときに話題として出てくるのだけど、最近Cortex-M23やM33が出てきたというくらいしか知らない。
一部の機能が使えるとかだろうか?

USBもちょっと気になる。
まあ、自分でUSB対応することはないだろうけど、USBシリアル変換のケーブル無しでデバッグできたりするとちょっと楽かもしれない。

そして、SoftDeviceだが、S140になるらしい。
いつの間にか、nRF5 SDKもv12.2.0がリリースされていたが、その中には入っていないようだ。

 

早くも、Preview-DKができている。

nRF52840 Preview DK / Products / Home - Ultra Low Power Wireless Solutions from NORDIC SEMICONDUCTOR

まあ、早くもというか、Preview-DKが無いとモジュールメーカーが困るからだろうかね。
nRF52832のときは買ったけど、やっぱり一般人が買うものではないな。チップもまだ1.0じゃないので、改版によってすぐ使えなくなるし。

2016/12/06

[esp8266]esp-open-sdkのmake後

あれだけ時間がかかったesp-open-sdkのmakeだが、いったい何ができたのだろうか?
追いかけるつもりはないので、ディレクトリの中身だけ眺めておこう。

image

ああ・・・Non-OS SDKを取り込んでいたのね。

他にも、crosstool-NGやxtensa-lx-106-elfなどコンパイラっぽいディレクトリがあるが、make後に出てきたメッセージではsdkディレクトリ以下に-Iや-Lするディレクトリがあると書かれていた。

sdkディレクトリの中は、Non-OS版と同じようなフォルダ構成になっていた。
こういうときは、WinMergeで比較だ。
えいっ。

image

差分なし。

xtensa-lx-106-elfをビルドするためにNon-OS版が必要だったということもないと思うので、単にAPIが使えるようにしてあげているだけかもしれん。

 

esp-open-lwipは、lwipのESP版なのか。
lwIP - A Lightweight TCP/IP stack - Summary [Savannah]
lwIPは使ったことが無いのだが、keilで使えるライブラリの一覧で見たことがある。
どうやら、Non-OS版で使われているらしい。

が、使われているということは、ライブラリがあるということだ。
Non-OS版のlibを見ると、liblwip.aとliblwip_536.aが入っている。
sdkと比較して差分がなかったということは、ビルドしてまったく同じものができたか、単にNon-OS版のファイルをコピーしたかだ。
まあ、後者だろう。

では、一体なぜ・・・とmakefileを眺めて、理由が分かった。

lwip: toolchain sdk_patch
ifeq ($(STANDALONE),y)
    make -C esp-open-lwip -f Makefile.open install \
        CC=$(TOOLCHAIN)/bin/xtensa-lx106-elf-gcc \
        AR=$(TOOLCHAIN)/bin/xtensa-lx106-elf-ar \
        PREFIX=$(TOOLCHAIN)
    cp -a esp-open-lwip/include/arch esp-open-lwip/include/lwip esp-open-lwip/include/netif \
        esp-open-lwip/include/lwipopts.h \
        $(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/include/
endif

そう、デフォルトであるSTANDALONE=yの場合のみビルドされるものなのだ。

 

STANDALONE=nの場合は、バイナリ提供されているものはバイナリのまま使う方式だと思うから、気にせずよいということか。

2016/12/04

[esp8266]esp-open-sdkのビルド(STANDALONE=n)

やる気が起きないので、久々に仕事と何の関係もなくESP8266のことをやろう。
特に目的が無いので、githubに移動したというRTOS版を動かすことにする。

espressif/ESP8266_RTOS_SDK: Latest ESP8266 SDK based on FreeRTOS


まずは、コンパイル環境を作るところから始めるようだ。
以前、Ubuntu on Windowsでやろうとして、提供されたコンパイラが32bit環境でしか動かないようだし、参照しようとしたコンパイル環境がEspressifから出ていなかったので止めた。

RTOS版のRequirementsで紹介されているページも結局は同じコンパイル環境なのだけど、Espressifが紹介しているから、お仕事で使うことになったとしても納得できるだろう。
仕事とは関係なく、といいつつも、やっぱり考えてしまうよねぇ。

pfalcon/esp-open-sdk: Free and open (as much as possible) integrated SDK for ESP8266/ESP8285 chips

今回は、Ubuntu on Windowsではなく、VMware上のXubuntu16.04(64bit)でやる。
普段立ち上げていることが多いのでね。

 

書いてあるとおりに、cloneして、apt-getして、makeする。
モードとして、STANDALONE版とそうでない版があるらしい。
デフォルトはSTANDALONE版になるのだけど、ライセンスがどうのとあるので、そういうグレーなところはなるべく持ち込まないよう、STANDALONE=nで行う。
リンクするくらいだから、なんかうまいことやってくれればうれしいのだがね。

 

VM環境とは言え、そこそこましなビルド環境だと思っているのだが、15分経ってもmakeが終わらない。。
20分くらいかかったようだ。
最後に、コンパイラへのPATHと、includeとライブラリへのパス(-Iと-L)が表示されるので、メモして置いた方がよいだろう。スクリプトにしておくとよいのではないかな。
たぶん、STANDALONE=yだと不要なんじゃなかろうか。


ここまでやっておいてなんだが、なぜRTOS版にはコンパイラが別途必要なのだろう?
Requirementsにxccでもgccでもよい、と書いてあるので、実はNon-OS版の環境を持っていれば不要なのだろうか。

いつもgen_misc.shを実行するだけなので、どういうコンパイラを使っているかすら把握してなかったのだな。

[hw]1.27mmシングルを2つ並べてもデュアルにはできなかった

デバッガとして、SEGGERのJ-Link Liteをしばしば使っている。
相手に1.27mmのソケットがある場合はよいのだが、たまにないときがある。
RedBearのBLE nanoなんかがそうだ(mbedとして使う場合が多いのだろうけど)。
前回は無理やりピンを曲げたり、ピンだけ挿したりしてつないだのだけど、どうにも見栄えが悪い。

別の用事で、1.27mmのシングルラインのピンヘッダを折る用事があって、ちょうど5ピンが2つ残っていた。
これを挿せば目的を達するのではないだろうか?

image

はい、ダメでした。
2.54mmだとできるけど、1.27mmだからか、買ったピンヘッダがそうなのかわからないけど、厚みがあるようだ。

 

こういうのがちょうどよいのだけど、わざわざこれだけ買うというのもなぁ。。。

SWD (2x5 1.27mm) Cable Breakout Board ID: 2743 - $1.95 : Adafruit Industries, Unique & fun DIY electronics and kits

 

あるいは、2列のピンヘッダを自分でハンダ付けして2.54mmで使えるようにするか。
それだったら、J-Link LITEの根っこから生やせばよいのだけどね。

ピンヘッダ 2×5(10P) 表面実装用 1.27mmピッチ: パーツ一般 秋月電子通商 電子部品 ネット通販