Linux/組み込みLinux - カーネルお​​よび他のBSP固有のコンポーネントについて[閉じる]

*長すぎる。私はLinux / Embedded Linuxの世界がどのように機能するのかを概説したいと思います。メインラインLinuxを使用して最初から始めて、それを他のプロセッサと周辺機器があるマザーボードにコンパイル/デプロイするにはどうすればよいですか？

現在の動作方法は次のとおりです。

すべてのボードでLinuxを実行する手順：

• uBoot（組み込み）またはGRUB（デスクトップ/ x86 SOM）用のソースコードを入手する
• 特定のシステムに合わせてuBootまたはGRUBを変更し、特定のチップを初期化し、起動と実行に必要なメモリとコンソールインターフェイスを取得するコードを記述します。
• 上記のコードを設定するには、uBoot / GRUB config.txtを修正してください。
• これをコンパイルしてボードにデプロイし、ブートローダコンソールが表示され、対話できることを確認します。
• カーネルメインラインソースの取得
• "make config"を使用して利用可能なドライバとモジュールを選択します（この時点でこれらの選択はソースを変更します。これらの設定が保存されている場所に関係なく、メインラインのgit cloneと一致しません）（これをソース管理 .config ファイルで追跡) 今後の注意)
• Busyboxなどのツールを入手するか、デスクトップを置き換えますか？ソースディレクトリへのインストール
• ucLibcまたは他のライブラリをインポートし、ソースディレクトリにインストールします。
• クロスコンパイルツールチェーンを使用した特定のチップのカーネルソースコードのコンパイル
• ボードのデバイスツリーファイル.dtbを作成します（埋め込み/デスクトップ？またはデスクトップは使用されませんか？）。これにより、ドライバが物理ピンに接続されます。
• Uboot / GRUBおよびTFTP /シリアルコンソールまたはメモリカードを使用してコンパイルされたカーネルイメージをロードします。
• ドライバとデバイスツリー構成に基づいてシリアル/SSHなどを介してシェルアクセスを実行および確認する
• ボード固有の構成のためにuEnv.txt（組み込み）またはmymyfile.txt（デスクトップ）を変更しますか？これは本質的にカーネルブートステップをブロックまたは追加するスクリプトですか？デスクトップと同等のものは何ですか？
• apt-get 必須パッケージとドライバ
• ドライバとアプリケーションコードの作成とテスト（ドライバの手動ロード）
• 上記で実装されたハードウェアとドライバを記述するデバイスツリーファイルを追加します（このファイルは、生成された初期BSPとは別のものです）。
• これをカーネルイメージに含めるには、カーネルをビルドし、これらのすべてのソースファイルと設定ファイルの変更（Linuxのメインラインの追加と修正）を含むファイル構造をフォルダ構造に含めます。
• Linuxのメインラインとモード用に別々のフォルダを作成し、モードを3番目のステージングフォルダのメインラインに直接コピーできます。これにより、追加されたすべてのコンテンツとメインライン以外のモードの個別のソース管理が可能になります。

SSH経由で接続できる基本システムを入手でき、この時点ですべての共通コンポーネント（ビデオ、USB、マウスなど）のドライバがある場合は、この時点でほぼすべての作業を実行できます（X11サーバーのインストール）。 、LXDE、ネットワーク待機）？ブートローダ/BIOSで処理する必要があるドライバは何ですか？カーネルドメインにのみあるドライバは何ですか？

カーネルビルドを構成するためのKconfigファイルがあります。これは妥当であり、私が見たカーネルモジュール開発文書はこれについてかなりよく説明しているようです。

ランタイム構成とロードする必要があるデバイスを処理するuEnv.txtやconfig.txtなどのファイルもあります。そして、デバイスツリーブロブはどのデバイスをロードするべきかを決定しますか？

このファイルのマジック文字列はどのようにカーネルに接続されており、特定のボードのメインラインでこれらの修正が行われましたか？ HDMIを有効にする必要があるかどうかを判断するには、それを読む必要があります。これは、Linuxデスクトップバージョンのコードとまったく同じではない可能性があります。

ドライバがメインラインに入った後も、まだメインラインとは独立して開発されていますか？たとえば、私が使ってきたいくつかのドライバがありますが、今メインラインに含まれているというメモがあります。これはもはや直接ダウンロードできないという意味ですか？私が行ったステップでは、私のボードのヘッダーとソースコードをダウンロードしてコンパイルしてインストールしました。メインラインにいる場合は、今そこから抽出する必要がありますか？

背景と具体的なアイデア

私はマイクロコントローラとWindowsの開発経験があるEEですが、Linuxの経験はあまりありません。私の質問の枠組みは、「このランダム（Linuxコンパイラ対応）プロセッサとこれらの周辺機器を使い始めたら、Linuxバージョンをどのように構築します（そして私のオプションは何ですか）」です。

ブートローダー：

RPI2やBBB（Beaglebone Black）に関する具体的なドキュメントと方法を見つけることができましたが、ブートローダなどの高度なトピックに入ると、何が起こっているのかあいまいに説明するスクラップだけがあります。たとえば、RPI2には3段階のブートローダがあります（読んだ場合は完全にuBootベースではありません）が、BBBにはより伝統的なuBootベースのブートローダがあります。新しいBBx15には、起動する場所を選択できるジャンパがあります。

デスクトップシステムはGRUB（IIRC）を使用し、組み込みシステムは通常uBootを使用します。 RPIはブート時にGPUを使用し、別のROMから最初のステップブートローダを読み取るという内容を読みました。これが利用可能なすべての情報です。自分だけのボードバージョンを稼働したい場合（討論目的では実用的ではない）、uBoot以外に何が起こっているのでしょうか？ジャンパブートの選択を可能にするために、BBx15用uBootに追加の修正はありませんか？

Linuxは起動段階について知っていますか？それとも実行されたらこれを忘れますか？ BBBはuBootを使用してeMMCからRAMにイメージをロードし、RPI2は3段階のブートローダを使用します。 BBBはARMプロセッサを使用していますが、RPI2はGPUを使用しているようです。電源を入れると、ARMプロセッサの実行が開始されます。これらのロードプロセスを準備するには何を変更する必要がありますか？ GPUはROMコードが完了するまでARMをリセットしたままにしますか？ GPUが起動プロセスの一部であるため、GPUが実行しているコードはuBootコードから削除され、GPUを持たない他のシステムはuBootコードで実行する必要がありますか？これらすべてが私にとって何を意味しますか？ 2番目または3番目のステップブートローダを変更すると、GPUから完全に独立してLinuxを実行できます（カーネルがGPUツールチェーンにコンパイルされている場合）。

第3段階のブートローダとconfig.txtは実際にuBootですか？

使用しているボードのヘッダー。これはドライバを含むメインラインのヘッダーですか、それとも別のものがありますか？すでに走っているなら、「タイトル」はまさにメインラインのタイトルですか？

組み込みマイクロコントローラの開発には、HAL層の使用に精通しています。 HALには、周辺機器を設定し、ドライバがこれらのリソースを指すようにする機能スタブがあります。ボードサポートパッケージには、通常、関連ボード用にすでにコード化されているこれらのHALスタブがあります。 Linux開発といくつかの類似点があると確信していますが、違いがどこにあるのかよくわかりません。

BuildrootやYoctoなどのパッケージがあります。含めるARMプロセッサとドライバを自動的に選択するインタフェースを備えたLinuxメインラインですか？