10

私が作成した RTOS/カーネルを実行している 2 コアの ARM 組み込みシステム デバイスがあります。テスト目的でカーネルへの I/O をシミュレートする内部診断ツール/モジュールを作成したいと考えています。明らかに、これは現実世界のテストを完全に置き換えるものではなく、物理的なハードウェア インターフェイスなどすべてを使用します。これはハイパーバイザーに近いと思います。これを行うための方法/概念は何ですか?

4

5 に答える 5

4

私はL4 のマイクロカーネルを使用しており、ハードウェアのアクセス許可は MMU ページとしてマップされています。ARM オプションは、1k、4k、64k ページおよび 1M セクションです。また、Linux の FB deferred I/Oも参照してください。アイデアは、メモリ マップされた 疑似レジスタセットを提供することです。その後、ページ フォールトハンドラーをフォールト アドレスと共に使用して、どの疑似レジスタがヒットしているかを判断できます。指示を見る必要があるかもしれません。たとえば、コードは書き戻しやその他の更新を使用できます。Linuxアライメント ハンドラーコードは、おそらく非常に有益です。

参照: ARM ARM -章 B3 メモリ管理ユニット。
        ARM ARM - 2.6.5 データ アボート (データ アクセス メモリ アボート)。

また、割り込みをシミュレートする必要があります。タイマーを使用して (任意のディストリビューションで)、ドライバー/OS ISR を呼び出すことができます。タイマーの使用を最小限に抑えるために、タイミング ホイールを使用して、割り込み到着のさまざまな確率分布関数を作成できます。FIQ可能であれば、このタイマーを として配置することもできます。IRQこれにより、通常の s がマスクされていても、テスト デバイスの ISR がデータ更新を受信できるようになります。FIQ一定のタイマー割り込みでハンドラーを使用して DMA をエミュレートすることもできます。もちろん、これは、テスト ドライバーが を使用せずFIQ、FIQタイマーを使用できることを前提としています。

特にデバイスが書き込み専用チップの場合、多くの OS ドライバーにはレジスター キャッシュがあります。このコードを見てみるのも役立つかもしれません。

L4を使用すると、特定のセルに実際の物理デバイス範囲の許可が与えられます。これは仮想空間に再配置されます。ハイパーバイザーの追加の問題は、複数の OS を実行していて、さまざまなハードウェア周辺機器のウィンクイン/ウィンクアウトの許可を切り替える必要があることです。私はあなたがこれをしなければならないとは思わない。

警告: マルチ CPU ロックdata faultは、処理に問題がある可能性があります。ドライバーは、複数の CPU を介してハードウェアにアクセスしないでください。ハンドラーは、割り込みをロックして単一の CPU で実行できます。このソリューションは機能します。例外が発生した場合、strexは条件コードを設定して戻ると思います。おそらく、障害ハンドラーでこれを処理できます。

質問とアームタグの言い回しの仕方により、上記の解決策を提案しまし。

Pekkaが指摘しているように、C++ を使用することを選択した場合、これはテスト用の設計に役立つ可能性があります。有用なパターンは、ハードウェアにアクセスするドライバー内の純粋な仮想インターフェイスです。テストするときは、この仮想インターフェイスをシミュレーション クラスに置き換えます。関数ポインターバンドルを使用すると、 「C」でこれを行うこともできます。これらのタイプのアクティビティは十分に文書化されているため、除外しました。ただし、これが探している解決策である場合は、質問を明確にし、タグを付け直すことを検討してください。

于 2013-03-28T14:49:22.670 に答える
3

忠実度 (および労力) を高めるために、次のアプローチを適用できます。

  • 計画されたハードウェアへのソフトウェア API がある場合、シミュレートされた結果で応答するスタブは、一次ソリューションを提供します。
  • ハードウェアがメモリ マップされている場合は、外部ハードウェアであるかのようにメモリを更新するシミュレーション プロセス/スレッドを作成します。
  • 次に、さらに忠実度が必要な場合は、メモリ マップド デバイスのページ フォールトを使用したアートレス ノイズによるアプローチを導入して、シミュレーターを実際の API に対して透過的にし、同期イベント更新を導入することができます。
  • 最後に、システムの外部からハードウェア イン ザ ループ シミュレーションを実行するために、同じインターフェイスをアプリケーションに提供するハードウェアを (場合によってはより多くのソフトウェアを使用して) 構築する方が、手間がかからない可能性があります。これにより、正確なハードウェア インターフェイスが得られますが、複雑さはテストの足場に移動するだけです。
于 2013-03-29T09:19:30.463 に答える
2

RTOS のカーネルとハードウェアの間にハードウェア アブストラクション レイヤー (HAL) がある場合。これは、I/O をシミュレートするための良いポイントになる可能性があります。

どのような種類の HAL レイヤーも持っていない場合、これが実装する理由の 1 つになる可能性があります。HAL には他にも多くの正当な理由があります (こちらを参照)。詳細については、「ハードウェアの抽象化」で Google を検索してください。

ARM デバイスをシミュレートするための ARM エミュレーター (ARMware など) もあります。

于 2013-03-31T21:34:15.053 に答える
0

実行したいテストは、仮想 IO 要求をカーネルに送信するのと似ています。コンセプトはソフトウェアベースの準仮想化に似ていると思います。

ソフトウェア ベースのハイパーバイザーはテスト プログラムです。仮想 IO をカーネルに送信し、カーネルにはこれらの IO 要求を受け入れるための仮想 IO ドライバーが含まれています。

処理後、仮想 IO ドライバーはハイパーバイザーへのハイパーコールを実行して、仮想 IO 信号の状態を警告することもできなければなりません。

于 2013-04-02T03:40:04.860 に答える
-3

RTOS/カーネルに関する情報はありません....しかし、RTOS/カーネルには次のようなものが必要だと思いますioctl。なんで使わないの？

于 2013-03-26T06:24:00.363 に答える