6

「arm-elf」を生成するコンパイラ（gnuarm GCC 4.1.1）を使用してブートローダーとアプリケーションをコンパイルする製品があります。

ブートローダーとアプリケーションは、リンカースクリプトの異なるフラッシュメモリ領域に分離されています。

このアプリケーションには、ブートローダーを呼び出すことができる機能があります（2つのパラメーターを持つ単純なc関数として）。

世界中の既存の製品をアップグレードできる必要があります。これは、常に同じコンパイラを使用して安全に行うことができます。

ここで、arm-eabiを出力する新しいGCCバージョンを使用してこの製品アプリケーションをコンパイルできるようにしたいと思います。

アプリケーションとブートローダーの両方が同じツールチェーンを使用してコンパイルされる新製品ではすべて問題ありませんが、既存の製品はどうなりますか？GCC 4.6.xとarm-none-eabiでコンパイルされた新しいアプリケーションをフラッシュした場合でも、アプリケーションは古いarm-elfブートローダーからブートローダー関数を呼び出すことができますか？

さらに、上記の質問とは直接関係ありませんが、arm-elfでコンパイルされたオブジェクトファイルをarm-eabiでコンパイルされたバイナリに混合できますか？

編集：

何か違いがあれば、ベアメタルARM7用に構築していることを明確にするのは良いことだと思います...

4

3 に答える 3

5

いいえ。ABI は、バイナリを互換性のあるものにする魔法です。Application Binary Interface は、他のライブラリ/アプリケーションとの通信方法に関するさまざまな規則を決定します。たとえば、ABI は呼び出し規約を定義します。これは、C 関数に引数を渡すためにどのレジスタを使用するか、余分な引数を処理する方法などについて暗黙の前提を作成します。

EABI と ABI の正確な違いはわかりませんが、EABI を読むことでそれらのいくつかを見つけることができます。Debian のページでは、syscall 規則が異なること、およびいくつかのアライメントの変更について言及しています。

上記を考えると、もちろん、arm-elf オブジェクトと arm-eabi オブジェクトを混在させることはできません。

上記の回答は、メイン アプリケーションでブートローダー コードと対話することを前提にしています。インターフェイスが非常に単純な場合 (2 つのパラメーターを使用した関数呼び出しのみ)、動作する可能性があります。やってみると面白い実験になります。ただし、**動作が保証されている**わけではありません。

EABI を使用する必要はありません。古いバージョンと同様に、gcc 4.6 でも arm-elf ツールチェーンを生成できます。Windows でバイナリ ツールチェーンを使用しているため、さらに多くの課題が発生する可能性があります。crosstool-ngを調査することをお勧めします。これは Linux で非常にうまく機能し、適切なツールチェーンを構築するために cygwin でも問題なく動作する可能性があります。

于 2012-05-03T20:36:31.630 に答える
5

インライン アセンブリでブートローダーを呼び出すオプションが常にあります。その場合、必要な呼び出し標準に従うことができます :)。

ただし、移植性の問題に加えて、このアプローチでは、ブートローダーとアプリケーションについて次の 2 つの仮定が行われます。

  • アセンブリ コードを使用してのみ古いタイプのブートローダーを呼び出すことができるため、非 EABI ツールチェーンでビルドされたブートローダーが特定のデバイスにあることをアプリで検出できます。
  • あなたが言及した2つのパラメーターは、ブートローダーによってプリミティブデータとして使用されます。たとえば、ブートローダがそれらを構造体へのポインタとして使用すると、不正なアラインメントやパディングなどの問題に直面する可能性があります。
于 2012-05-04T16:59:22.353 に答える
2

これでOKだと思います。私は自分でこのような移行を行いました。覚えていることから、除算の処理に関する問題に遭遇しただけです。

これは違いについて私が見つけることができる最良の情報です。構造体の配置の問題がなければ問題ないことを示唆しています。

于 2012-05-04T17:13:24.723 に答える