STM32MP1 - COPROC
コプロセッサ管理

1.0 版

こんにちは、STM32MP1 コプロセッサ管理のプレゼンテーション
へようこそ。ここでは、プロセッサ同士がコマンドとイベントを介して相互作用し、データを交換し、リソースを共有する方法について説明します。

1

システムの概要
メインプロセッサ2

コプロセッサ

共有メモリ
MCUSRAM

ファームウェアメモリ
OpenSTLinux

MCUSRAM /RETRAM

Cortex-A7

CortexM4

HW セマフォ

メールボックスペリフェラル

IRQs

IPCC

IRQs

NVIC

GIC

HSEM

内部ペリフェラル
ペリフェラル XXX

ペリフェラル YYY

ペリフェラル ZZZ

STM32MP1 マルチプロセッサシステムでは、独立したファーム
ウェアを 2 つの CPU コアで実行できます。
• マスタの Arm Cortex-A7 プロセッサは Linux ベースの OSを実行するために最適化されています。
• スレーブ（またはコプロセッサ）の Arm Cortex-M4 プロセッサは、マイクロコントローラまたはベアメタルアプリケーション向けに最適化された RTOS を実行できます。
さらに、いくつかの内蔵された STM32 ペリフェラルをこれらのプロセッサのいずれかに割り当てることができます。

次に、2 つの内部メモリ領域がマスタプロセッサとスレーブプロ
セッサ間で共有されます。これらのメモリは、コプロセッサのファームウェアをロードして実行するのに使用されますが、プロセッサ間通信用の共有バッファなどの共通的構造を定義するのにも使用されます。
さらに、プロセッサ間通信の場合、プロセッサ間通信コントローラ（IPCC）という名前の特定のペリフェラルにより、専用メールボッ
クスによる信号の授受が可能になります。
最後に、ハードウェアセマフォ（HSEM）を使用して、共有リソース
を同時アクセスから保護できます。
2

主な概念

3

• コプロセッシング管理は、異種の非対称アーキテクチャでマルチコアを取り扱うために導入されたメカニズムです。
• コプロセッサを管理するために、以下のサービスのリストが提案されています。
• Cortex®-A7（Linux または Uboot）による Cortex-M4 ファームウェアのロードと制御• RPMsg メッセージとメールボックスに基づくプロセッサ間通信• リソース管理：• コアへのペリフェラルの割当て（アクセス権要求による）• システムリソース管理（両コアに共通のリソース）

詳細に入る前に、マルチプロセッサシステムでのコプロセッサの管理に関連する概念を理解することが重要です。
1 つ目は、Cortex-M4 コアのロードと制御です。Cortex-A7 コア
は、Cortex-M4 ファームウェアのロードと Cortex-M4 コアのリ
セットの制御を担当します。
その後、共有メモリと IPCC ペリフェラルに依存した RPMsg プロ
トコルによってプロセッサ間通信が確保されます。
最後に、次の機能を提供するリソース管理サービスが提案されます。
• ペリフェラルをコアに割り当て、このコアのみによるこのペリ
フェラルへの排他的アクセスを制御します。
• たとえばクロックや GPIO など、2 つのコア間で共有される共通（またはシステム）リソースへのアクセスを管理します。

3関係するフレームワーク

4• Cortex-A7 では、Linux OS により、リモートプロセッサの制御と、それとの通信を可能にする下記フレームワークが統合されています。
• RemoteProc - 汎用のリモートプロセッサフレームワークにより、リモートプロセッサの制御（電源オン、ファームウェアのロード、電源オフ）が可能になります。
• RPMsg - リモートプロセッサメッセージングは VirtIO ベースのメッセージングバスであり、これによって、カーネルドライバがシステムで利用可能なリモートプロセッサと通信できるようになります。
• VirtIO - VirtIO フレームワークは仮想化をサポートします。これにより共有リングバッファ（Vring）に基づく効率的なトランスポート層が提供されます。

• Cortex-M4 では、OpenAMP は、ベアメタルおよびリアルタイム OS（freeRTOS、
Zephyr など）用の RemoteProc および RPMSg フレームワークを統合しているライブラリです。

ソフトウェアに関しては、コプロセッサの管理は 3 つの主要なフ
レームワークを通して行われます。
リモートプロセッサすなわち RemoteProc フレームワークは、
Cortex-M4 コプロセッサが適切に動作するために必要なファー
ムウェアとすべてのリソースをロードする役割を果たします。
RPMsg という名前のリモートプロセッサメッセージングフレーム
ワークは、プロセッサ間通信に使用され、VIRTual Input Output
すなわち Virtio [Virt] [I] [O] フレームワークに依存しています。
この VIRTual Input Output フレームワークは、Vring [V] [ring]という名前の共有リングバッファプールを管理するメカニズムを提供します。
Cortex-A7 では、これらのフレームワークは Linux カーネルディ
ストリビューションでネイティブです。RemoteProc フレームワー
クは U-Boot にも組み込まれており、Linux ファームウェアの前に Cortex-M4 ファームウェアをプリロードできます。
Cortex-M4 では、ベアメタルおよびリアルタイム OS 用のOpenAMP [Open] [AMP] ライブラリを組み込むことによって、フレームワークを利用できます。

4

共有 RAM メモリのマッピング

5• Cortex-M4 ファームウェアは RETRAM のアドレス 0 から開始する必要がありますが、部分的に MCUSRAM に配置できます。
リビジョン A：SRAM3（128kB）
リビジョン B：SRAM3（64kB）+
SRAM4（64kB）

MCUSRAM4（64kB）
MCUSRAM3（64kB）

Cortex-A7 非セキュア

Cortex-M4

Cortex-A7 非セキュア

Cortex-M4

DMA バッファ
プロセス間通信（IPC）バッファ

MCUSRAM2（128kB）

データ

MCUSRAM1（128kB）

エンコード

リテンション RAM（64kB）

コードおよびデータ
例外テーブル• もちろん、お客様は、製品のニーズに合わせてこのマッピング（領域の場所とサイズ）を調整できます。

このスライドは、STM32MP1 デバイスで利用可能ないくつかのRAM バンクと、STM32 MPU の組込みソフトウェアディストリ
ビューションに適用される一般的なマッピングを示しています。
• RETRAM は、Cortex-M4 がベクタテーブルとコードおよび
データを配置するために使用します。
• MCU SRAM1 および SRAM2 を使用して、Cortex-M4
ファームウェアの残りのコードとデータを配置できます。
• MCU SRAM3 は通常、プロセス間通信バッファ（詳細は後述）のマッピングに使用されます。
• MCU SRAM4 は、DMA1 または DMA2 インスタンスを使用するときに広バンド幅が必要な場合に、Cortex-A7 用の
DMA バッファを配置するために予約できます。
このマッピングを領域の境界に合わせことは必須ではありません
が、Cortex-M4 メモリのハードウェア分離がバンク単位の粒度でサポートされているため、これは大きな関心事になる可能性があります。

5

：STM32CubeMX によって構成

ブートチェーン：認証（オプション）

Cortex-A7 セキュア（TZ）

DDR（最大 1 GB）

Cortex-M4
MCUSRAM（384kB）
リテンションRAM（64kB）

Linux アプリケーション
アプリケーション
フレームワーク

コプロセッサアプ
リケーションオプション
TF-A または
OP-TEE

FSBL

SSBL

セキュアモニタ

信頼できるアプ
リケーション

TF-A

ROM

ブートチェーン

OP-TEE：Open Portable
Trusted Execution
Environment (オープンで移植可能な信頼できる実行環
境)

ランタイムサービス

SYSRAM（256kB）

TF-A：Trusted Firmware
for Arm® Cortex-A
processors (Arm CortexA プロセッサ用の信頼できるファームウェア)

Cortex-A7 非セキュア

ROM コード

6

Linux

ファーム
ウェア

コプロセッサ

コミュニティ + ST アドオン

（ロード &）コール（ロード &）コールオプション

ユーザ空間

コミュニティ

カーネル
空間

ST

ロード

凡例

サードパーティ

U-Boot信頼できるブートチェーンは、ST マイクロエレクトロニクスが提供するデフォルトのソリューションであり、完全な機能セットを備えています。
Cortex-M4 ファームウェアは、Linux OS またはセカンダリブート
ローダ（U-Boot など）によってロードし、開始できます。
«通常»モードでは、ファームウェアはファイルシステムに保存されており、RemoteProc ファイルシステムインタフェースを介してLinux ユーザランドによってロードされます。
«早期ブート»モードでは、ファームウェアは BootFS パーティショ
ンにインストールされ、Linux ファームウェアが起動する前に UBoot によってロードされます。

6

ファームウェアの形式• ファームウェアは ELF 形式ファイルに保存されています。

/* Resource table with trace and Vring for IPC */struct remote_resource_table __resource __attribute__((used)) rproc_resource = { ¥.version = 1, ¥.num = 2, ¥.reserved = {0, 0}, ¥.offset = { ¥• ファームウェアバイナリには、オプションのリソー
ステーブルが、両方の Cortex コアから認知される特定の「.resource_table」セクションに定義されています。このテーブルは、以下の共通リ
ソースを定義するために使用されます。

offsetof(struct remote_resource_table,
rpmsg_vdev),
offsetof(struct remote_resource_table,
cm_trace), ¥}, ¥/* Virtio device entry for IPC */.rpmsg_vdev= {RSC_VDEV, VIRTIO_ID_RPMSG_, 0,
RPMSG_IPU_C0_FEATURES, 0, 0, 0,
NUM_VRINGS, {0, 0},},/* Vring rsc entry - part of vdev rsc entry */.rpmsg_vring0 = {VRING_TX, VRING_ALIGN, VRING_SIZE, 1, 0},.rpmsg_vring1 = {VRING_RX, VRING_ALIGN, VRING_SIZE, 2, 0},• デバッグのためにコプロセッサのトレースにアクセスするためのユーザ sysfs インタフェースを提供します。
• メッセージングサービスをサポートするために
RPMsg および VirtIO フレームワークをロードします。

7/* trace buffer declaration accessible from Cortex-A7*/.cm_trace = {RSC_TRACE,(uint32_t)system_log_buf,
sizeof(system_log_buf), 0, "cm4_log",},};

Cortex-M4 ファームウェアは ELF 形式で保存されており、UBoot または Linux から RemoteProc フレームワークによってロードされます。
コードおよびデータセクションに加えて、コプロセッサ管理に関連する機能をサポートするために特定のセクションを定義することができます。このセクションは、ファームウェアのロードフェーズ中に RemoteProc Linux フレームワークによって解析されるリソー
ステーブル構造で構成されています。
このテーブルで宣言されている最初の機能は、Cortex-M4 ログ
をリングバッファに出力する可能性があるリモートプロセッサト
レースバッファです。このバッファは Cortex-A7 側で監視できます。リングバッファのアドレスとサイズはリソーステーブルで宣言されます。
2 つ目は、プロセッサ間通信プロトコルです。RPMSG プロトコルを有効にするには、Virtio デバイスおよび関連する virtio リング
ディスクリプタをテーブルで宣言する必要があります。Cortex-A7
RemoteProc フレームワークは、マスタとして機能し、関連する
RPMsg バッファを MCUSRAM に割り当て、結果としてこのテー
ブルを完成させます。
7

プロセッサ間通信

8• プロセッサ間通信とは、Cortex-A コアと Cortex-M コア間の通信を可能にするために準備された下記メッセージングサービスを指します。
• メッセージサービスは、共有メモリを介して RPMsg および Virtio フレームワークによって管理されます。
• ドアベル／メールボックスサービスは、IPCC 内部ペリフェラルによって提供されます。
RPMsg

トランスポート層

VirtioMAC 層

共有メモリ IPCC

物理層

Cortex-M4 プロセッサと Cortex-A7 プロセッサ間のプロセッサ
間通信は、RPMSg メッセージングサービスに依存しています。
RPMsg および Virtio フレームワークは、通信に関連するバッファの管理を担当します。
次に、ドアベルまたはメールボックスメカニズムを使用して、新しいメッセージが利用可能であることをプロセッサに通知します。この信号は、プロセッサ間通信コントローラ（IPCC）によって生成されます。

8プロセッサ間信号授受のための IPCC

サードパーティ
コミュニティ

ハードウェア

9

凡例

ST

信号の方向

OpenST
Linux

Cortex A

ユーザ空間
カーネル空間Cortex M

foo_driver

アプリケーション

メールボックス

stm32_ipcc

HAL_IPCC

P2

P1

P2

P1_CH2_TXF

P2_CH1_RXO
P2_CH2_RXO...

TXF IRQP1

RXO IRQ

チャネル 1
P1_CH1_TXF

ORRXO IRQ

NVIC

IPCC

OR

TXF IRQ

GIC

ハードウェア

P1

P2

P1

P2

P1_CH1_RXO
P1_CH2_RXO

P2_CH1_TXF

OR

OR

チャネル nP2_CH2_TXF

STM32MP1 に統合された IPCC ペリフェラルは、Cortex-A7 と Cortex-M4 間の通信用に 6 つの双方向チャネルを提供します。
原理は、次のとおりです。
コア、たとえば Cortex-A7 は、他のコア、ここでは Cortex-M4 に Rx 占有•（RXO）割込みを生成するチャネルフラグを設定します。
•
Cortex-M4 はフラグをクリアしてチャネルを空けます。これによってCortex-A7 に TX フリー（TXF）割込みが生成されます。
IPCC ペリフェラルはバッファを管理せず、ドアベルのようにしか機能しないことを理解することが重要です。
RPMsg メッセージングは、2 つの双方向チャネルを使用します。チャネルは、
RPMSg バッファが使用可能であることを通知するために一方向で使用され、RPMSg バッファが解放されたことを通知するために他の方向で使用されます。
STM32 MPU 組込みソフトウェアディストリビューションでは、IPCC チャネル 1
は Cortex-M4 から Cortex-A7 コアへのメッセージに使用され、IPCC チャネル
2 は Cortex-A7 から Cortex-M4 コアへのメッセージに使用されます。
Cortex-A7 では、IPCC はメールボックスソフトウェアフレームワークによって制御されます。
Cortex-M4 では、IPCC は HAL_IPCC ソフトウェアドライバによって制御されます。

9RPMsg プロトコル
RPMsg バッファ／Vring

エンドポイント
RPMsg
クライアント A

RPMsg
チャネル
« サービス X»

RPMsg
クライアント B

RPMsg
チャネル
« サービス X»

1
2

データ

1
2

データ

10

エンドポイント

RPMsg
チャネル« サービス X»

RPMsg
クライアント A

RPMsg
チャネル
« サービス X»

RPMsg
クライアント B

OpenST
Linux
Cortex A

Cortex M

STM32 MPU 組込みソフトウェアディストリビューションでは、RPMsg プロ
トコルがプロセッサ間通信に使用されます。
このスライドは、RPMSg プロトコルとそれに関連する概念のプレゼンテー
ションです。
RPMSG プロトコルは、ローカルアドレスからリモートアドレスへのメッセー
ジの送信で構成されます。メッセージは共有メモリのバッファに格納されます。Virtio 層は、Vrings という名前の、関連ディスクリプタを持つリングバッファを使用して、バッファライフサイクルの管理を担当します。
それぞれの Cortex で、RPMsg クライアントがサービスを提供します。このクライアントは、下記によって識別されます。
• サービス名称によって定義されるサービス• アドレス識別子と操作コールバックによって定義されるエンドポイント
RPMsg フレームワークは、サービスの登録時に、«ネームサービスのお知らせ» メッセージをリモートプロセッサに送信します。このメッセージでク
ライアントエンドポイントのアドレスが提供されます。
リモートプロセッサ側では、RPMSG フレームワークは、ローカルクライア
ントが同じサービスを登録しているかどうかを確認します。この場合、両方の RPMsg クライアント間にチャネルが作成され、ローカル RPMsg クライ
アントにチャネルが結合されていることが通知されます。

10

サードパーティ
コミュニティ
ハードウェア

例：RPMsg 上の仮想 UART

凡例

ST

11

仮想リンク

OpenSTLinux

アプリケーション

Cortex A

Cortex M

アプリケーション/dev/ttyRPMSG0TTY RPMSG チャネル
stm32_rpmsg_tty

virtual_hal_uart

MCUSRAM
RX & TX Vrings

rpmsg

OpenAMPバッファ

rproc_core

stm32_ipcc

IPCC

CA7 Linux ワールド

HAL_IPCC

CM4 ファームウェア

この仮想 UART は、RPMsg プロトコルを使用するアプリケーションを示すために STM32MP1 デバイス用に実装した例です。ここでの目的は、RPMSg プロト
コルで UART をシミュレートすることです。
Cortex-A7 コアでは、stm32_rpmsg_tty ドライバは RPMsg クライアントであり、Linux ユーザランドにシリアル TTY コンソールを公開し、UART と RPMsg プロ
トコル間のアダプテーション層を実現するために実装されています。
Cortex-M4 コアでは、「仮想 HAL UART」サービスが RPMsg クライアントです。
アプリケーション向けに HAL UART API を提供し、UART と RPMsg プロトコル
間に同じアダプテーション層も提供しています。
Cortex-M4 上の仮想 UART の初期化によって RPMSG チャネルが作成されます。これにより、「TTY RPMSG」サービスのエンドポイントが作成され、「新しいサービス」のお知らせが Cortex-A7 に送信されます。

Cortex-A7 側では、メッセージが処理され、対応するサービスがstm32_rmpsg_tty ドライバに関連付けられます。Linux ドライバが探査されてエンドポイントが作成され、/dev/ttyRPMSG0 ファイルシステムインタフェースが作成されます。これ以降、Cortex-A7 コアは仮想 UART チャネルを介してメッセー
ジを送信できます。
仮想 UART の複数のインスタンスを作成できることに注意してください。
RPMSG プロトコルで言えば、このアクションはインスタンスごとに新しいエンド
ポイントを作成することになります。その結果、/dev/ttyRPMSG<X> インタ
フェースが Cortex-A7 側に作成されます。

11

用語

12

• STM32 のリソース管理メカニズムを理解するために、知っておくべきいくつかの以下の用語があります。
• 割当て：コアへのペリフェラルの割当ては、このペリフェラル（またはハードウェアブロック）がそのプロセッサによって使用されることを意味します。
• 共有リソース：ペリフェラルの動作に必要な共有リソースまたはシステムリソースであり、ペリフェ
ラルが割り当てられているマスタコアによって制御されます（クロック、レギュレータ、GPIO などのリソース）。

コプロセッサのリソース管理は、マルチコアシステムでのペリフェ
ラルの管理メカニズムの実装に対応しています。
まず、リソース管理を理解するために、いくつかの概念を定義する必要があります。
ペリフェラル割当てという用語は、1 セットのペリフェラルを
Cortex のコンテキストに割り当てるアクションを意味します。たと
えば、I2C ペリフェラルは Cortex-A7 コアまたは Cortex-M4 コアのどちらかに割り当てることができます。
他方で、いくつかのペリフェラルまたはリソースは、いくつかのコンテキストで共有する必要があります。共有リソースは通常、リセットおよびクロック制御用の RCC のようなシステムリソースです。

12

共有された IP

A7S と A7NSに A7NS と M4に
よって共有
よって共有

ペリフェラルの割当てと共有

凡例

A7S または
A7NS または
A7NS に割当て M4 に割当て
A7 セキュア A7 非セキュア
M4 に割当て
割り当てられた IP （TZ）に割当て
に割当て

13

A7S、A7NS、M4
によって共有コプロセッサCortex-A7
Cortex-A7
（マスタ）
（マスタ）
コア

割込み

ウォッチドッグ

STGEN

EXTI

IWDG1

SysCfg

GIC

IWDG2

RTC

NVIC

WWDG

RAM

SYSRAM（256kB）

DDR CTRL

LPTIM（x5）

DMAMUXDMA1MDMAMCUSRAM1-2（256kB）

MCUSRAM3（128kB）

RETRAM（64kB）

GPIOZ

ネットワーク
PWR

TEMP

FDCAN

デバッグ
DBGMCU

DMA2

BSEC

RNG2

HASH2

ETZPC

CRYP2

CRC2

TZC400

RNG1

HASH1

TAMP

CRYP1

CRC1

DSI

LTDC

ビジュアル
GPU

GPIOA-K

電力と熱
RCC

セキュリティ

DMA

IO

タイマ
TIM（x15）

バックアップ SRAM
（4kB）

Cortex-M4（コプロセッサ）

HSEM

IPCC

HDP

STM

Ethernet

FMC

SDMMC1/2（*）

SDMMC3（*）

DCMI

CEC
（*）：一部のペリフェラルは多機能であり、お客様によって異なるマッピングがされる場合があります。

低速インタフェース
USART（x3）

UART（x4）

SPI6

USART1I2C（x4）。

SPI（x2）

I2C4

I2C6

アナログ
VREFBUF

D/A コンバータ（x2）

DFSDM（*）

A/D コンバータ（x2）

SPDIF-RX

SAI（x4）

大容量記憶装置デュアル QSPIUSB ホストUSB OTG

高速インタフェース

SPI I2S（x3）（*）

オーディオ

このスライドでは、STM32MP1 プラットフォームで可能なペリフェラル割当てを示しています。
この概念に沿って、この図の凡例は、各ペリフェラルの以下の 2 つの可能な状態を区別して示しています。
•「割り当てられた」とは、1 つのハードウェア実行コンテキストのみが実行時にペリフェラルを使用していることを意味します。単一色のボックスは割当てが静的であることを意味しますが、垂直セパレータ付きの 2 色または 3 色のカラーボックスは、アプリケーションのニーズに応じて、特定のコンテキストにペリフェラルを割り当てるためにユーザの選択が必要であることを意味します。この割当ては、STM32CubeMX ツールで、または手動で行うことができ、Cortex-A7 セキュアおよび Cortex-M4 コアのハードウェア分離によって補強されています。
「共有された」とは、ペリフェラルが同時に 2 つまたは 3 つでさえも異なる実行コンテキス•
トによって使用できることを意味します。このモードは、共通リソースにアクセスするときに、指定されたコンテキスト間で競合が発生しないことを保証するレジスタバンキングや他のメカニズムを使うことを意味します。
例：•
左側にある TIM インスタンスは 1 つのランタイムコンテキストに割り当てることができ、このコンテキストのみによって使用されます。
•
すぐ下の RCC ブロックは、3 つのランタイムコンテキストから同時にアクセスできるシス
テムペリフェラルです。
以下のスライドの目的は、「割り当てられた」リソースと「共有された」リソースを管理するために
STM32MP1 プラットフォームに実装された概念を説明することです。
割当てに関連するすべてのメカニズムは、ST Wiki ページでさらに説明されています。
この図は、STM32 MPU 組込みソフトウェアディストリビューションにおける割当ての ST マイク
ロエレクトロニクスの推奨または選択を示していることに注意してください。その他の可能性については、STM32MP1 のリファレンスマニュアルで説明されている可能性があり、このディスト
リビューションで後で検討される場合があります。

13

ペリフェラル管理の課題

14• ペリフェラルを Cortex-M4 コアまたは Cortex-A7 コアに割り当てる：• ペリフェラル（またはハードウェアブロック）がそのプロセッサによってのみ使用されることを意味します。
• 開発者は、グローバルシステムでの割当ての一貫性に責任があります。
• STM32CubeMX ツールでは、TF-A、U-Boot、Linux、および HAL_init のデバイスツリーに Cortex-A7 またはCortex-M4 が使用することを事前入力することで、開発者のためにこの一貫性を保証することができます。

• 分離：• ペリフェラルは、セキュアな部分または Cortex-M4 コア用に分離できます。
• TF-A セキュアファームウェアは、 ETZPC レジスタに基づくペリフェラルの分離をデバイスツリーに従って管理します。
• STM32CubeMX ツールでは、Uboot/TF-A のデバイスツリーに事前入力することで、開発者のためにこの分離を実現できます。

• クロックや GPIO などの共有リソースを設定する• リソースは、ハードウェアセマフォによって保護されるか、デバイスツリーに従って Linux によって設定されます。
• STM32CubeMX ツールでは、Linux のデバイスツリーおよび HAL_init 関数に事前入力することで、開発者のためにこのリソース設定を行います。

リソース管理の実装を理解するには、マルチプロセッサ環境で発生する関連課題を理解することが重要です。
STM32MP1 マイクロプロセッサでは 2 つのコンテキストが並行して動作しています。ペリフェラルが 1 つのコンテキストに割り当てられている場合、
このペリフェラルはこのコンテキストのみが管理しなければなりません。したがって、グローバルシステムの一貫性を確保する必要があります。これを実現するために、STM32CubeMX ツールは、ペリフェラルを割り当てる
ためのインタフェースを提供しています。
STM32MP1 は、セキュアな部分または Cortex-M4 にペリフェラルを分離する可能性も提供しています。分離は、拡張 TrustZone 保護コントローラ（ETZPC）テーブルの設定を介して、セキュアファームウェア TF-A によって管理されます。STM32CubeMX ツールでは、分離に関係する TF-A デ
バイスツリーを設定することでこれを管理することもできます。

最後に、一部のリソースは共有リソースです。これらのリソースは、一般にペリフェラルを操作するために必要になります。そのタイプに応じて、シス
テムリソースは、システムの一貫性を確保するために、ハードウェアセマ
フォで保護するか、Linux コンテキストで排他的に管理する必要があります（たとえば、クロックツリー管理）。同様に、STM32CubeMX ツールは、
共有リソースを正しく設定するのに役立ちます。
14

STM32CubeMX によるペリフェラルの割当て

15• チェックボックスにチェックを入れると：• ペリフェラルを次のコンテキストの 1 つに分離するた
めに TF-A デバイスツリーにコードが生成されます。
•••

Cortex-A7 セキュア
Cortex-M4
Cortex-A7 非セキュア• Cortex-A7 またはCortex-M4 でドライバを有効にするためにコードが生成されます（デバイスツリー）。
• Linux デバイスツリーにコードが生成され、ペリフェラ
ルの設定に応じてペリフェラルの動作に必要なすべての共有リソース（クロック、レギュレータ、GPIO、
EXTI）が宣言されます。
• Cube ファームウェアコードが、Cortex-M4 コアに関連するペリフェラルを初期化するために生成されます。

このスクリーンショットは、STM32CubeMX ツールで実行できる割当ての例を示しています。
• USART4 は、Linux 用に Cortex-A7 非セキュアコンテキストに割り当てられています。
• USART5 は、STM32Cube 用に Cortex-A4 コンテキストに割り当てられています。
選択した設定に応じて、STM32CubeMX ツールは、次の方法でペリフェラルを Cortex コンテキストに割り当てます。
• TF-A のデバイスツリーを設定することでペリフェラルを分離する。
• 割当てに応じてノードを有効または無効にする Linux デバイ
スツリーを設定する。
• Cortex-M4 コアに割り当てられたペリフェラルを操作するために必要なシステムリソースを宣言する。
• Cortex-M4 コアに割り当てられたペリフェラル用の Cube
ファームウェア初期化コードを生成します。

15

リソース管理サービス

16• 2 つの実行コンテキストの共存を保証するために、リソース管理によって以下のいくつかのサービスが提供されます。
• ペリフェラル割当てリクエスト：Cortex-M4 で使用されるメカニズムで、ペリフェラルがプロセッサ用に予約されていることを確認します。原則は、使用を開始する前にペリフェラルの可用性を確認することです。
• コプロセッサ共有リソース構成の設定：コプロセッサでペリフェラルを操作するために必要な共有リ
ソースを構成するために、メインプロセッサ（Linux を実行する Cortex-A7）で利用可能なサービス。
• ハードウェアセマフォによる共有ペリフェラルの保護：両方のプロセッサで利用できるこのサービスにより、GPIO と EXTI の共有リソースを同時アクセスから保護できます。
• 共有リソースの動的再構成：コプロセッサがメインプロセッサに共有リソース構成の更新を要求できるようにするリモートメッセージングに基づくサービス。

リソース割当ての制御とチェックを支援するために、いくつかのサービスが STM32 MPU 組込みソフトウェアディストリビューションに実装されています。
• 最初のサービスは、STM32Cube ファームウェアに実装されたペリフェラル割当てチェックです。このユーティリティは
ETZPC テーブルに依存しており、初期化前にペリフェラルの分離を確認できます。
• 2 つ目のサービスは、共有構成の設定です。Cortex-A7 コアに実装され、ペリフェラルに関連付けられたクロックとレギュ
レータの設定を可能にします。これらの共有リソースは、電源管理の最適化のために Linux OS によって管理される必要があります。
• 次に、各 Cortex ファームウェアが GPIO および EXTI リソースの設定を担当します。これらの共有リソースの保護は、HSEM ペリフェラルに依存するハードウェアセマフォの使用によって保証されます。
• 最後に、リソースの動的再構成サービスが導入され、コプロセッサが動作中にクロックとレギュレータの設定を変更できるようになりました。
16

ペリフェラル割当てリクエスト• ETZPC テーブルに基づく設定：
ブート段階で、信頼できるファームウェア TF-A はペリフェ
ラル割当てを次のように設定します。

• TF-A はブートローダのデバイスツリーから設定を読み取ります。
• TF-A はそれを ETZPC レジスタへ書き込みます。

設定

A7 Linux
アクセス

M4 ファームウェア
アクセス

セキュア

不可

不可

非セキュア、M4 分離

不可

可非セキュア、 A7 または
M4

可

可

非セキュア、A7 分離 *

可

不可

17

* ソフトウェア分離のみ、ハードウェア分離なし（ハードウェア
アクセスは可能）• チェック：ペリフェラル割当てリクエスト機能により、ドライバはペリフェラルのアクセス可能性を確認できます。
ドライバを開始する前に、ペリフェラルへのアクセスが以下のように許可される必要があります。

• Cortex-A7 では：U-Boot が、ETZPC テーブルに依存する Linux デバイスツリーのペリフェラル
ノードを更新することにより、アクセスを許可します。
• Cortex-M4 では：ドライバを開始する前に、ペリフェラルへのアクセスはリソースマネージャユーティ
リティによって許可される必要があります。

ペリフェラル割当てリクエストサービスは、拡張 TrustZone 保護コントローラ（ETZPC）テーブルによって制御されるバスファイアウォールに依存しています。
セキュア／非セキュアコンテキストと Cortex-A7 または Cortex-M4 コンテ
キストへの割当てに応じて、4 つのモードが利用可能です。
Cortex-M4 コアからのアクセスは引き続き可能であるため、他のモードとは逆の非セキュア Cortex-A7 の分離は、実際のハードウェア分離ではなくソフトウェア保護であることに注意してください。
ETZPC テーブルは、TF-A セキュリティファームウェアによってそのデバイ
スツリーに基づいて入力されます。

その後、初期化段階で、次のようにアクセスが許可されます。
• Cortex-A7 コアでは、U-Boot は ETZPC テーブルに従って Linux のデバイスツリーを更新します。割当てに応じて、Linux での使用に宣言されたペリフェラルノードを有効または無効にします。
• Cortex-M4 コアでは、アプリケーションはペリフェラルを初期化する前にペリフェラルの割当てを確認する必要があります。リソースマネー
ジャユーティリティは、このアクセスを許可するサービスを提供します。

17

コミュニティ

凡例

サードパーティST

ペリフェラル割当てリクエスト

ハードウェアアプリケーション

アプリケーション

OpenST
Linux

Cortex-A

ユーザ空間

Cortex-M

カーネル空間リソースマネージャ
ユーティリティデバイスツリーY=OK、X=無効

stm32 ドライバ Y

18

ETZPC 設定に従って
U-Boot によって変更された Linux DT
HAL ドライバを使用する前にペリフェラル
アクセス権をリクエスト

stm32 ドライバ X

HAL_X

ETZPC テーブルはTF-A によって記入される

ハードウェアペリフェラル Y

ETZPC

ペリフェラル X

この図は、ペリフェラル割当てのチェックに関連するソフトウェア
アーキテクチャの概要を示しています。
この例では、TF-A ファームウェアがペリフェラル X を分離してCortex-M4 コアに割り当て、ペリフェラル Y をCortex-A7 コアに割り当てています。
• Cortex-A7 コアでは、ブート段階で U-Boot がペリフェラル Y
ノードを有効にし、ペリフェラル X ノードを無効にしています。
その結果、ペリフェラル Y の stm32 ドライバのみが有効になります。
• Cortex-M4 では、アプリケーションはリソースマネージャユー
ティリティによってペリフェラル X へのアクセス権を付与し、HAL API を呼び出して初期化します。

18

共有リソース構成の設定

19• 共有リソースは、両方のコアがペリフェラルを操作するために必要な場合に、同時アクセスから保護する必要があります。2 つの戦略：• ハードウェアセマフォを使った保護• 1 コアだけによる共有リソースの管理• ハードウェアセマフォによる保護： 共有リソースを保護してリソースレジスタへの同時アクセスを回避するデフォルトの方法• ピン：ピンの構成は Linux の pinctrl フレームワークによって管理されます。 GPIO モードでは、コプロセッ
サーは出力値の変更、および入力値の読出しができます。
• 外部割込み（EXTI）：GPIO と、関連する EXTI 割込みの間の結び付けは、Linux レギュレータフレーム
ワークによって管理されます。コプロセッサは、NVIC 割込みマスクの有効化／無効化を担当します。

• Cortex-A7 Linux フレームワークによる管理：電源管理戦略に関係する特定のシステムリソースに対して：• クロックツリー：クロック設定は Linux クロックフレームワークによって管理され、コプロセッサはペリフェラルのクロックゲーティングを担当します。
• レギュレータ：電源は Linux のレギュレータフレームワークによって管理されます。

このサービスの主な目的は、マルチコアシステムの共有リソースの構成を正しく管理することです。
これらのリソースを保護するために、以下の 2 つの戦略が実装されています。
• ハードウェアセマフォによる共有リソースの保護• 1 つの Cortex だけによる共有リソースの管理
HSEM ペリフェラルに依存するハードウェアセマフォによる保護がデフォルトで使用されます。これは、ハードウェアセマフォに共有リソースの重要なレジスタへの排他的アクセスを許可させることから成ります。これは、たとえば GPIO および EXTI 構成の場合です。

クロックやレギュレータなどの他の共有リソースは、Linux OS で管理する必要があります。主な理由は、Linux OS にネイティブに実装されている統合電源戦略です。実際、クロックとレギュレータの連鎖は、親ノードと子ノードを持つツリーで表すことができます。このツリーは Linux OS によって監視され、子の状態に応じて親を無効または有効にします。たとえば、
Linux は Cortex-M4 コアで使用されるクロックについて通知を受ける必要があります。この情報がない場合、Linux はクロックが使用されていないと見なし、親ノードとして PLL クロックを停止する可能性があります。

19

サードパーティ
コミュニティ

共有リソース構成の設定

凡例

ST

ハードウェア20• Linux によって設定されるリソース
アプリケーション

アプリケーション

HAL_..._MSP

OpenST
Linux

Cortex-A

ユーザ空間

Cortex-M

カーネル空間rproc_srm_dev
rproc_srm_dev

rproc_srm_dev

HAL_RCC

rproc_srm_core

クロックの有効化
／無効化

HAL_X

remoteproc

ハードウェアペリフェラル X

Cortex-M4 の X ペリフェ
ラル用にクロックとレギュレータを設定

RCC
PWR

このスライドは、Cortex-A7 コア上の Linux OS による共有リ
ソースの構成に関与するソフトウェアフレームワークを示しています。
リモートプロセッサシステムリソースマネージャ（RPROC SRM）
フレームワークは、割り当てられたペリフェラルを操作するために
Cortex-M4 コアが使用する共有リソースを宣言および構成する
ために ST によって開発されました。このフレームワークは、
Cortex-M4 ペリフェラルに関連付けられているノードのデバイス
ツリーを解析し、それに応じて共有リソースを構成します。SRM
デバイスドライバインスタンスはサブノードごとに有効にされます。
Cortex-M4 側では、クロックおよびレギュレータリソースは初期化されません。クロックゲーティングレジスタは Cortex に依存するため、ペリフェラルクロックのみが停止されます。

20

サードパーティ
コミュニティ

共有リソースの保護

凡例

ST

ハードウェア• HSEM によって保護されるリソース

21

アプリケーション

HAL_..._MSP

アプリケーション
OpenST
Linux

Cortex-A

ユーザ空間

Cortex-M

lock_resource
ユーティリティを介したアクセス

カーネル空間ピンコントローラ

IRQ コントローラ

stm32_pinctrl

stm32_exti

HAL_EXTIHAL_HSEM

HAL_GPIO

HAL_XXX

stm32_hwspinlock

ハードウェア
EXTI

ペリフェラル XXX

HSEM
GPIO

このスライドは、ハードウェアセマフォによる共有リソースの保護に関与するソフトウェアフレームワークを示しています。
Cortex-A7 コアでは、GPIO および EXTI の設定レジスタへのア
クセスは、HSEM セマフォがフリーならば取得し、そうでなければ解放されるまで待機するハードウェアスピンロックによって保護されます。
U-Boot ブートローダもブート段階で同じハードウェアセマフォを使用することに注意してください。
Cortex-M4 コアでは、アクセス保護はアプリケーションによって管理され、ロックリソースユーティリティ API によって許可される必要があります。
このユーティリティは、保護するリソースに応じてセマフォをロック／ロック解除するシンプルなインタフェースを提供しています。

21

例：Cortex-M4 に割り当てられた I2C

22

void HAL_I2C_MspInit(I2C_HandleTypeDef *hi2c){
OpenST
Linux

Cortex-A@ soc {
i2c1: i2c@40012000 {compatible = "st,stm32f7-i2c";
status = “disabled";}};@M4_hw_resources {compatible = "rproc-srm-core";status = “enable";
M4_IP_I2C@0x400012000 {compatible = “rproc-srm-dev";
status = “okay";clocks = <&rcc_clk I2C1_K>;
pinctrl-0 = <i2c1_pins_a>;};};Cortex-M...
/*HW semaphore Clock enable*/__HAL_RCC_HSEM_CLK_ENABLE();
if (SystemResourceConfigAllowed(SYS_RES_RCC)) {/*##-1- Enable the HSI clock #*/RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct)!= HAL_OK){/* Error */while(1);}/*##-2- Configure HSI as I2C clock source #*/RCC_PeriphCLKInitStruct.PeriphClockSelection = RCC_PERIPHCLK_I2Cx;
RCC_PeriphCLKInitStruct.I2c123ClockSelection = RCC_I2CxCLKSOURCE;
HAL_RCCEx_PeriphCLKConfig(&RCC_PeriphCLKInitStruct);}/*##-3- Enable peripherals and GPIO Clocks #################################*//* Enable GPIO TX/RX clock */I2Cx_SCL_GPIO_CLK_ENABLE();
I2Cx_SDA_GPIO_CLK_ENABLE();/* Enable I2Cx clock */I2Cx_CLK_ENABLE();/*##-4- Configure peripheral GPIO ##########################################*/PERIPH_LOCK(GPIO);
HAL_GPIO_Init(I2Cx_SCL_GPIO_PORT, &GPIO_InitStruct);
HAL_GPIO_Init(I2Cx_SDA_GPIO_PORT, &GPIO_InitStruct);
PERIPH_UNLOCK(GPIO);}

コードの設定に関して、STM32CubeMX ツールが共有リソースを管理するためのコードを生成します。
このスライドでは、Cortex-M4 コアに割り当てられた I2C ポートの共有リソースの生成について説明します。

Cortex-A7 デバイスツリーにおいて、リソースマネージャノードが、関連するクロックと GPIO の宣言とともに定義された I2C1 サブノードで宣言されています。
ペリフェラルを Cortex-A7 コアに割り当てるために使用された I2C1 ノードは以前に無効になっていることに注意してください。
I2C ポートに使用されるピンもデバイスツリーで宣言されていることに注意してください。GPIO はハードウェアセマフォによって保護されているため、この部分は任意です。ただし、この宣言はデバッグに使用することができ、ピンが別のペリフェラル用に予約されていないことを Linux OS がクロスチェックできるようになります。
Cortex-M4 側では：クロックの初期化は、「SystemResourceConfigAllowed」サービスによって•保護されています。実際、特定のケースでは、Cortex-M4 コアがクロックツ
リーを初期化する必要がある場合があります。これは、Cortex-M4 が UBoot のステージでロードされ、Linux ファームウェアの前に開始された場合に当てはまります。このサービスを使用すると、ブートモードに関係なく、同じファームウェアを使用できます。
•
この例では、GPIO の設定は、ハードウェアセマフォを取得するロックサー
ビスによって保護されています。
22

サードパーティ
コミュニティ
ハードウェア

例：I2C バスの共有

凡例

ST

仮想リンク

アプリケーション
OpenST
Linux

Cortex A

Cortex M

リモート I2C リンク

rproc_srm_coreboard_driver（display, cam, …）

Cortex-M4 から／Cortex-M4 へ、I2C リクエ
スト／応答を送信／受信

I2C プロキシ

アプリケーション

RPMsg 上でI2C リクエスト／応答を
送信／受信

23

ETZPC

アプリケーションによって行われた I2C 割当てリクエストCortex-A7 から／CortexA7 へ、I2C リクエスト／
応答を送信／受信リソースマネージャユーティリティ

Virtual_hal_i2c

stm32_rpmsg_i2c
rpmsg

MCUSRAM

remoteproc

プロセッサ間で仮想
I2C を生成するために
RPMSG を使用する

stm32_ipcc

IPCC

Cortex-M4 またはCortex-M4 から／へ、
I2C リクエスト／応答
を送信／受信OpenAMP
HAL_I2C（マスタ）

HAL_IPCC

I2C は Cortex-M4 に割り当てられている

RCC

I2C

これは、以前に提示した概念のほとんどを使用したより複雑な例です。
STM32MP1 プラットフォーム上の Cortex-A7 コアと Cortex-M4コアの間で I2C ポートを共有する方法について説明します。
この例では、I2C ペリフェラルは Cortex-M4 コアによって管理されています。これは、ETZPC テーブルによって I2C が CortexM4 用に分離され、Linux のファームウェア SRM フレームワーク
が I2C バスの動作に必要なクロックを設定したことを意味します。
Cortex-A7 コアと Cortex-M4 コア間で I2C フローを転送するた
めに、STM32 MPU 組込みソフトウェアディストリビューションで提案されている仮想 UART と同じ原理で、RPMSg 上の仮想
I2C リンクを実装することができます。
Cortex-M4 コアでは、Cortex-M4 アプリケーションまたは仮想I2C HAL から I2C リソースを共有できるようにするために、I2C
プロキシが必要です。
コプロセッサ管理または ST32MP1 製品自体の詳細については、
st.com で入手可能な STM32MP1 ユーザーガイドを参照してください。
23