3

Raspberry-Pi用に独自のツールチェーンを構築しようとしています。ビルド済みのツールチェーンがたくさんあることを私は知っています。この作品は教育上の理由によるものです。私はスクラッチブックから組み込みアームLinuxをフォローしています。そしてこれまでのところgccとuClibの構築に成功しました。ターゲットarm-unknown-linux-eabi用にビルドしています。

起動可能なファイルシステムの準備に関しては、ブートローダーのビルドについて自分自身に疑問を投げかけています。

このシステムのブートローダーに関する部分は不完全なようです。今、私は自分のarm-unknown-linux-eabiツールチェーンを使用してこのシステムのubootを構築する方法を自問しています。

Linuxカーネルの呼び出しに依存しないツールチェーンを構築する必要がありますか？私の最初の調査では、OSに依存するツールチェーン（Linuxカーネルのsys-callなど）と、その下にカーネルを必要としないツールチェーンが別々にあることがわかりました。「ベアメタル」ツールチェーンまたは「スタンドアロン」ツールチェーンと呼ばれることもあります。

一部の情報源は、Linuxツールチェーンを使用してU-Bootを構築できると述べています。これが本当なら、なぜそしてどのようにこれが機能するべきですか？

また、「ベアメタル」ツールチェーン用の2つ目のツールチェーンを構築する必要がある場合は、これら2つの違いに関する情報を見つけることができます。別のlibstdcが必要ですか？

4

2 に答える 2

2

カーネルの構築に使用したのと同じクロスツールチェーンを使用してU-Bootを構築できます。おそらく、システムの残りのユーザースペースです。

ブートローダーは、定義上、自己完結型であり、Cランタイムライブラリを使用しないため、Cランタイムライブラリの選択を気にしません。したがって、sys-callsの問題は発生しません。

ツールチェーンは常に、完全に機能する開発システムによってホストされる必要があります。常にターゲットシステムではありません。「ベアメタルツールチェーン」への参照は、コンパイラによるsys-callの使用を指していません（I / Oのオペレーティングシステムに大きく依存しています）。ブートローダーとカーネルを構築するときに重要なのは、コンパイラとリンカが、特定のメモリアドレスで実行できる静的にリンクされたコードを生成するように構成されていることです。

于 2012-12-13T20:18:19.527 に答える
1

ほとんどすべての可能な方法で、組み込みツールチェーンとLinuxツールチェーンの間に違いはありません。ただし、例外が1つあります。

その例外は__clear_cacheです。これはコンパイラによって生成され、「Linux」で生成される関数です。ツールチェーンには、命令キャッシュとデータキャッシュを同期するためのシステムコールが含まれています。（そのビットの詳細については、http：//blogs.arm.com/software-enablement/141-caches-and-self-modifying-code/を参照してください。）

さて、その関数への呼び出しを明示的に追加しない限り、それが呼び出されることを私が知っている唯一の方法は、Cでネストされた関数（避けるべきGCC拡張）を書くことです。しかし、それは違いです。

于 2012-12-15T20:19:18.273 に答える