HWMv1とHWMv2
nRF Connect SDK 2.6.xまではカスタムボードの定義ファイルにはHWMv1(Hard Ware Model version 1)が使われていました。nCS 2.7.0からはHWMv2を使用することになったため、2.6.x以下のプロジェクトでカスタムボードを作成したものをビルドするとビルドログ中に
CMake Deprecation Warning at C:/ncs/v2.7.0/zephyr/soc/CMakeLists.txt:15 (message):
---------------------------------------------------------------------
--- WARNING: Functionality to describe SoCs in HWMv1 is ---
--- deprecated and should be replaced with HWMv2, including ---
--- boards. HWMv1 SoCs support remains only to ease the migration ---
--- of out-of-tree SoCs and associated boards. It will not be ---
--- possible to build using HWMv1 SoCs at all in future releases. ---
---------------------------------------------------------------------
というウォーニングが表示されます。今のところまだ大丈夫ですが近い将来にHWMv1はビルドできなくなると書いてあります。
最初はなんのことかさっぱり分かっていませんでしたｗ
なお、nCS 2.7.0以降のSDKでカスタムボードを新規作成する場合は最初からHWMv2が使われるので、2.7.0以降のSDKで新規にプロジェクトを作成する人には関係ありません。ですので思い切って2.7.0以降のSDKで作り直す(リファクタリング)するのもありだと思います。テンプレートの記述なんかも微妙に変化していて、フラッシュパーティションを例にすると、昔のSDKで作ったものは以下のようになっています。
&flash0 {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x0 0xc000>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0xc000 0x72000>;
};
slot1_partition: partition@7e000 {
label = "image-1";
reg = <0x7e000 0x72000>;
};
scratch_partition: partition@f0000 {
label = "image-scratch";
reg = <0xf0000 0xa000>;
};
storage_partition: partition@fa000 {
label = "storage";
reg = <0xfa000 0x6000>;
};
};
};
SDK 2.6.x(HWMv1)で同じように新規作成してみると以下のようになっています。
&flash0 {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 DT_SIZE_K(48)>;
};
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000c000 DT_SIZE_K(472)>;
};
slot1_partition: partition@82000 {
label = "image-1";
reg = <0x00082000 DT_SIZE_K(472)>;
};
storage_partition: partition@f8000 {
label = "storage";
reg = <0x000f8000 DT_SIZE_K(32)>;
};
};
};
若干分かりやすくなっている気がしなくもないですが、そうじゃなくても新しい書き方に倣っておいたほうが気分がいいってものです。(長いモノには巻かれろの精神で(笑))
なお、image-scratchがなんなのか分かっていません。
名前から考えるとDFUの時のテンポラリバッファですかね……。
コンバートすることもできる
当たり前と言えば当たり前ですが、既存の資産をそのまま捨てることなんてできないよという人もいっぱいいるはずです。ですので、ちゃんとHWMv1からHWMv2にコンバートするためのスクリプトが用意されています。board_v1_to_v2.pyです。
ruamel.yamlのインストール
まずこのスクリプトを動かすためにはruamel.yamlというモジュールが必要です。pip install ruamel.yamlで追加します。
コンバート作業をするパス
次に作業フォルダですが、例にあるようにボードファイルのルートに移動して実行するのがよさそうです。ということでhello_worldのプロジェクトフォルダから実行してみます。引数の一覧は以下の通りです。
python C:\ncs\v2.7.0\zephyr\scripts\utils\board_v1_to_v2.py --board-root . -b sample_board -g arm -v xenoma -s nrf52840
何が変わったのか？
DTSについては記述内容が全く変わっておりません。DTSの最初にv1って書いてあるから、てっきりこれがv2になるものだとばかり思っていたら全然そんなことはありませんでした(笑)。
どうやらファイル構成が大きく変わっているようです。今まではなかった
Kconfig.<board_name>
というファイルやboard.ymlなどがコンバートで生成されています。もちろん、SDK 2.7.0以降のカスタムボード作成で作った場合も同じように作成されます。
余談
DTSファイルの書き方を覚え直すことになるのか……とドキドキしていましたが、全然そんな変更ではありませんでした。あと、このことに関するドキュメントはこちらにあります。
いや、いつも見つけるのが大変なんですよ……ドキュメントが多すぎて(笑)
ドキュメント書いている人、ごくろうさまです。