网上说明一大堆，基本是官网文档复制没有额外解释！
对于ESP32-C3的 risc-v 内核，是我选择他的原因之一，
了解芯片上电后的启动流程，有利于我们更加深入理解芯片。
コンテンツ
序文
ARMコアのSTM32起動プロセスについては、以前のブログ投稿で詳細に分析しました。STM32起動プロセスを理解することは、チップの使用と理解のためのより高いレベルになります。これで、risc-vコアを備えたESP32-C3を初めて使用できます。その起動プロセスを理解できれば、ESP32-C3をより深く理解できます。
記事を書く前に、インターネットでたくさんの記事を読んだ後、公式の説明も読んでいます。インターネット上のほとんどの文書は公式ウェブサイトからコピーされています。これは何もありません。結局のところ、公式ウェブサイトは説明、追加の分析はありませんが、オリジナルを書くこともできます。私は本当にXXです。もちろん、見たことのない良い記事を除外するわけではありませんが、それは、より詳細な分析を見たことがないからです。自分でレコードを書くことにしました。まず、それを次のように使用します。私自身の記録第二に、私が実際にやっているところがいくつかあります。それは完全な理解ではなく、場所にない場所もあるに違いありません。記事をより完璧にするためにもっと意見を述べていただければ幸いです。 。
いつものように、私は何度も見つけることができる記事や公式資料を読みました。公式が言及した3つのステップは次のとおりです。
上記の3つの主要なステップの場合、最も単純で明確なのは3番目のステップです。2番目のステップにもソースコードがありますが、それを確認して分析することはできますが、最初のステップは正しいので、何が起こっているかを知ってください。 。具体的な実装方法は、プログラムがESP32-C3の内部ROMにあり、分析可能なソースコードやデータが見つからないためです。
チップの起動プロセスは、ほとんどの場合、起動ファイルとリンクファイルから切り離せません。ESP32-C3についても同じことが言えます。元々、私の理解によれば、基になるスタートアップファイルと接続ファイルを見つけて、手順に従って分析を開始する必要がありますが、基になるコードをしばらくチェックしました。基盤となるアーキテクチャについて十分に理解しておらず、私はそれを見つけられませんでした= =！それで、何をすべきかを考えていますか？
最初から最後まで順番に来て、最後から最初まで順番に来ることはできません！app_mainネットワークの前にある関数をレイヤーごとに見て、プログラムがapp_main関数を実行する前に何が処理されたかを見てみましょう。
記事はフラッシュバックで説明されていることに注意してください~~
この記事は、VScodeプラグイン（Ubuntu環境）のエンジニアリング構造に基づいています。環境のセットアップについては、次のブログ投稿を参照してください。
ESP32-C3 VScode開発環境が構築されています（Espressifの公式ESP-IDF-WindowsとUbuntuのデュアル環境に基づいています）
まず、アプリケーションの起動フェーズ
1.1 app_main.c
app_main.cメイン関数からapp_main、次の定義に移動して、前のレベルに直接移動します。
1.2 port_common.c
app_mainが検索するファイルは、port_common.c次のパスです。
どのタスクが呼び出されますかapp_main。すぐ上に表示され、呼び出し
main_taskますapp_main。このタスクは関数で作成されます。関数がこのタスクを作成することを知っている場合、この関数はどこで呼び出されますか？関数内で呼び出しを検索して見つけます。呼び出しが完了すると、FreeRTOSタスクのスケジューリングがオンになります。main_taskesp_startup_start_app_common
esp_startup_start_app_commonmain_taskesp_startup_start_appesp_startup_start_app_common
これに対応して、スタートアップログを見てみましょう。
1.3 port.c
新しいファイルを再度入力しましport.cた。パスは次のとおりです。
次に、上記のようにesp_startup_start_app、関数から検索して、図に示すように
別の関数を見つけます。start_cpu0_default
1.4 startup.c
startup.c次のパスで新しいファイルが見つかりました： start_cpu0_default
startup.cファイルの機能ではstart_cpu0_default、多くの重要なステップが実行され、コードを自分で確認できます。
これに対応して、起動ログを見てみましょう。
start_cpu0_default関数がどこから呼び出されているかも確認したいのですが、現時点ではジャンプできません。現時点startup.cでは、ファイルを検索しているところ、次の文が見つかります。
この文の意味は次のようになります。関数が関数と同等であるという追加の宣言がない場合、関数は関数にstart_cpu0_default弱く接続されています。（エラーを指摘してください）start_cpu0start_cpu0_defaultstart_cpu0
start_cpu0関数に関連するプログラムを引き続き見てください、g_startup_fnそれは配列のようですか？図に示すように、「の定義に移動」
をg_startup_fn使用、別の新しいファイルを入力して、マクロ定義を見つけることができSYS_STARTUP_FN()ます。
1.5 startup_internal.h
ファイルパスの古い見方は次のとおりです。
これはヘッダーファイルであるため、関数宣言とマクロ定義が必要です。このファイルで注意する必要があるのはマクロ定義#define SYS_STARTUP_FN() ((*g_startup_fn[(cpu_hal_get_core_id())])())です。
次に見つける必要があるのは、マクロ定義SYS_STARTUP_FN()が呼び出される場所です。
ヘッダーファイルであるため、関数呼び出しを見つけるのは少し複雑ですが、大きな問題ではありません
。次に、上位ディレクトリを使用します。これは、基盤となるソースコードを確認するための基本的な方法でもあります。
1.6 cpu_start.c
ファイルパスの古い見方は次
のとおりです。cpu_start.cファイルでは、上記のヘッダーファイルのマクロ定義への呼び出しが実際にあることがわかりますSYS_STARTUP_FN()。これらは主にCPUを起動するいくつかの関数で
あり、その中でcall_start_cpu0関数はこのマクロの定義：
関数の内容はたくさんありますはい、ここではそれらを1つずつ分析しません。しかし、ここで、公式ドキュメントと組み合わせてもう一度見てみましょう。
このように理解すると、公式ステートメントは非常に単純であるように感じますが、実際にはレイヤーバイレイヤーと呼ばれています。
分析のこの時点で、私たちはすべてエントリ関数に入ったので、プログラムはどのように呼び出されますか。以前の理解によると、このエントリ関数は、次のような接続スクリプトでENTRY呼び出す。ENTRY(call_start_cpu0);
実際、フォルダ検索に行ってファイルが多いことがわかったENTRY(call_start_cpu0);場合、ESP32-C3に関連するものを選択しても、場所は異なりますが、どれですか。私たちは道をたどり続けなければなりません！
1.7 esp32c3.project.ld.in
コンポーネントesp32c3のディレクトリの下call_start_cpu0を検索し、使用されているENTRY(call_start_cpu0);リンクファイルを見つけます:(エラーがある場合は指摘してください）
これは、エントリ関数の実行を開始するSTM32の分析に似ています。
ファイルパス：
また、セカンダリブートローダーを見下ろす必要があります。
次に、セカンダリブートプログラム
私の現在の理解に基づくと、第2レベルのブートローダーは、完全に明確にするのに十分ではありません。公式は、ソースコードがESP-IDFのcomponents / bootloaderディレクトリにあると述べています。」プログラム：
このbootloader_start.cファイルでは、公式の指示として、ESP-IDFは、第2レベルのブートプログラムを使用して、Flashパーティション（パーティションテーブルを使用）およびその他の機能の柔軟性を高めます。
引き続きいくつかのコードをチェックし（具体的には、bootloader_start.cファイル内の関連する場所を検索します）、bootloader_start.cそれがLOG出力==！に従って判断されたセカンダリブートストラッププログラムのコード
ブートローダーディレクトリにはESP32-C3のリンクファイルもあります。呼び出し
もENTRY(call_start_cpu0);あります。これはbootloader_start.c、第2レベルのブートローダーに対応するリンクファイルである必要があります（問題を明確に指摘します）。
エピローグ
この記事は、C言語のスタートアップの前の部分で非常に満足のいくものです。最下層の後、なじみのないrisc-vカーネルとアーキテクチャーはまだあいまいな状態です。私の友人がもっと意見を述べてくれることを願っています。
記事全体はコードのプロセス分析としか見なせず、機能を分析する機能はありません。これは私が満足していないことです。3フィートの凍結は1日の寒さではありません、さあ！
ブロガーの理解が深まるにつれて記事が更新されますので、今後はメモリやアーキテクチャから記事を改善していきたいと思います！