hiro99ma blog

何か技術的なこと

DevAcademy “Adding custom board support” (5)

2024/07/26

引き続き DevAcademy IntermediateのAdding custom board supportを見ていく。

Lesson 3 を Exercise 2 まで見たが、nRF5340 + MCUboot はできたものの nRF5340 + MCUboot + TF-M がうまくいかないため試行錯誤中。

CONFIG_FPROTECT=n

いっそのことCONFIG_FPROTECT=nでもいいんじゃないか。 プロテクトしようとするからACLやSPUが出てくるが、まだ私には早いのだ。 DFUするときにやり直そう。

child_image/mcuboot.confを作ってCONFIG_FPROTECT=nと書いたがwarningっぽい波線が表示された(vscode上で)。 C:\ncs\v2.6.1\bootloader\mcuboot\boot\zephyr\prj.confでCONFIG_FPROTECT=yになっているという。確かになっていた。 いいのかな？ 今度はビルドが進んだような気がするので、よかったと思おう。

Partition Manager?

しかしエラーで止まった。

Dropping partition 'nonsecure_storage' since it is empty.
Partition manager failed: partition tfm_secure (['mcuboot_pad', 'tfm']) does not span over consecutive parts. Solution: ['tfm', 'mcuboot', 'mcuboot_pad', 'app', 'mcuboot_secondary']
Failed to partition region flash_primary, size of region: 1048576
Partition Configuration:
mcuboot:
  placement:
    before:
    - mcuboot_primary
  size: 49152
mcuboot_pad:
  placement:
    before:
    - mcuboot_primary_app
  size: 512
tfm:
  placement:
    before:
    - app
  size: 32768

CMake Error at C:/ncs/v2.6.1/nrf/cmake/partition_manager.cmake:331 (message):

Partition Managerのエラーである。

ちなみに 1048576 = 0x10_0000 = 1MByte で nRF5340 の Flash も 1MByte である。 なので内蔵Flash に “nonsecure_storage” のパーティションが割り当てられていないからエラーになったのだろう。

めんどくさそうな話だが評価ボードnRF5340 MDBT53-1Mモジュールピッチ変換基板のボード定義ファイルをまねしておけば良かろう。 ・・・こちらも同じエラーが出ていた。 なるほど、non-secure とそうでないのとでパーティションの設定は共有できないのだな。

ncs を “nonsecure_storage” でgrepすると、TF-M関係らしきディレクトリでPM_NONSECURE_STORAGE_ADDRESS, PM_NONSECURE_STORAGE_SIZEが、nrf/subsys/partition_manager/以下で知らない拡張子のファイルがいくつか、ボード定義ファイルだとYMLファイルに名前があった。 Thingy53のボード定義ファイルにpm_で始まるYAMLファイルもそうである。

ビルドログの Partitoin Manager 関係のところを見ると warning が出ていた。

CMake Warning at C:/ncs/v2.6.1/nrf/cmake/partition_manager.cmake:79 (message):
  

          ---------------------------------------------------------------------
          --- WARNING: Using a bootloader without pm_static.yml.            ---
          --- There are cases where a deployed product can consist of       ---
          --- multiple images, and only a subset of these images can be     ---
          --- upgraded through a firmware update mechanism. In such cases,  ---
          --- the upgradable images must have partitions that are static    ---
          --- and are matching the partition map used by the bootloader     ---
          --- programmed onto the device.                                   ---
          ---------------------------------------------------------------------

pm_static.ymlというファイル名でないとダメなのだろうか。 念のためThingy53(ns)でビルドしたが同じwarningが出ていた。 なんだ、意味が無いwarning立ったのか。。。

warningとは別に”Found partition manager static configuration”というログが2箇所あった。 cpuappとcpuapp_nsだ。 つまり、雰囲気からするとPartition Managerの設定ファイルは読み込んでいるのだろう。

ならば私もpmファイルを置けば良い。 それぞれpm_static_devacademy_nrf5340_cpuapp.ymlとpm_static_devacademy_nrf5340_cpuapp_ns.ymlという名前にしてコピーし、外部Flashらしき設定を削除した。 PCDもいらないだろう。
そうやって置いたものの”Found partition manager static configuration”というログが出ない。 ビルドのセクションとしては「child image mcuboot」という名前のようなので MCUboot 関連だろう。

=== child image mcuboot -  begin ===

child imageの例としてブートローダが上げられているし、”child_image == MCUboot”でよかろう。

Thingy53(ns)のビルドログと比較するとconfigurationの読み込みでthingy53_nrf5340_cpuapp.confを使っているところくらいか。 MDBT53ボード定義ファイルのときにも似たようなファイルをコピーしたので、中身をコピーしてchild_image/mcuboot.confに貼り付けて加工する。

貼り付けただけでは失敗したのでCONFIG_FPROTECT=nとCONFIG_SECURE_BOOT=yだけにすると child_image として b0 のビルドが行われるようになってしまった。

=== child image b0 -  begin ===

CONFIG_SECURE_BOOT=yを設定しないと “Dropping partition ‘nonsecure_storage’ since it is empty” になってしまうのだ。 ただ、pm_を読み込むログは出ていない。 なぜCONFIG_SECURE_BOOTかというと、上の方に載せたpm_static.ymlがないというログを出すところの条件に入っていたからだ。 まあ、設定してもログは出なかったが。

もしかしてCONFIG_SECURE_BOOT=yがb0のビルドをすることになった要因だろうか？ child_image の cpuapp は BOOTLOADER_MCUBOOT で cpunet が SECURE_BOOTとか。 いや、Thingy53ではempty_net_coreがあり、これがcpunetのようだ。

=== child image empty_net_core - CPUNET begin ===

それにb0ではなくb0nだった。

=== child image b0n - CPUNET (inherited) begin ===

いかん、迷走している。。。

整理しよう

Partition Manager!

Partition Managerに関する部分だと思うが自信はない。 が、手がかりもないのでここから攻めよう。

せっかくDevicetree overlays, CMake, and multi-image buildsやMulti-image builds and the Partition Managerがあるので見ていく。

Devicetree overlays, CMake, and multi-image builds

DevAcademy Fundamentals: Lesson 3 > Devicetree overlays, CMake, and multi-image builds

multi-image buildsのところだけ

「自動でmulti-mage buildになる」といってるのは、nRF9160DKみたいにすでにボード定義ファイルが準備されているならば、という言葉が省略されているのかな？ 新規でボード定義ファイルを作る場合はnsも何もないし。

Multi-image builds and the Partition Manager

DevAcademy Intermediate: Lesson 8 > Multi-image builds and the Partition Manager

この図は Lesson 3のものだが、SPEとNSPEを考えやすくするのに良かった。

Board files for multi-core hardware & TF-M

前回眺めたときは nRF9160DK のことしか書かれていなさそうだったのでほとんどスルーしていたのだが、今見るといろいろ重要なことが書かれていた。

DevAcademy Intermediate: Lesson 8 > Board files for multi-core hardware & TF-M

これをまねしつつ、Thingy53から設定をコピーしたりしていると動いたような気がする。

弱気なのは、確認する方法がよくわからないからだ。 Build Configurationの下にはMCUbootとTF-Mがぶら下がっているし、LEDも点滅するのだが、それでも、ね。 Partition Managerは使われていないし “nonsecure_storage”パーティションも見つからないままなのだが、特にエラーにはならなかった。 使っていないからかもしれないし、DTSファイルにアドレスなどを書いているためかもしれない。 DFUするためのビルドではないので、特にPartition Managerで計算する必要がなかったのかもしれない。 あるいはそもそも期待通りに動いていないか。

< Top page
View on GitHub