0

arm プラットフォームでは、u-boot は最初に TLB、icache、および BP 配列を無効にしますが、その理由は何ですか? それは必要ですか？

cpu_init_crit:
/*
 * Invalidate L1 I/D
 */
mov r0, #0          @ set up for MCR
mcr p15, 0, r0, c8, c7, 0   @ invalidate TLBs
mcr p15, 0, r0, c7, c5, 0   @ invalidate icache
mcr p15, 0, r0, c7, c5, 6   @ invalidate BP array
mcr     p15, 0, r0, c7, c10, 4  @ DSB
mcr     p15, 0, r0, c7, c5, 4   @ ISB
4

3 に答える 3

1

リセットは、ハードまたはソフトの場合があります。何かがリセットベクターにジャンプする可能性があります。古いエントリでキャッシュが有効になっている場合、コードがクラッシュし、システムが起動しなくなる可能性があります。これは、SDRAM がコールド パワーオン後に誤動作し、クラッシュを引き起こす可能性があるため、考えているよりも一般的です。多くの場合、ウォッチドッグまたは回復不能な障害がリセット ベクターにジャンプします。最後に、XIP NOR フラッシュにu-bootシステムがあるかもしれません。一部のシステム/コードは、このコードにジャンプしてソフト リセットを実行する場合があります。

これらのすべての場合で、利用可能なデバッグはNILです。99.9999% のケースでシステムが動作している可能性があります。ホットバーまたはアイスクリーム冷凍庫でのみ発生する特定のハードウェアでの起動エラーのトラブルシューティングを行う必要がある場合、この余分なコードを楽しむことができます. つまり、それが必要となるまれな状況があります。

電源レールがオンラインになると、ハードウェア障害がより一般的になります。データシートには、範囲内の電力/温度などでシステムが適切に動作することが記載されています。 u-bootは、この理想的な世界では動作しない可能性があります。懸念事項が起動時間である場合は、独自のローダーを作成するか (ただし、このコードは保持してください)、BSS クリアなどを最適化することをお勧めします。

于 2014-01-14T15:27:56.003 に答える
0

これは、リセット時にハードウェアで無効化が行われない場合 (コールドまたはウォーム) に必要です。もう 1 つのより実用的な理由は、通常、U-Boot がハードウェア上で実行される最初のコードではないことです。ほとんどの場合、U-Boot の前に実行される ROM コードが存在し、U-Boot がシステムの制御を取得したときのハードウェアの状態に関する仮定を回避するために、常にハードウェアを既知の状態に戻すことを試みる方が安全です。そこから進みます。

于 2014-01-20T10:23:00.943 に答える
0

A15/A7/A12 では、リセット後にキャッシュ/mmu/btb の無効化を行う必要がないため、これは単に「パラノイア」の理由で行われます。ただし、リセット時に自動無効化を実行しないコアが存在する可能性があるため、このコードは、異なるコア タイプ間で同じ動作が維持されるようにします。

于 2014-01-14T14:43:03.803 に答える