4

Ubootブートローダーに取り組んでいます。ブートローダーの機能とそれが処理するアプリケーションについて、いくつかの基本的な質問があります。

Q1：私の知る限り、ブートローダーはアプリケーションをメモリにダウンロードするために使用されます。インターネットを介して、ブートローダーがアプリケーションをRAMにコピーし、アプリケーションがRAMから実行されることもわかりました。ブートローダーの動作と混同しています...アプリケーションがシリアルまたはTFTPを介してブートローダーに提供された場合、次に何が起こりますか、ブートローダーが最初にRAMにコピーするか、フラッシュに直接書き込むか。

Q2：ブートローダーがアプリケーションをRAMにコピーしてから、RAMからアプリケーションを実行する必要があるのはなぜですか？アプリケーションをFLASHから実行すると、どのような問題が発生しますか？

Q3：「アプリケーションはRAM / FLASHから実行されています」というステートメントの意味は何ですか？アプリケーションの.textセグメントまたは.codeセグメントがRAM/FLASHにあるということですか？また、RAM内にあるように設計されているため、.bssセクションについては気にしません。

ありがとうPhogat

4

4 に答える 4

4

ハードウェアシステムを設計する場合、設計者は実行可能コードを配置する場所を検討する必要があります。答えは、マイクロコントローラ、含まれているメモリタイプ、およびシステム要件によって異なります。したがって、答えはシステムごとに異なります。一部のシステムは、RAMにあるコードを実行します。他のシステムは、フラッシュにあるコードを実行します。システムが何をするように設計されているかを知るために、システムについて十分に教えてくれませんでした。

RAMのアクセス時間はフラッシュよりも速く、コードの実行速度が速いため、システムはRAMからコードを実行するように設計されている場合があります。フラッシュは豊富でRAMは豊富ではないため、システムはフラッシュからコードを実行するように設計されている可能性があります。システムは、フラッシュからコードを実行して、より高速に起動するように設計されている場合があります。これらはほんの一例であり、他の考慮事項もあります。

RAMは揮発性であるため、電源を入れ直してもコードは保持されません。システムがRAMにあるコードを実行する場合、電源投入時にコードを取得してRAMに書き込むためにブートローダーが必要です。フラッシュは不揮発性であるため、電源投入時にすぐに実行を開始でき、ブートローダーは必要ありません（ただし、それでも役立つ場合があります）。

Q3に関しては、答えはイエスです。システムがRAMから実行されている場合、.textはRAMに配置されます（ただし、ブートローダーがRAMにコピーするまでは配置されません）。システムがフラッシュから実行されている場合、.textセクションはフラッシュに配置されます。.bssセクションは変数であり、.textセクションがどこにあるかに関係なくRAMにあります。

于 2013-03-15T16:08:25.880 に答える
3

はい、通常、ブートローダーはシステムを起動しますが、デフォルトの起動パスを中断し、代わりに代替ファームウェアをダウンロードして実行できるようにするメカニズムや、その他の機能（フラッシュなど）も提供する場合があります。

従来のROMには、インターフェイス、アドレス、データ、チップセレクト、読み取り/書き込みなどの従来のRAMがありました。その方法でROMを購入することもできますが、ピンの不動産の観点からは、spiまたはi2cベースのものを使用する方が安価です。遅いです。実行するのは望ましくありませんが、一度読んでからRAMから実行することは許容できます。新しいフラッシュテクノロジーでは、読み取り妨害の問題が発生する可能性があります。コードが同じ命令を読み取るタイトなループにある場合、またはその他の理由でフラッシュの読み取りが速すぎる場合、充電が低下して読み取りが間違った値を返す可能性があります。データ、プログラムがコースを変更したりクラッシュしたりする可能性があります。また、PCやその他のLinuxプラットフォームは、カーネルをNVストレージ（ハードディスク）からRAMにコピーしてから実行するために使用されるため、フラッシュからRAMにコピーして、RAMから実行するのは快適なレベルです。多くの場合、フラッシュよりも高速です。したがって、フラッシュを使用しない理由はたくさんありますが、システムによっては、フラッシュから正常に実行できる場合があります（問題のフラッシュに直接アクセスできず、実行できないシステムもあります。もちろん、そのシステムの一部のROMでは実行可能/起動可能）。

RAM内にあるものを使用してフラッシュをプログラムする場合は、コーディングの課題が単純化されます。ramから読み取り、フラッシュに書き込み、フラッシュから読み取り、ramに書き込むコードを一度作成してデバッグできます。終わり。これで、シリアルからRAMに、またはRAMからシリアルにデータを受信する個別のコードで作業できます。終わり。次に、イーサネットやUSBなどで同じことを行うコードで作業します。プロトコルの発明やタイミングの問題の解決に取り組む必要はありません。フラッシュの書き込みは非常に遅く、中程度の速度のxmodemでも速すぎる可能性があるため、xmodemやその他のシリアルベースのフラッシュローダーの代わりに、そのデータをRAMにバッファリングする必要があり、タスクを完全に分離することもできます。大きなRAMベースのFIFOを使用する場合は、データをRAMに移動してから、RAMからフラッシュに個別に移動します。他のインターフェースについても同じです。データをバッファリングして、ダウンロードインターフェイスからフラッシュに直接移行するような錯覚を与えることは技術的に可能です。プロトコルによっては、プログラミング前にRAMに必要なフラッシュページが1つだけになるように、送信者を遠ざけることが技術的に可能です。閃光。古いパラレルフラッシュを使用すると、ほとんどの人が理解しているとは思わない、かなりクールなことを行うことができます。フラッシュページへの書き込みを既知の期間停止すると、フラッシュは自動的にそのページのプログラムを開始し、完了するまでに10ミリ秒など待機する必要があります。人々が想定したのは、シーケンシャルアドレスをプログラムし、その期間内に次のアドレスの新しいデータを取得する必要があり、高いシリアルポート速度などを要求するということでした。現実には、同じデータで同じアドレスを何度も叩くことができ、フラッシュはページのプログラムを開始せず、ダウンロードインターフェイスは無限に遅くなる可能性があります。シリアルフラッシュの動作は異なり、トリックを必要としないか、トリックが異なります。

RAM/FLASHは業界用語ではありません。.textがROM（フラッシュ）にあり、.dataと.bssがRAMにあることを意味している可能性があります。.dataの初期状態のコピーもおそらくフラッシュ上にあり、main（）が呼び出される前にramにコピーされます。同様に、main（）が呼び出される前に.bssがゼロになります。gnuソース（glibc、またはgcc、私にはわかりません）のほとんどのプラットフォームのcrt0.Sを見て、ブートストラップが一般的な方法でどのように機能するかについての要点を理解してください。

Linuxやその他のオペレーティングシステムを実行するためにブートローダーは必要ありません。ubootは必要ありませんが、非常に便利です。Linuxは非常に簡単です。カーネルとルートファイルシステムをコピーし、メモリにレジスタまたはタグを設定するか、両方を設定してから、カーネルのエントリポイントに分岐すると、Linuxがそこから引き継ぎます。Linuxは非常に複雑であるため、イーサネットなどの高速インターフェイスを利用できる複雑なブートローダーが必要です（シリアルまたは低速に制限されるのではありません）。

于 2013-03-15T15:17:56.850 に答える
2

Q2あなたの質問について何か付け加えたいと思います。

Q2：ブートローダーがアプリケーションをRAMにコピーしてから、RAMからアプリケーションを実行する必要があるのはなぜですか？アプリケーションをFLASHから実行すると、どのような問題が発生しますか？

それは、SPIまたは同様のシリアル外部コードメモリを持っていることだけではありません（とにかくそれほど頻繁ではありません）。

通常の高速パラレルバスに接続された外部ROM/FLASH / EPROM /でさえ、外部メモリアクセス時間のために比較的遅いMCUでもシステムが最大クロック（ゼロ待機状態）で動作するのを防ぎます。100MHzクロックには10nsのFLASHアクセス時間が必要ですが、これを取得するのはそれほど簡単ではありません（経済的に可能であれば）。そして、あなたは100MHzがもはやそのような脳の回転速度ではないことに同意するでしょう:-)

そのため、多くのMCU / CPUアーキテクチャは、乗算命令を一度に読み取る、内部キャッシュを使用する、または低速の外部コードメモリを補うために必要なことをすべて実行するというトリックを実行しています。ほとんどの古い8ビットアーキテクチャのみが、フラッシュメモリから直接コードを実行できます（「インプレース」）。

コードメモリが内部フラッシュだけだったとしても、それを高速化するために何かをする必要があります。この記事を例にとってみましょう。

http://www.iqmagazineonline.com/magazine/pdf/v_3_2_pdf/pg14-15-18-19-9Q6Phillips-Z.pdf

ARM7がMAM（Memory Accelerator Module）と呼ばれるものをどのように組み込んだかを説明しています。これは良い読み物であり、特定のARM7アーキテクチャのコードメモリアクセスを高速化するためのいくつかの手段があります（他のほとんどの場合に使用されます）。

  1. 最大クロック周波数を制限します（記事の例では80MHzから約20MHzまで）
  2. フラッシュアクセス中に待機サイクルを挿入する
  3. 命令キャッシュを使用する
  4. プログラムコードをフラッシュからRAMにコピーします

明らかに、命令キャッシュがオプションではなかった場合（小さすぎる、またはクロックが高すぎる）、起動時にコードを再配置した後、RAMからの実行のみが実際に残されます。

リンカに指定できるRAMからコードの特定のセクションのみを実行するオプションもあります。DSP（Digital System Processing）システムの場合、EPROM / FLASHから実行するオプションは、今では言うまでもなく、クロックが数十MHz程度の昔でも実際にはありませんでした。

もう1つの問題はデバッグです。ROMまたはFlashに配置されたコードをデバッグするためのオプションは非常に限られています（ほとんどのシステムでブレークポイントを設定できるようにするには、コードのセクションをRAMに移動する必要があります）。

于 2013-03-15T16:23:11.130 に答える
2

Q2に関して、Flashから実行する際に直面する可能性のある問題の1つは、別のコード更新です。更新しようとしているFlashの同じブロックから実行している場合、システムはクラッシュします。これは、システムアーキテクチャ（アプリケーションとブートローダーがFlashでどのように編成されているか）によって異なりますが、ブートローダー自体を更新しようとしている場合は、特に回避するのが難しい場合があります。

于 2013-03-15T16:24:13.113 に答える