これは私が使用しているプロセッサに固有のものなのかどうか分かりませんので、私はCortex M0 +を使用しています。私は不思議に思っていました：-fPICを使ってgccを通して16進ファイルを生成すると、私は位置独立コードを生成します。しかし、objcopyから出てくるint 16進ファイル形式は、常に各行のヘッダーのアドレス情報を持っています。私がブートローダを書こうとしているのであれば、その情報を無視してそれに関連するバイトをスキップして、実際のコードをいつでもどこでもメモリにロードすることができます。gccを使用してインテル16進フォーマットと位置独立コード
intel-HEXフォーマットは、プログラムPROM、EPROM、または内部EPROM付きプロセッサに特化して設計されており、通常これらのデバイスのプログラマに使用されます。レコードの先頭にあるアドレスは、プログラムコードと直接関係がありません。これらは、PROMのどのアドレスにデータが書き込まれるかを示します。また、PROMはプロセッサのアドレス空間のどこにでもマッピングできるため、最終アドレスは変更できます。
PROMをプログラムしたくない場合は、レコード以外のデータを削除する必要があります。 （最後にチェックサムを忘れないでください;-)
私はintel-HEX形式を理解しているので、レコードは連続していてはいけません。その間に穴があるかもしれません。
いくつかの発言：
-f PICパラメータはインテルHEXフォーマットについては責任を負いません。私はコマンドラインのどこかで-O ihexを見つけるだろうと思う。実行可能なファイルを作成したい場合、objcopyはより適切な出力形式を提供します。
自分でブートプロセスの初期段階を書いていない限り、ブートローダはロードされません。ブートローダはロードされます。これが起こるアドレスは通常固定であり、変更可能ではありません。したがって、位置独立コードは必要ありませんが、どちらも傷ついていません。
これは古い質問ですが、解決しました。セクションは重要で、リンカファイルで指定されたアドレスに配置されます。データとBSSセグメントは、再配置可能なコードを作成しない限り、位置に依存しません。長い話が短いので、コードをロードするだけではアドレスは関係ありませんが、コードとデータを重要なものにすることができます –
ブートローダでは、1つのことだけを気にする必要があります。ロードしようとしているプログラムのアドレスと交差していないこと。たとえば、ブートローダがカーネルを起動すると想定される場合、カーネルメモリ（カーネルイメージがメモリに格納されている場所）またはdevicetreeと交差してはいけません。 – theadnangondal
しかしそれ以外の問題は、アドレス情報とチェックサムの16進数ファイルを取り除き、残りのアドレスをいくつかのアドレスにダンプしてどこにジャンプするのかという問題でした。あるいは、私が知る必要がある16進ファイルのセグメントがあるので、どこにジャンプするかを知る必要がありますか？ –
ええ、私はあなたがその情報を削除することができると思います。私はとにかくそれらのアドレスの使用を見ません...ジャンプは、それらのアドレスとは別に計算されます....おそらく、このヘルプの理解にhttp://stackoverflow.com/questions/5024387/trying-to-load- position-independent-code-on-cortex-m3 – theadnangondal