Adeneo EmbeddedによるWindows Embedded CompactでのARM Cortex-A9サポートの最適化 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Windows Embedded Compact での ARM Cortex-A9 サポートの最適化 フリースケール i.MX6 アプリケーション プロセッサ上の Windows Embedded Compact を使用したランダム ハングやその他の問題とその解決方法の説明 By アデネオ組み込みエンジニアリングチーム Rev 1.0、2014 年 11 月 概要 昨年、Adeneo Embeddedは、Freescale i.MX6 Windows Embedded Compact Board Support Packageを使用しているお客様から、ランダムなプロセッサのデッドロックやオペレーティングシステムのクラッシュの報告を受けてきました。 デバイスを包括的にテストしているときにランダムなハングやその他の問題が表面化しました、つまり、通常のCTKテストに合格しても、エラーの発生は引き出されませんでした。 アデネオのシニアエンジニアの専任チームは、多くの主要なお客様と協力して、全面的に問題を分析し、解決しました。最新バージョンのAdeneo i.MX6 Windows Embedded Compact (7および2013) BSPにより、これが達成されたと確信しています。 このホワイトペーパーは、調査についてであり、私たちの発見の一部を共有しています。このドキュメントのすべての情報は、Windows Embedded Compact 7 と 2013、および i.MX6 のすべてのバリエーションに適用されます。 調査の形式 現場からの問題報告に基づいて、システム内の単一のコンポーネントを原因として特定することは複雑であったため、状況を調査するために正式かつ広範なプロセスを使用することにしました。 BSPコード、Microsoftカーネルコード、および顧客アプリケーションコードについて、正式なコードレビューが行われました。 Lauterbach JTAGハードウェアデバッガは、クラッシュ時に利用可能なすべてのプロセッサデータをキャプチャするために使用されました。 Microsoftのカーネルチームは、Windows CEカーネルに関するすべての質問を支援しました。 お客様のエンジニアリングチームは、アプリケーションに関する特定の知識を持ち、問題をより簡単に再現するためのテストアプリケーションを開発しました フリースケールのサポート・エンジニアは、シリコンに関するあらゆる質問にお答えします。 Adeneoのエンジニアは、BSPを地上から再設計し、i.MX6およびCortex-A9アーキテクチャに最適化しました 要約すると、複数の企業のコラボレーション、そしてさらに重要なことに、独自の付加価値を持つ献身的な個人の多様なグループが、この複雑な問題の解決策を開発するための包括的な技術的カバレッジを提供しました i.MX6 BSPの歴史 i.MX6 Windows Embedded Compact BSPの出発点は、i.MX5xシリーズからi.MX2xシリーズまで、フリースケールの他のアプリケーションプロセッサ用の初期のBSPでした。OS 側では、履歴は Windows CE 5 にまでさかのぼります。 フリースケールのアプリケーション・プロセッサの良いところは、さまざまなプロセッサ間で周辺IPブロックを共有するため、開発者は多くのコードを共有して再利用できることです。これは、BSP を新しい i.MX6 SoC で機能させ、プロジェクトを開始するのに、最初は非常に役立ちました。ただし、マルチコアCortex-A9アーキテクチャを備えたi.MX6は、シングルコアCortex A8またはARM9 CPU用に設計されたコードを再利用するのが困難です。 特に、キャッシュ管理、マルチコアサポート、メモリ構成は、既存のCortex-A8およびARM9コードが最初に有効にすることができた領域でしたが、その後の長期安定性テストで失敗しました。 Cortex-A9アーキテクチャ フリースケールのi.MX6アプリケーション・プロセッサは、ARM Cortex-A9およびARMv7命令セット・アーキテクチャの実装です。この強力なアーキテクチャは、処理パフォーマンスを向上させるための多くの機能を提供しますが、システムソフトウェアの開発には特別な注意が必要です。 i.MX6は、Windows Embedded Compactの対称型マルチプロセッシング構成で最大4つのコアを提供します。 調査中に対処された安定性に影響を与える機能には、次のようなものがあります。 投機的な負荷と実行 投機的なテーブルウォーク 分岐予測 アウトオブオーダーの実行と命令の並べ替え パラレル内部バス 複数の内部バッファとキャッシュ マルチコア コヒーレンシ L1/L2 キャッシュ操作 Abort handling コード レビューの一環として、これらの機能を正しく構成し、適切に活用するための既存のコードの欠点を特定しました。すべてのコードは ARM アーキテクチャのドキュメントで検証され、ARM の最新の推奨事項に従って更新されました。フリースケールのエンジニアは、ARMのドキュメントが曖昧な実装の詳細を理解するのに役立ちました。これは、機能の実装方法がシリコンベンダーにある程度の自由を残しているためです。 Freescale、ARM、その他のIPベンダーからのすべてのエラッタ・ドキュメントがレビューされ、適用可能なすべての修正または回避策がBSPまたはカーネル・コードに実装されていることを確認しました。 お客様との話し合いの結果、パフォーマンスを損なうことなく安定性に重点を置いたi.MX6プロセッサの良好な動作構成を決定しました。 マルチコア構成では、同じ構成で使用可能なすべてのコアを常に動作させるようにコードを更新しました。重要な領域は、低電力状態から復帰したときに同じ設定を再適用するための電源管理コードでした。 メモリ・コンフィグレーション Cortex-A9は、デバイスを複数のモードで動作させ、アプリケーションプロセスを相互に分離し、保護とセキュリティのレイヤーを提供する仮想メモリシステムを実装することを可能にする強力なメモリ管理ユニットを提供します。 メモリ空間を見ると、このアーキテクチャにはいくつかのタイプのメモリがあります。私たちは以下の点に重点を置きました。 正常なメモリ デバイスメモリ ARMアーキテクチャは、メモリアドレス空間とI / Oアドレス空間があるx86アーキテクチャと比較して、フラットな統合メモリアドレス空間を持っています。これは、すべてのペリフェラルレジスタとその他のI/Oアドレスが、RAMとROM(メモリマップドI/O)とともに同じアドレス空間にマップされることを意味します。デフォルトでは、これは新しいものではなく、ソフトウェアおよびハードウェアの開発者にとって物事を容易にするため、悪い設計ではありません。以前のバージョンの Windows CE およびその他の OS では、すべてのアドレスが通常のメモリとして扱われ、RAM と I/O の唯一の違いは、I/O のメモリ プロパティで非キャッシュ フラグを設定することでした。Cortex-A8までのアーキテクチャでは、システムの安定した動作を確保するにはこれで十分でした。 特にCortex-A9の投機的エンジンでは、従来のアプローチが問題を引き起こします。コアの一部の投機的機能を無効にすることができますが、投機的テーブルウォーク (暗黙的に投機的ロードを行う) は、ノーマル メモリでは無効にできません。そのため、Cortex-A9では、アーキテクチャの拡張アクセス許可機能を使用し、すべてのI/Oメモリをデバイスメモリとして構成する必要があります。とりわけ、デバイスメモリには、そのプロパティ(XNフラグ)に実行なしフラグが設定されており、プロセッサは投機的な操作中にそれに触れません。負荷が高く、ストレスがかかると、プロセッサが時間ごとにより多くの投機的な操作を行い、I/Oに触れる機会が増えるため、これが問題になります。これは、クラッシュやデッドロックの主な理由の1つでした。 Windows CE の場合、Microsoft は Compact 7 を使用して、OEM が使用可能なメモリをカーネルに報告する新しい方法を導入しました。ただし、上記の問題は x86 および古い ARM アーキテクチャでは問題ではないため、i.MX6 BSP は古いレポート スタイルを先祖から継承しています。 レガシ メモリのレポートを使用して、OEM はメモリ マッピング テーブルに使用可能なメモリに関する情報を入力し、起動時にそれを CE カーネルに提供します。次に、カーネルは、OEM からのメモリ ブロックごとにキャッシュされたエントリとキャッシュされていないエントリを含む初期 MMU ページ テーブルを作成します。MMUにとって、すべてが正常なメモリです。 新しいWEC7モデルは、RAMとROM用の古いテーブルとI / O(デバイステーブル)用の新しいテーブルの2つのテーブルで動作します。デバイス テーブル内のすべてのブロックは、MMU でデバイス メモリとしてコンフィギュレーションされ、保護されます。 これは簡単に聞こえますが、悪魔は細部に宿っています。新しいモデルでは、初期ブート フェーズで BSP コードがアドレス変換を使用する方法が変更されます。新しいモデルで動作し、ブートローダーコードからOALコードへのパラメーター転送を可能にするために、スタートアップコードとKITLコンポーネントの機能を更新する必要がありました。また、十分に文書化されておらず、カーネル コードのレビューと Microsoft カーネル エンジニアとの話し合いにより、コードのこの部分を微調整して i.MX6 用に最適化する必要があります。もう1つの問題は、i.MX6の内部SRAMであり、これは最初にプロセッサのI/Oスペースの一部として表示されるため、デバイステーブルに配置されることになりました。ただし、内部 RAM は低電力モードで使用されるため、外部 RAM が自己リフレッシュされている間に電源管理コードが実行されるため、XN フラグを設定せずに通常のメモリとしてマップする必要があります。結局のところ、それは些細な仕事ではありませんでした。 同期バリア Cortex-A9の前述の拡張機能により、プロセッサとすべてのメモリが既知の状態を持ち、同期している同期ポイントを操作フローに設定する必要があります。これは、プロセッサ構成を更新する場合や OS のコンテキスト スイッチ中に特に重要です。 OAL とカーネル コードのコード レビューと Microsoft との話し合いを通じて、すべての ARM 要件を満たすように BSP を更新し、カーネルと OAL 間のインターフェイスを微調整して最適なパフォーマンスを提供しました。 Errata 調査中、i.MX6 とそのさまざまな IP ブロックのエラッタ作成に時間を費やしました。BSP とカーネル コードは、各エラータについて集中的にレビューされ、影響を受ける場合は修正または回避策を実装する必要があります。 その一環として、i.MX6 に実装されたすべてのソフトウェア BSP (Freescale 製) とその変更ログも確認し、見落としがないことを再確認しました。 いくつかの重要な正誤表がコードに欠落していると特定され、調査中に実装されました。必要なコード変更のうち 3 つは Microsoft カーネル コードにあり、カーネルの更新が必要でした。Adeneo Embeddedは、これらの変更をカーネルに実装し、更新されたカーネルをテストラボおよび現場の選ばれたお客様にテストした後、カーネルの変更リクエストをMicrosoftに提出し、Windows Embedded Updateメカニズムを通じてアップデートを正式にリリースしました。 キャッシュ管理 i.MX6は、内部L1データおよび命令キャッシュと外部L2統合キャッシュを備えたCortex-A9アーキテクチャを実装しています。内部L1は、L1 RAMアレイがARM MPCore IPブロック内にあり、MPクラスタ内の各Cortex-A9コアが独自のL1キャッシュを持つことを意味します。外部 L2 は、L2 RAM アレイが ARM MPCore IP ブロックの外側にあり、SoC の内側にあり、内部 AXI バスに接続されていることを意味します。どちらの RAM アレイにも、プロセッサのロード/ストア命令からアクセスできません。 キャッシュメモリを使用すると、システムは頻繁に使用するデータをメモリに保持し、より高速にアクセスできますが、これには、プロセッサキャッシュブロックの外部のオブザーバがデータの変更を確認できるように、キャッシュメモリと外部SDRAMを同期する必要があります。 SMP クラスタとして設定すると、必要な L1 メンテナンスの一部がハードウェア キャッシュ コントローラによって行われます。それぞれが独自のL1キャッシュを持つ最大4つのコアと、コンテキストスイッチのために同じ実行スレッドを異なるコアに割り当てる可能性のあるマルチタスクオペレーティングシステムがある場合があるため、すべてのコアがメモリの同じ同期ビューを持つ必要があります。これは、単一のアドレスが影響を受ける限り、MPCoreのコヒーレンシユニットを介してハードウェアで行われます。L1のメンテナンスが必要な場合は、ソフトウェア全体で対応する必要があります。 また、ソフトウェアはすべての L2 キャッシュ メンテナンス操作を処理する必要があります。 キャッシュのメンテナンスは、通常、カーネルによって呼び出されますが、デバイスドライバやアプリケーションソフトウェアでさえもキャッシュのメンテナンスを要求しなければならない状況がいくつかあります。いずれにせよ、OAL はこれらの要求を取得して実行します。OAL のすべてのキャッシュ関連コードは、ARM アーキテクチャの要件を満たし、カーネルと最適化された方法で連携するように更新および再設計されました。欠点:キャッシュでのCortex-A9のサポート、メンテナンスコード、およびドライバーからのメンテナンスリクエストも、初期のBSPで不安定な問題の主な原因でした。 この領域の複雑さのいくつかは次のとおりです。 L1 コードを最適化して、利用可能なハードウェア サポートを活用 L1 と L2 を含むメンテナンス要求では、すべてのメモリ レベルが同期していることを確認するための特定の手順が必要です メンテナンス要求は、複数のスレッドとCPUから並行して送信される可能性があり、L2コードはリエントラントでマルチコアセーフである必要があります DMA コントローラーは物理アドレスで動作し、キャッシュについては認識しません。DMA 操作を使用する場合、ドライバーは必要なキャッシュ メンテナンスを要求する必要があります。USB、SD、およびビデオ操作の不安定性は、この領域のバグに関連していました。 ビルドとテスト この調査の冒頭で、CTK BSPテストではこれらの問題を特定できなかったことがわかったため、テストアプローチを見直し、改善された手順を実施しました。私たちのテストの新しいコンポーネントは安定性ラボであり、タスクを自動化し、結果を記録するためのITインフラストラクチャとともに専用のハードウェアセットを提供します。主要なお客様からの承認を得て、お客様のテストアプリケーションと問題の再現に役立つアプリケーションを、より汎用的なテストアプリケーションに移行し、ポートフォリオに追加しました。 また、お客様のユースケースに関する知識が重要であることも学びました。私たちは、実際のシナリオにより近いものにするためにテストを再構築し、お客様からのフィードバックを直接統合しました。 調査中に、ビルドプロセスまたはツールが一部の問題の根本原因である可能性があるという懸念が何度も提起されました。テストチームは、OSイメージがどこでどのように構築されたかに基づいて、異なる結果を報告しました。ツールのインストールと更新のプロセス、およびMicrosoftのOSバグ修正をインストールするプロセスを分析しましたが、これらの観察結果は赤ニシンであるという結論に達しました。しかし、この調査部分から得られた知識を、Adeneo Embeddedのビルドラボの改善に活かしました。インフラストラクチャを強化し、ツールをアップグレードして、Windows Embedded Compact と BSP のバージョンと QFE レベルを簡単に切り替えられるようにしました。 コミットメント この調査は約8ヶ月の期間にわたって行われ、Adeneo Embeddedは問題解決に全力を尽くしました。エンジニアのコアチームがフルタイムで作業し、必要に応じて拡張されたエンジニアグループがサポート(テスト、ビルド、デバッグ、アプリケーション,..)に対応しました。ここで解決しなければならなかった問題は些細なことではありませんでした。時には、ジェットコースターに乗っているような感覚でした。 しかし、その結果、Adeneo EmbeddedのFreescale i.MX6 Windows Embedded Compactボード・サポート・パッケージは、品質が大幅に向上し、このシステム・オン・チップに最適化されています。これにより、Windows Embedded Compact i.MX6 を実行しているすべてのお客様、および将来の CPU アーキテクチャを WEC7 および WEC2013 の同様の ARM コアで実行するお客様にメリットをもたらします。 詳細については、
[email protected] のAdeneo組み込みサポートチームに電子メールを送信するか 、 当社のWebサイトをご覧ください http://www.adeneo-embedded.com/ 全般
