MMUとプロテクション機能を積極的に使った、
新しいRTOSシステム
バグの自動検出も
可能な新開発環境
京都マイクロコンピュータについて
• 設立
1985年
• CEO
山本 彰一
• 国内拠点
本社・開発拠点
京都市西京区
東京オフィス
港区新橋
• 海外販売
韓国代理店：Nextech Solutions Co., Ltd
インド代理店：Celestial Systems Pvt. Limited
• 主要製品
JTAGエミュレータ
PARTNER-Jet2
GCC コンパイラ
exeGCC
開発プラットフォーム
SOLID
プラットフォーム変更のお悩み
ベアメタル
RTOS
システムも大型化してきたし
、
アプリも複雑化してきたし、
そろそろ…
RTOS
Linux
システム設計
大変そう
デバッグ
大変そう
printf デバッグで、
やり切れるか？
プログラミングモデルの
パラダイムシフトはリスク、できれば
リアルタイム性も確保で
マルチCPU +マルチOS
そんなのうちで
作れるのかよ？
開発リソース
不足も心配
お使いの
プラットフォーム
検討中
プラットフォーム
組込みソフトウエア開発の普遍的なお悩み
・納期どおりに開発する
・品質を確保する
・快適な操作性
・出来るだけ安価に
これらを実現するための開発環境として生まれたのが、
SOLID開発プラットフォームです。
• 開発環境とRTOSが一体化提供される、
組み込み向けソフトウェア開発プラットフォーム
• SOLID-IDE
• VisualStudioベースのIDE
• GCC/Clangコンパイラベースのツールチェイン
• KMCが創業以来培ってきたデバッガ
• SOLID-OS
• リアルタイムOS（TOPPERSカーネル）
• Armプロセッサに対応した専用ランタイムライブラリ
• これを一つ用意するだけで、開発がスタートできる「優れモノ」
とは
SOLID-OS
SOLID-IDE
LLVM/Clang
コンパイラ
デバッガ
(Visual Studio ベース)
JTAG/デバッグモニタ
TOPPERS/ASP3, FMP
デバッグ支援, ミドルウェア
ツールを
パッケージ化した
統合開発環境
ここが新しい！
連携というより、むしろ、各々のツールが専用設計されている
• RTOS実装とコンパイラの専用化
• RTOS実装とデバッガの専用化
• コンパイラとデバッガの専用化
• IDEを、RTOS,コンパイラ,デバッガに合わせて専用化
組み合わせを限定することで、使う側には、一体専用設計によるメリットが大
きく享受される。
そんな開発プラットフォームが
SOLID
です。
本日の三つのポイント
• RTOSなのに、MMUによるプロテクションが簡単!!
• RTOSなのに、ファイルからの実行が簡単
RTOSなのに、
MMUによるプロテクションが簡単!!
従来の多くの開発案件では、、、、
Cortex-AでRTOSを使うとき、MMUはキャ
ッシュオン（データキャッシュ有効化）
のために”だけ”使っていませんか？
• Linuxなどの高級OSを使う場合は、それらのシステムがMMUを高機能に使ってくれるが、
、、、
• そうでない場合、極端にMMUを有効活用していないのが多いのでは？
MMUを積極的に使うには
おそらくMMUを使うための設定のプログラムなどが、なかなか
面倒だったのでは？
SOLIDが解決します
さっきから同じ事、しつこいですよね、、、
ただ、これがSOLID作る大きなきっかけの一つなので、、、
• メモリマップエディタによる簡単な設定で仮想アドレスを有効化
• MMU周りのAPIを整備して提供
メモリマップエディタで設定した例
メモリマップエディタで設定した例
周辺レジスタの領域は、プログラム開発
しやすいよう論物一致で設定
同じアドレスの
バッファを、、
異なるアドレスで、
キャッシュオンと、
キャッシュオフで割り付け
MMU関連APIの例
• メモリマップエディタで設定すると、自動的に設定テーブルが生成され実行時に初期化されるが、それだけでなく、後
からプログラム中でAPIを使ってMMUを制御する事も出来ます
• 物理アドレスの論理割り当て、解放関連
• SOLID_MEM_Map, SOLID_MEM_Unmap, …• I/O領域の論理割り当て、解放関連
• SOLID_MEM_AllocIO, SOLID_MEM_FreeIO, …• 論理アドレス管理関連
• SOLID_MEM_IsValid, SOLID_MEM_VA2PA, SOLID_MEM_SetAttr, …
• キャッシュコントロール関連
• SOLID_MEM_CACHE_Invalidate, SOLID_MEM_CACHE_Clean, …
• 詳しくは以下のドキュメントで
では、SOLIDはLinuxなのか？？
SOLIDではMMUを簡単に積極的に使うために割り切りをした
割り切って出来なくしたこと
• ユーザーモードを使わない
• 全てのプログラムはスーパーバイザーモードで実行
• したがって、割り当てた領域は、全てどこからでもアクセス可能
• 基本的にページテーブルを切り替えない
• Linuxユーザー空間のように、同じアドレスで異なるメモリ、にはしない
• メモリ空間は単一の一つの空間しか存在しない
SOLIDは割り切りのMMUだから､､､､
• メモリ空間が一つしかない
• 同じ論理アドレスは、同じメモリ
• 実行レベルは常に一つ
• どこからでも、どこのメモリをアクセス可能
すなわち、今までのRTOSでのプログラムで
のメモリアクセスとなんら変わらない!!
• プログラム中で新しく学習する必要があまりない
• いままでのプログラムを効率よく移植して実行が可能
MMUを積極的に使うと
• メモリプロテクションを使った効率よい開発
• 0番地などはメモリを割り当てない
• 実行メモリなどは書き換え不能に設定
• SOLIDでは開発環境のリンカスクリプトとSOLID-OSの連携で、各セクションのメモリアクセス権を自
動設定します
• 物理的なメモリを効率よく利用
• SOLIDでは4Kページを採用することで、効率よくメモリ割り当てをします
• 論理アドレスが離れていても、その隙間に物理メモリを割り当てる必要はありません
• ELFローダーの利用
• SOLIDのELFローダーは、MMUで論理アドレスが使える事を前提に動作します
• サブモジュールは論理アドレス固定で作成することで、実行効率をよくしています
• 論理アドレス固定でも、隙間に物理メモリを割り当てないので、メモリ利用効率に優れます
SOLIDでのMMU関係の注意点
• 通常のプログラムでは、特に意識する必要はないが、DMAの場
合は以下の注意が必要
• DMAコントローラには物理アドレスを渡す必要がある
• 専用APIでアドレスを取得すれば良い
• DMA前後に適切にキャッシュメンテナンスが必要
• これは今までも同じだが、専用APIを用意しているので、それを利用すること
• これ以外は、MMUを有効にしていても、今までと同じ感覚で
RTOSプログラムが可能
• I/O領域をアドレス変換した場合、その部分は変換して読み替え必要だ
が、アドレス変換しなければ、これも必要なし
SOLID-OSのMMUによる安全な開発
• コンパイル・リンクしたプログラムは、各セクション毎に適切に
MMUの権限が設定されます
• .textなど
実行可能、リード可能、ライト不可能
• .rodataなど
実行不可能、リード可能、ライト不可能
• .dataや.bssなど
実行不可能、リードライト可能
• プログラムバグなどで、実行命令などの書き込みからの破壊を即時検出しま
す
• タスクのスタック突き抜けを保護します
• RTOSが生成するタスクスタックを割り当てるとき、隣接境界のメモリを割り
当てないことで、スタックを使いすぎたときに、即時に検出します
スタック突き抜け検出の様子
スタック突き抜け詳細情報
RTOSなのに、
ファイルからの実行が簡単
SOLIDの複数プログラム対応
• 標準搭載のELFローダーの仕組みを使えば、分割開発、分割ロードが可能
• 分割開発ごとに、実行ファイルを生成可能。SOLIDのELFローダーが、メモリを効率的に実
行ファイルを展開し、実行
• ローダー機能は、特にRTOS（TOPPERS/ASP3, TOPPERS/FMP）に依存せず実装
• ローダーが存在するからといって、RTOSを使ったプログラム方法は変化しない
• SOLIDローダーの機能は、シンボルへのアドレス解決をしているだけ
• ELFローダーとRTOSマルチタスクを使えば、複数アプリケーションの並列実行の
ような環境を実現
• 並列実行は必須ではなく、シングルタスクでも可能です
実行時のイメージ
メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーションメモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能 アプリ 2 アドレス解決 相互呼び出し可能 アドレス解決 相互呼び出し可能起動直後
アプリ１ロード
アプリ２ロード
アプリサイズ変更も問題なし
メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーションメモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能 アプリ 2 アドレス解決 相互呼び出し可能 アドレス解決 相互呼び出し可能起動直後
アプリ１ロード
アプリ２ロード
システム部分のサイズ変更や、
アプリ開始アドレス変更も問題なし
メモリ空間
SOLIDシステム + RTOS + システム初期 アプリケーションメモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アドレス解決 相互呼び出し可能 アプリ 2 アドレス解決 相互呼び出し可能 アドレス解決 相互呼び出し可能起動直後
アプリ１ロード
アプリ２ロード
MMUを使ったメモリ管理で、
隙間があっても効率的なメモリ利用が可能
メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アプリ 2実行する時のメモリ空間は、MMUを設定した仮想アドレス空間を利用
物理メモリ空間
SOLIDシステム+ RTOS + システム初期 アプリケーション アプリ １ アプリ 2この隙間には、実際にはメモリが存在しない。アクセスすると例外発生
SOLIDローダーの特長
• 各サブモジュールは、固定の論理アドレスでリンク
• 実行時（ローディング時）に、アドレス再配置を行わない
• 実行時には未解決シンボルのみ、アドレスを解決して設定
• 各サブモジュールの実行アドレスをあらかじめ決めておく必要はあるが、実メモリの予約は不要
• 必要なメモリをローディング時に払い出す
• 関数だけでなく、変数のアドレスも解決可能
• 複数のサブモジュールをローディング可能
• アンロードが可能
• ただし、そのモジュールの公開しているシンボルが、どのモジュールも利用していない場合に可能
• 実装としては、スタティックリンクの最後の工程を、実行時に行っている感じ
• 解決後の命令などはスタティックリンクしたものと同じ
ローダー対応に必要な条件
• SOLID開発環境で作成できること
• ツールチェイン（コンパイラやリンカ）に専用機能を追加しているので、SOLID開発環境利用が前提
• ARM側プログラムに、SOLIDコアサービスのうち、以下の追加が必須
• SOLID ELFローダ
• SOLID ARM v7メモリ管理マネージャ
• SOLID ファイルシステム抽象化レイヤ
• ファイルシステムの実体は、システムやユーザー毎に自由に変更・実装が可能
• Exportシンボルリスト
• テキストファイルに、アプリケーションが外部公開するシンボル名を定義すること。関数のプロト
タイプや変数種別など型情報は必要なく、シンボル名称のみをテキストのリストアップ
• マルチタスク機能が必要な場合には、RTOSを追加
開発やデバッグ
• SOLID-IDEでアプリケーションプロジェクトを作成してビルド
• 他のアプリケーションのプロジェクトや、ベースシステムのプロジェ
クトが無くてもかまわない
• SOLID-IDEを使ってアプリケーション単体だけをデバッグ可能
• ベースシステムや他のアプリケーションがROMなどに書き込んである
状態で、開発しているアプリケーションのみをIDEデバッガからデバッ
グ可能
• ROMなどに書いてあるアプリケーションを、SOLID-IDEで作成し
たアプリケーションと置き換えてデバッグ可能
システムに応じて
必要なFSやデバイス
に対応して実装
SOLID 標準実装として
KMCから提供
SOLIDファイルシステム
SOLIDファイルシステム
抽象化レイヤ
FAT FS
RAM FS
ROMFS
・・・・・・・
SOLID ELFローダ
SD
CF
HDD
DDR
NOR
SPI
SOLIDローダーがある事で可能になること
• アプリケーション毎の分割開発が可能
• 機能毎に分割したアプリケーションとして開発
• 協力会社と連携して開発するときに、アプリケーション分割して開発
• 開発する以外のアプリケーションは、ソースやオブジェクトなどが無い実行バイナリのみも可能
• システムや基本アプリケーションをROMに書いておき、協力会社に提供して追加アプリケーションのみ作成して
もらう、など
• MMU対応なので、余裕をもったアドレス割り当てをしても効率的にメモリを利用可能
• 機器の試験用アプリケーションを作成、用意しておき、試験モード起動などの作成が簡単に
ローダーがあると、、、分散開発へ応用
開発協力会社がアプリケーション単位で、
プログラムを分担して開発
ローダーがあると、、、仕向地向け開発への応用
ローダーがないと、、、、
また、自作のローダー的な物を作って対応、など
SOLIDのローダーは、アドレス解決の仕組みです。
関数コールだけでなく、変数のアドレス解決も可能。
すなわち、データをローダーで入れ替える事も可能の
で、仕向地別のメッセージなどの入れ替えに応用する
ことも可能
RTOSなのに、
リッチなデバッグ開発環境
代表的な自動バグ検出機能
• ソースコード静的解析機能を標準搭載
• 追加設定なく、ビルドの設定さえあれば、解析可能
• 0除算や不正ポインタアクセスの可能性などを検出
• アドレスサニタイザによる実行時メモリバグ検出機能
• iOSアプリ開発環境などで定評のアドレスサニタイザを、
組み込みで初めて実現
• バッファオーバーランや、解放後のメモリアクセスなど、
不正アクセスを自動検出
実行前のバグ検出
が可能。
デバッグを効率良
くします
プログラムの流れを遡っ
て解析し、不具合に至る
「きっかけ」となり得る
処理を指摘します。
静的解析機能
アドレスサニタイザ
（メモリアクセスバグ
の自動検出）
・バッファオーバーラン
・不正ポインタ
・二重解放など
手順はとてもシンプル
サニタイザモードでビルド＆実
行するだけです。
バグを検出する様子を動画で見
てみましょう。
アドレスサニタイザ
RTOSの状態分析
• イベントトラッカー（タスク遷移の解析）
• RTOSのプロセス・タスク・スレッドなどの遷移表示機能です。
JTAGエミュレータであるPARTNER-Jet2と連動して動作するので、イベン
トトラッカーとCPUのリアルタイムトレースを連携させた解析が可能
です。
• RTOSの資源表示
• プログラムをブレークしたときのタスクの状態や、スタックの使用量
などが一目でわかります。
イベントトラッカの結果を表示
• 機能が豊富にあるのですが、ここでは基本的な操作のみ説明します。
モジュール名
TID: タスク
INT: 割り込み
CYC: 周期ハンドラ
時間軸
緑実線:CPU実行中
黒破線:CPU実行可能
赤破線:待ち状態
青四角:
待ち遷移イベント
プログラムをブレークした
ときのタスクの状態や、ス
タックの使用量などが一目
でわかります。
SOLID-IDE標準搭載機能
• カバレッジ計測機能を標準搭載
• 実行済み・非実行コードが一目でわかる
• パフォーマンスチューニングのポイントが簡単に絞り込める
• LLVM-Clnagコンパイラの機能を利用しており、簡単に使えます
• ソース単位でカバレッジ測定する・しないを設定できます
• サイズプロファイル機能も標準搭載
• ROM化時のサイズ検討等が簡単にできます
• コンパイル単位で分析、セクション単位で分析、など、生成されたELF
ファイルを様々な角度からサイズ分析できます
コードカバレッジの機能
ソースコード中の各ベーシックブロック単位ごとに、実行された回数を記録、表示します。
ソースコード上に実行回数を グラフィカルに表示
