·

Linux のようなマルチスレッド機能を使いたいが、メモリ容量は節約したい。大容量メモリである DDR は電源回路コストが高いので使いたくない。

京都マイクロコンピュータでは、このようなお客様の不便を解消するため、「Linux における”ファイルからアプリケーションを実行する”という操作をリアルタイム OS 向けアプリケーションで使うにはどうすればいか」を、お客様と共に考えてきました。

インテリジェントローダー

そのような背景の元で生まれたのが SOLID インテリジェントローダーです。

～京都マイクロコンピュータが提供する、次世代のローダー～【第一章】こんなローダーが欲しかった！

インテリジェントローダーの仕様
組込みソフトウェアにおける一般的なローダーは、開発環境でビSOLID 開発プラットフォームの中の新兵器、それがインテリジェントローダーです。その名のとおり、「かしこく」それでいて縁の下の力持ち的なローダーが、組込みソフトウェアの開発スタイルを大きく変えようとしています。本書ではインテリジェントローダーを詳しく解説していきます。

ルドされたプログラムをターゲット実機で実行するため、実メモリ上に実行モジュールを転送します。
SOLID インテリジェントローダーの大きな特徴としては、ソフトウェ
アを分割開発した場合に、分割されたアプリケーション単位で個別にビルドされた実行モジュールを、個別にロードする機能を持つ

第一章では、「こんなローダーが欲しかった！」インテリジェントロー

点です。

ダーとは何か、をご紹介します。
第二章では、SOLID の API を使って具体的にロードする方法

1)

分割開発されたアプリケーション単位で個別にビルドできるを、第三章ではインテリジェントローダーの応用的な使い方や、動2)分割開発されたアプリケーションを個別にロードし、他のアプリケーションと結合して実行できる作の仕組みについてご紹介します。
3)

た当該アプリケーションのソースコードがあれば、プログラムインテリジェントローダーが生まれたき全体のデバッグ操作ができる
4)っかけ

他のアプリケーションのソースコードが無くても、分割開発し指定したアプリケーションのアンロードが可能

上記の仕様にすることにより、分散拠点で独立性の高い開発をお客様の「困った」を何とかしたい進められるという大きなメリットがあるだけでなく、開発中のソフトウェアを部分的に更新する場合のビルドおよびロード時間を大幅

ソフトウェアの規模が大きくなると、複数メンバーによるチーム開発に短縮する事もできます。

だけでなく、協力会社に委託をして共同開発するというスタイルが当たり前になっています。しかし、分散開発されたプログラムを実行・デバッグするには、一旦全てのソースコードを集結してビルド作業を行い、実行モジュールを生成する必要があります。
このような場面で、実際にソフトウェアを開発しているお客様から次のようなお困り事を聞くことが多くあります。
··

インテリジェントローダーを使ってできること
モジュール単体ビルド・ロードの便利な使い方

ビルド時間、ロード時間が長く、開発効率が悪い。何より、開発エンジニアの思考が中断されるのが困る。

ソフトウェア規模が大きく、複数のエンジニアや拠点で分割開発協力会社さんとの共同開発では、権利関係によってソースする例として、図 1-1 の様に開発会社（とりまとめ）が 2 拠点コードを開示できないケースがある。そのため、ビルド作業がの開発協力会社に機能単位でプログラム開発を分担する場合大変複雑になっている。

を考えてみます。
開発会社はソフトウェア全体の制御を行う部分（ハードウェアの初期化、MMU を利用したメモリ空間全体構成の設定やソフトウェア開発プラットフォーム SOLID 技術解説書 page 1RTOS カーネルなど）を担当します。ここではこの部分を「本体アまたこれとは逆に、協力会社がソースコードを開示することなく、プリ」と呼ぶことにします。

開発会社（とりまとめ）に実行モジュールのみを提供するだけ

開発会社は、協力会社 1 に、機器ハードウェアの自己診断プロで、本体アプリを単体で更新してビルド・ロードし、開発会社側でグラムを開発委託することにします（アプリ１）。また協力会社

プログラム全体を動作させることが出来ます(図 1-3)。

2 には、同社の持つノウハウを組み込んだデータ処理プログラム

実機デバッグにおいては、ソースコードが存在する部分はソースコ（アプリ２）を開発委託することにします。アプリ 1、アプリ 2 ともードデバッグが、ソースコードが無い部分はアセンブラレベルでのデに比較的本体アプリと切り離して開発が進められる例です。

バッグが出来ます。もちろんソースコードが無い部分であっても、ブ（本体および各アプリ間で共有するグローバル変数や関数名をレークポイントを設定してプログラムの動作確認ができます。

指定する方法は第二章で説明します）

図 1-1. 開発協力会社がアプリケーション単位でプログラムを分担して開発
図 1-3. 協力会社がソースコードを開示しなくてもソースコードを開示する必要がない
このような体制で開発する場合、本体アプリは ROM 等に書き込まれた実行モジュールだけがあればよく、ソースコードを協力会社に提供しなくても問題ありません(図 1-2)。SOLID 環境で開発されたプログラムであれば、本体アプリのソースコード無しでも、開発を分担する協力会社 1、協力会社 2 は各々の担当アプリ
ケーションを単体で開発し、ビルド・ロードを行い、メインモジュール各社がビルド・ロード・デバッグ可能
SOLID の開発対象は RTOS システムのようなリアルタイム制御システムなので、全てのアプリは単一の論理空間に配置されます。物理アドレス上も固定配置されるため、一度ロードしたプログ
ラムはユーザーの意図しないタイミングでアンロードしたり、アドレスが移動する事はありません。これも Linux のマルチスレッド動作な
どと SOLID が大きく異なる点であり、特長でもあります。と一緒にデバッグできます。

図 1-2. ソースコード無しで開発を分担

ソフトウェア開発プラットフォーム SOLID 技術解説書 page 2

【第二章】ローダーの使い方
第二章では、SOLID の API を使って具体的に分割ロードする方法をご紹介します。

ローダーを使ったプログラムの作り方
本体アプリとサブアプリに機能分割する
まず通常の分割開発と同様に、機能や目的に応じて開発対象の分割方法を決めます。このときプログラムの基本的な制御を行う部分を「本体アプリ」と定義し、SOLID で開発します。
本体アプリは、プログラム全体に必ず１つだけ存在するようにし、RTOS カーネルもこの本体アプリ内に配置することをお勧めしま

図 2-1. 本体アプリのシンボルをサブアプリで共有する（テキストファイルを利用）す。

サブアプリ(アプリ 1、アプリ 2)が本体アプリのシンボルを Import す

次に SOLID 環境で分割されたアプリケーションである「サブアプるには、図 2-2.のようにサブアプリ内で Import シンボル API をリ」を開発します。サブアプリには SOLID コアサービスや RTOS を使って直接シンボルを指定することも可能です。

カーネルを含む必要はありません。またサブアプリの数は 0～N 個と、柔軟に分割可能です。

シンボルを共有する
本体アプリとサブアプリ間では、通常グローバル変数や関数を共有する必要がありますので、SOLID においても同様の処理が必要です。
SOLID においてシンボルを共有する方法は２つあります。1 つはビルド時に共有シンボル定義ファイル（テキストファイル）を参照する方法で、もうひとつはプログラム内に API を使って定義する方法です。
まず、グローバル変数や共有する関数名などのシンボル情報を定義します。SOLID では、これらのシンボを他のアプリで利用する

図 2-2. 本体アプリのシンボルをサブアプリで共有する（API を利用）ため、Export シンボル：他のアプリにシンボルを利用させる
Import シンボル：他のアプリのシンボルを利用するという２つの API を用意しています。
図 2-1. では、本体アプリが API で Export 指定したシンボルをサブアプリ(アプリ 1、アプリ 2)がテキストファイルとしてビルドにより共有する方法を示しています。

ソフトウェア開発プラットフォーム SOLID 技術解説書 page 3これとは逆に、サブアプリ内にあるシンボルを本体アプリや他のアプインテリジェントローダーを使って分割開発されたアリが利用する場合は、図 2-3 や図 2-4 のように定義します。

プリを合体して実行するシンボルの共有はサブアプリ間においても同様の手順で定義できシンボル共有定義ができた「本体アプリ」「サブアプリ(アプリ 1、アます。

プリ 2)」が各開発拠点でビルドできたところで、それらのアプリケーションを結合して実行するまでの流れを紹介します。
ここで SOLID が用意したのが、本体アプリがサブアプリをロードするための API です。
ローディング API[SOLID_LDR_LoadFile()]

実行モジュールが存在するファイルパスを指定し、メモリ上にプログラムをロードします。この時点ではアプリ間の共有変数など相互参照しているアドレスは未解決の状態なので、まだアプリの実行は出来ません。
実行可能チェック API[SOLID_LDR_CanExec()]

ローディング API でロードすると決めたアプリが実行可能な
図 2-3 サブアプリのシンボルを本体アプリで共有する（テキストファイルを利用）のか（アドレス解決が矛盾なくできているか）をチェックし、問題無く実行できるならば True を返します。

図 2-4 サブアプリのシンボルを本体アプリで共有する（API を利用）
以上のように、SOLID では API を使ってシンボル共有を定義します。API で定義されることで、SOLID ではアプリ間のシンボル解決をするための処理をランタイムソフトウェアとして生成し、その実体を本体アプリ内に常駐させます。SOLID では、このようなアプリ内に常駐する管理用のランタイムプログラムをコアサービスと名付けています（コアサービスは京都マイクロコンピュータの造語で、ロード以外に MMU の管理などの機能も持っています。詳しくは第三章でご紹介します）。
コアサービス内にあるインテリジェントローダーは、本体プログラムを実行した際に、あたかもリンカが行っているようなアドレス解決を行いながら、メモリ上に実行モジュールを配置していく機能を持っています。

ソフトウェア開発プラットフォーム SOLID 技術解説書 page 4

図 2-5. でその手順を説明します。

【第三章】ローダーの応用例と動作の仕組み
第三章では、これまでご紹介してきたローダーの応用的な使い方や動作の仕組みについて解説します。また末尾では、インテリジェントローダー開発者からローダーが生まれた背景などもご紹介しています。

ローダーの応用例
バージョン管理もシンプルに効率よく組込み機器の場合、仕向け先によってプログラムの一部を変更して出荷する事があります。固定のデータ領域にパラメータだけを図 2-5 アプリを結合して実行するまでの流れ① まず、本体アプリをロードします。
② 本単アプリから、アプリ１をロードします。アプリ 1 は USB メモ
リやシリアルフラッシュメモリなど、ファイルシステム上に予めコピーしておきます。
③ プログラムが、実行可能な状態かどうかを確認します。

置き換えるような場合は問題ありませんが、きめ細かい仕向け先対応を行う場合は、プログラムそのものを変更する必要が生じます。
SOLID を使ってプログラム開発をすれば、図 3-1 のように仕向け先別に異なるアプリを各々個別に開発し、その後共通部分と組合せて実行が可能です。

④ しかし、アプリ２でも相互参照しているシンボルがあるため、この段階ではシンボル解決できておらず、実行できないという結果(False)が返されます。
⑤ 次にアプリ 2 をロードします。
⑥ 再度、アプリ 1、アプリ 2 が実行可能な状態かどうかを確認します。
⑦ 今度は全てのシンボルの相互参照が確認できたため、シンボル解決が完了したこと(True)が返されます。
⑧ これ以降、本体アプリ、アプリ 1、アプリ 2 は定義された相互参照シンボルを使ってシームレスに実行できるようになります。
（図中 ELF 解析、ELF 情報 という記載がありますが、こちらについては第三章で説明します）

図 3-1 仕向け先別にアプリを分けて開発する
このとき、各アプリのプログラムサイズが異なる場合、配置が異なる場合でも問題なく本体アプリから各アプリをロードでき、通常のソフトウェア開発プラットフォーム SOLID 技術解説書 page 5

アプリケーションのデバッグと同様に実機を使ったソースコードデバ

来上がったのがランタイムという形でのコアサービスです。コアサービッグができます。

スは縁の下の力持ちとして、SOLID には無くてはならない重要なもちろん拠点毎のアップデートに際しても、当該拠点のアプリだけ存在です。

を改訂すればよいのでソフトウェアのバージョンアップや検証範囲

ロード対象ファイルに含まれる情報は？

が限定でき、システム全体の管理が大変シンプルに効率よく行えSOLID ではツールチェーン(Clang/GCC)でビルド操作を行い実ます。
このようなモジュール分割開発ができないと、図 3-2 のように仕向け先のアプリを全て込んでビルドしているケースがあるのではないでしょうか。
これでは全体のプログラムサイズが大きくなりビルド・ロード時間が長くなってしまうばかりでなく、本来は独立で管理できるはずの拠点単位のアプリケーション(アプリ A、B・・・)の全てのバージョン組み合わせ管理の必要が生じるなど開発効率があまり良いとは言えません。

行バイナリのオブジェクトフォーマットである ELF フォーマットでアプリケーションの実行モジュールを生成します。
この ELF フォーマットの実行モジュールには、リロケータブル可能なプログラム本体と、ELF 情報としてロード処理に必要なシンボル情報および再配置情報が含まれています。SOLID で分割ロードをする場合は、図 3-3 のようにコアサービス内にある ELF 解析機構がロード対象の実行モジュール内の ELF 情報を参照しながら、シンボル解決を行います。
なお、この実行モジュールには、ソースコードのあるファイルのルートパス情報や、ソースコード内の行番号情報といったソース情報は含まれていません。
シンボル情報に相当する ELF 情報を含む SOLID 実行モジュー

図 3-2 残念なプログラム配置

ルは、それを含まないモジュールに比べて一般的に約 10～20%程度ファイルサイズが大きくなります。

インテリジェントローダーの仕組み
コアサービスという縁の下の力持ち
SOLID では「コアサービス」と名付けた一連のランタイムが IDE と密接に連携することで、特長的な機能の多くを実現しています。
インテリジェントローダーもコアサービスに実装されている機能のひとつです。
コアサービスには、ローダーの他にターゲットのリソース(メモリ/MMU、割り込み、タイマ等)の管理と、ユーザーへの補助(デバッグ）といった機能があります。
コアサービスはターゲットシステムの一部に常駐しており、システムセットアップや動的解析機能を使ったデバッグ時など、必要に応じて IDE とも連携して動作するソフトウェアです。 少し古いですが「BIOS のようなもの」と言えばイメージがわきやすいかと思います。

図 3-3 ロード対象ファイルは ELF 情報を含むローダーが行っている処理
インテリジェントローダー本体は SOLID で本体アプリをビルドする際に本体アプリ内にコアサービスとして生成されます。
第二章で紹介した以下の２つの API によりインテリジェントローダーが動作します。

ソフトウェアの構造としては、第二章の「ローダーの使い方」でもごローディング API[SOLID_LDR_LoadFile()]紹介したようにシンプルな API 群を使ってリソースを操作するもの

実行可能チェック API[SOLID_LDR_CanExec()]となっています。
またコアサービスでは、ブート時の MMU の仮想アドレスへの移行といった、ユーザーが操作するのが面倒な処理も受け持っています。
このような SOLID コアサービスの機能には、従来の開発環境やデバッグツールにおいては、PC 側で処理を行っていたものもあります。「使いやすさ」「リアルタイム」「コンパクト」を追求していく中で、ユーザーが「スマート」に開発できるよう「シンプル」な仕様として出これらの API がコールされるとコアサービスに制御が移り、ファイルシステム経由で実行モジュールを読み込み、シンボル情報を解析してアドレス配置を決定し(MMU の設定を含む)、物理メモリにプログラムをロードします。
SOLID では、コアサービスを含む本体アプリは必ず 1 つ必要です。またサブアプリは 0～N 個とその数に制限はありません。
シンボルの相互参照はサブアプリ間であっても有効であり、ローディング API や実行可能チェック API を実行した際に、コアサービス

ソフトウェア開発プラットフォーム SOLID 技術解説書 page 6

はサブアプリ間のシンボルの相互参照についても解決処理を行い行」できれば、同じ結果になる、つまりリンカが行っているアドレスます。

解決処理とローダーの動作をランタイム側で行えばよいのだという

なお、インテリジェントローダーでは実行プログラムを RAM 上に配点に着目しました。アドレス解決に必要な ELF 情報をランタイム置することを前提としているため、ROM 上やファイルシステム内のに含め、その ELF 情報を参照してプログラムを物理メモリ上に配プログラムを直接実行することは前提としていません（なぜなら、置する処理もランタイム側に置けば良いのです。

シンボル解決によるアドレスの再配置ができないからです）。

MMU によるメモリ管理と密接に連携するインテリジェントローダー

そのように検討した結果生まれたのが OS に依存しないベアメタ
ルのローダーである SOLID インテリジェントローダーです。ベアメタ
ルのローダーを新規開発することで、既存の RTOS やツールチェ

上記では、分割ロードをするためにはアプリ相互の共有シンボルや変数などのシンボル解決をランタイム内で処理することをしていーンといった汎用性の高いツールに手を加えることなく利用できることがわかってきました。

ることを説明しました。ファイルシステム上にあるデータ（実行モジ

なおこのローダーはランタイム側で動作するものなので、プログラムュール）を解析し、アドレス解決をしながら実メモリ（物理アドレサイズと実行時間に対するオーバーヘッドが極力少なくなるよう、ス）にプログラムをロードする際には、MMU を有効活用すること十分配慮して開発しました。

でメモリを効率よく利用できるようになります。

DLL 方式と異なる処理を採用した理由

SOLID のもう一つの特徴である「MMU の管理を簡単に行う」では、開発環境上のシンプルな GUI で論理・物理アドレスの設定

SOLID インテリジェントローダーは、DLL 方式ではなく当社が独を行うだけで MMU 設定処理を SOLID が生成する、という機自にその方式を考案しインプリしたものです。なぜローダーを独自能があります。Arm® Cortex®-A プロセッサでは比較的設定がに作ったのか、その結論に至った背景を一部ここでご紹介しま複雑とされている MMU の処理を SOLID が代わりに行うというす。

ものです。

まず第一に、ロード対象である複数のモジュール間で、共有シンインテリジェントローダーにおいても複雑なシンボル解決とプログラボルや関数の相互参照がしたかったからです。DLL 方式の場合

ムの配置に関わる一連の処理は SOLID がコアサービスの中でロードする側とされる側の親子関係が固定されてしまい、相互参行っており、その過程では MMU によるメモリ空間の管理を同時照が解決できない点に不便さを感じました(図 3-4）。に処理しています。
インテリジェントローダー行う実行時のアプリ間アドレス解決は広義の論物変換であり、MMU の仕事ともいえるでしょう。

開発者からツール屋として、できる事をとことん考えたLinux のマルチスレッドのような機構をリアルタイム制御システムで実現する一つの手段はオリジナルの OS を開発する方法です。

図 3-4 相互参照の関係の相違

つまり OS のカーネルの機能として分散開発されたアプリケーショ次に考慮したのが実行速度の点です。DLL 方式ではスレッドンを脱着できるようにすることです。しかし現実問題としてお客様（アプリ）が呼び出された時点ではじめて実行モジュールがメモリに全く新しい OS を提唱することは、かえってお客様の採用のハ上にダウンロードされます。この場合当然ながら実行時にダウンロードルを上げてしまう事になり、お客様にとっても当社にとってもメード時間がオーバーヘッドとなってしまい、RTOS 利用を対象とすリットは少ないと思われます。

るリアルタイム重視の制御システムには不向きです(図 3-5)。その京都マイクロコンピュータは、長年に渡り開発環境を第一線のお客様と共に手掛けてきた、プロの「ツール屋」ですので、開発ツールの視点からこの問題を解決する方法を考えました。

ためシステム起動時の初期化段階で全てのアプリのダウンロードを済ませておき、その後は論理・物理空間の固定したアドレスに全てのプログラムがロードされた状態でシステムを稼働する方法が好ましいと考えました(図 3-6)。

やりたい事は、複数のプログラムをビルドしロードすることです。開発環境がホスト PC で行っている事をアプリケーションの中で「実ソフトウェア開発プラットフォーム SOLID 技術解説書 page 7

インテリジェントローダーは、使用していない空間には物理メモリを割り当てないよう無駄なくメモリを配置し、その配置情報がコアサービス内の MMU 管理機能と連携しているので効率よくメモリが利用できます(図 3-7)。是非この点にも着目して、うまくローダーを利用していただきたいと思います。

図 3-5 DLL 方式のロードでは、アプリ起動時にオーバーヘッドが発生

図 3-7 ローダーが物理空間に効率よく実行モジュールを配置（終）

図 3-6 SOLID インテリジェントローダーを使い、システム初期化時にロード完了
京都マイクロコンピュータは、長年にわたりツールチェーンを含む開発環境をご提供してきたツールベンダーであり、リンカの動作が分かっていたからこそ出来たローダーといえます。また SOLID がツー
ル単体ではなく IDE、ツールチェーン、RTOS、デバッガと一体化した構成であったからこそ、ユーザーがシンプルな手順で利用できるような形で、インテリジェントローダー提供できるようになりました。

MMU と連携しているので、メモリを効率よく利用できるインテリジェントローダーでは、実行モジュールをロードする際に、自動的に MMU を使って論理→物理空間のメモリ配置を行っています。ユーザーは開発途中で再配置／再調整をしなくてもいいよう、論理空間上に余裕を持って実行モジュールを配置すればよく、自由度の高いメモリ配置が可能です。

この記事はこちらからもお読みいただけます。

©2018 京都マイクロコンピュータ株式会社※ 記載の社名・製品名は各社の登録商標または商標です。記載内容は予告なしに変更する場合があります。

ソフトウェア開発プラットフォーム SOLID 技術解説書 page 8
2018.6(第 1 版)