問題タブ [ecos]

MIPS-32 プロセッサ アーキテクチャ用の決定的な標準化されたスタック フレームと C 言語の呼び出し規則 (レジスタの使用法など) はないようです。つまり、独自のスタック フレームと呼び出し規則を定義するのは、完全にアセンブラー/コンパイラー ツール チェーンに任されているようです。私は、GCC コンパイラが MIPS-32 命令セットに使用する規則についての決定的なリファレンスを見つけるのに苦労しました。私は特に、eCos オープン ソース カーネルの組み込み環境で使用されている MIPS-32 コアをターゲットとする Cygwin で GCC クロス コンパイラを使用しています。

この分野での MIPS-32 の GCC に関する決定的なドキュメントへの参照を歓迎します。

eCosについて聞いたことがありますが、趣味のプロジェクトとして遊ぶのは楽しそうです。

誰もが合理的な価格の開発ボードを推奨できますか? コストがあまりかからない場合は、押すボタンをいくつか (プログラムで押したものを検出する) いくつかのボタンと、デバッグ出力用の LCD が必要です。イーサネットがいいでしょう (うーん、コストがあまりかからないのであれば、wifi USB と BlueTooth もいいかもしれません)。

助言がありますか？(私は通常 ARM 7 または 9 用に開発していますが、遊んでみるには同じものが必要ですか?)

それを見る1つの方法-組み込みLinuxはデスクトップLinuxから始まり、組み込みシステムに必要のない部分を捨てます（これは実際に本当ですか？）が、eCosは組み込みシステム用にゼロから設計されています。

ここで、ARMプロセッサ（おそらくARM 7）を想定します。パフォーマンスに違いはありますか？実際、私たちは非常に低負荷のシステム、1日あたり最大500トランザクションについて話しています。

一方が他方（またはFreeRTOSなど）に勝る利点はありますか？安定性、成熟度、パフォーマンス、開発ツール、その他何ですか？

私が考えることができるのは、別のo / sに移植しないことが確実な場合、組み込みLinuxを使用する場合、ユニットテストを実行するためのo/s抽象化レイヤーは必要ないということです。ホスト（デスクトップLinuxボックス）。

何か考えやコメントはありますか？ありがとう。

cdl_option "CYGPKG_FOO_FEATURE_A_ENABLE" を持つ CYGPKG_FOO という名前のパッケージがあるとします。この cdl_option が有効になっているときに、このパッケージの CFLAGS に特定の gcc フラグ ("-DFEATURE_A=1" など) を追加したい。

しかし、「eCos Component Writer's Guide」には次のように書かれています。

http://ecos.sourceware.org/docs-3.0/cdl-guide/build.make.html#BUILD.FLAGS

上記のリンクから、cdl_option の選択に基づいて CFLAGS を追加/削除できないようです...

ここでの私の質問は次のとおりです。最初の段落で説明したことを行うことができますか? はいの場合、どのようにしますか?

ありがとう！

ECOSを使用してSyntheticLinuxターゲットを構築しようとしています。私のソフトウェア環境：

• Ubuntu 11.4
• GCC 4.5.2
• ECOS 3.0

Config Toolで、「all」パッケージを使用して「LinuxSythetic」ターゲットを設定しました。F7（ビルド）を押すとコンパイルが開始されますが、後で次のように表示されます。

/opt/ecos/ecos-3.0/packages/hal/synth/i386linux/v3_0/src/syscall-i386-linux-1.0.S：アセンブラメッセージ：make：ディレクトリ `/ opt / ecos / linux_build'/ opt/ecosを離れる/ecos-3.0/packages/hal/synth/i386linux/v3_0/src/syscall-i386-linux-1.0.S:457：エラー：__restore_rtの.size式が定数に評価されない

/opt/ecos/ecos-3.0/packages/hal/synth/i386linux/v3_0/src/syscall-i386-linux-1.0.S:457：エラー：__restoreの.size式は定数makeに評価されません：[src /syscall-i386-linux-1.0.od]エラー1make：[ビルド]エラー2

434行目のファイル/opt/ecos/ecos-3.0/packages/hal/synth/i386linux/v3_0/src/syscall-i386-linux-1.0.Sの内容は次のとおりです。

したがって、 __ restoreと__restore_rtは未定義です。

私はこの部分をコメントアウトしてシグナル関連のパッケージを削除しようとしましたが（シグナルハンドラーのものであると言っています）、ECOSカーネルの基本部分のようです。パーツがコメントアウトされている場合、ビルドは成功しているように見えますが、サンプルアプリをコンパイルすると、シンボルがないためにリンカーエラーが発生します（cyg_hal_sys_restore）。

ばかげた考えですが、undefを削除するために（間違ったコードがエラーを引き起こさないことを実際に望んでいない）、同じ方法で「__restore」を「cyg_hal_sys_restore」と「...rt」に置き換えようとしました。ビルドは（undefがないので）大丈夫です、例のコンパイルは（行方不明のシンボルがないので）大丈夫です、しかし例a.outは私がそれを始めた聖なる瞬間にsegfaultを投げます。

Halp、pls。、私はインラインasmやECOSに精通していません。

複数のスレッドを使用する eCos を実行している MIPS ターゲットがあります。デバッグには、gdb 7.5 と JTAG プローブを使用しています。

GDB から現在のスレッドを検査してバック トレースするにはどうすればよいですか。ベース スレッド アドレスと、代替スレッドからのプログラム カウンターがあります (必要に応じて他の情報を適切に見つけることができます)。

gdb は eCos を認識しないため、「情報スレッド」などのコマンドは機能しません。そのため、gdb のどのスレッド コンテキストをマニュアル化する必要があるでしょう...

gccプロファイリングを実装しようとしています。

PowerPCで組み込み環境のeCosを使用しています。私はCでプログラミングしています。

スイッチを使用してコンパイルおよびリンクすると、シンボルが未定義-pgであることがわかります。_mcount

この関数はターゲット固有であるため、実装する必要があることに気付きました。

_mcount機能の要件は何ですか？

すべてのレジスタを保存して復元する必要があるというのは正しいですか？標準の32と一緒に保存および復元する必要のある特殊レジスターはありますか？

_mcount割り込みを無効にして呼び出す必要があるというコメントを見たことがありますか、それとも_mcountコールツリーデータを記録する前に割り込みを無効にしますか？

私のPowerPCは8245です。これは603eファミリのプロセッサです。

powerpc-eabiとしてクロスコンパイラとして構築されたGCC4.6.1を使用しています。

これは、gccによって生成される_mcount呼び出しの例です。プロファイルされている関数の最初の命令は、示されている最初の行です。

コンパイラスイッチによって作成されたコードは、次のこと-pgを実行します。

• 1）呼び出し元のアドレスは、2つの命令mflr r0と。でスタックに格納されますstw r0,4(r1)。
• 2）入力したばかりの関数のアドレスはr0、2つの命令lis r12,35とで格納されaddi r0,r12,-32088ます。

したがって、_mcountが呼び出されるとr0、入力された関数アドレスが4(r1)含まれ、呼び出し元のプログラムカウンターが含まれます。この情報のペアが保存され、コールグラフの作成に使用されます。

この情報は、gccソースgcc / libffi / src / powerpc/asm.hを読んで見つけました。

何_mcountが返ってくるのかまだわかりません。LRを復元する必要があるようです。そのため、_mcountを使用できませんblr。LRを復元し、の後に命令に戻る(4)r1のではなく、ジャンプ命令を使用する必要があります。これは意味がありますか？blrbl _mcount

私は持っている：

• eCos OS を搭載した独自のプロトタイプ ARM ボード (Cortex-M3 ベース)
• ボードには RedBoot ブートローダーがプログラムされています
• シリアルライン（RS-232）
• ARM 用 GDB デバッガー (arm-eabi-gdb)
• ホスト OS は Windows/Cygwin および/または Linux (実際には関係ありません)

問題: GDB デバッガーがシリアル回線経由でターゲットに接続できません。

私が欲しいのは、ターゲット上のGDBスタブが生きていて動作しているかどうかを理解するために、GDBリモートプロトコルのパケットを盗聴することです.

詳細: RedBoot には、ターゲットの制御を組み込みの GDB スタブに渡すオプションがあります。RedBoot が動作していることはわかっています。これに接続して、シリアル ライン経由でコマンドを送信できます。RedBoot のマニュアルによると、GDB スタブへの切り替えは $ または + 記号 (実際には GDB リモート プロトコル パケットのプレフィックス) を入力することで行うことができます。それらのシンボルを送信すると、端末が死ぬときにうまくいくようです。しかし、RedBoot が GDB スタブをサポートするようにコンパイルされているかどうかはわかりません (理由は聞かないでください :-))。

次に、GDB デバッガーを使用してボードに接続しようとすると、次の図が表示されます (Windows の場合)。

ポートは正しく、ボーレートも同様です。何にも接続されていない別のシリアルポートで同じことをしようとすると、実際には同じ出力が得られます。

私が知りたいのは、GDB スタブが何かを送り返すかどうかです。

多分そうだと直感的に思った

役に立ちますが、GDBのマニュアルによると、効果は非常に限られており、私の場合はそれを超えています。

デバッグ ログを有効にするマクロを使用して GDB デバッガーをコンパイルすることは可能でしょうか?

stm32f4discovery Cortex-M4 で eCos 用の簡単なプログラムを作成しました。以下の手順に従います。

$ecosconfig 新しい stm32f4discovery

$configtool

$arm-none-eabi-gcc -o hello.elf hello.c -Lecos_install/lib -I ecos_install/include -mcpu=cortex-m4 -mthumb -g -O2 -ffunction-sections -fdata-sections -Ttarget.ld - nostdlib

$arm-none-eabi-objcopy -O バイナリ -R .sram hello.elf hello.bin

実際、それは成功です。でも、「hello ecos!」の見方がわかりません。

ボーレートとttyをセットアップする必要があると思います。そのため、minicom を使用してこれを行います。残念ながら、私は失敗しました。