2016/02/11

T2SPのT-Kernelソースコードのデバッグ(準備編)

 以前の記事に記載したとおり、T2SPにはQEMUが含まれています。
 QEMUは、GDB Serverを持っているので、GDBによるデバッグが可能です。
 GDBは、以前の記事に記載したARM用のものを使用します。
 以下、eclipse+CDTでGDBによるデバッグの設定などの覚書です。

 まず、eclipseの設定について。
 eclipseでGDBによるデバッグを実行するために、"Debug Configurations"に設定を追加します。
 メニュー[Run]->[Debug Confirurations...]で表示される"Debug Configurations"の[C/C++ Remote Application]で右クリックして[New]により、新しい設定を追加します。
 設定する内容は以下のとおりです。

----
・[Name:]に適当な名称を入力(ここでは"T-Kernel"とします)
・下部に表示されているのが"Using GDB(DSF) Automatic Remote Debugger Launcher"の場合、"Select other"をクリックして、「Select preferred Launcher」で[Use configuration specific settings]をチェックして、"Using GDB(DSF) Manual Remote Debugger Launcher"を選択
・[Main]タブで以下を設定
→[C/C++ Application:]に"${workspace_loc:/tkernel_source}/kernel/sysmain/build/tef_em1d/kernel-rom.rom"を入力(ELFファイルの指定)
→[Disable auto build]をチェック
・[Debugger]タブで以下を設定
→[Stop on startup at:]に"usermain"を入力(デフォルトのブレークポイント。チェックを外すとブレークしません)
→[Main]タブの[GDB debugger:]に"C:¥gnutools¥bin¥arm-*-eabi-gdb.exe"を入力(ARM用GDBの指定。環境に合わせて"*"は変更してください)
→[Connection]タブの[Type:]が"TCP"であることを確認
→[Connection]タブの[Host name or IP address:]が"localhost"であることを確認
→[Connection]タブの[Port Number:]に"1234"を入力
----

 上記は、カーネル部のELFファイルによりデバッグする場合の設定ですが、T-Monitor部のELFファイルでデバッグする場合には、

----
・[Name:]に適当な名称を入力(ここでは"T-Monitor"とします)
・[Main]タブの[C/C++ Application:]に"${workspace_loc:/tkernel_source}/monitor/tmmain/build/tef_em1d/tmonitor"を入力
・[Debugger]タブの[Stop on startup at:]に"reset_entry"を入力
----

としてください。
 なお、eclipseからGDBを実行するために、"C:\MinGW\bin"にある以下のdllファイルが必要となります。

----
libiconv-2.dll
libexpat-1.dll
libgcc_s_dw2-1.dll
----

 これらは、"C:\gnutools\bin"にコピーしてください(eclipseからGDBを実行する際に、"C:\MinGW\bin"にPATHを通す方法が分からなかったので)。

 続いて、QEMUの準備について。
 QEMUは、zipを展開したT2SPの"T-Kernel2.0/emulator"に格納されています。この下のフォルダ"tef_em1d"に"readme.txt"が格納されているので、これに記載されているとおり、binフォルダを"C:\qemu\bin"にコピーします。
 QEMUの実行について、"readme.txt"にはコマンドプロンプトから"qemu.bat"にオプションをつけて起動する方法が記載されていますが、多少面倒なので、エクスプローラーから"qemu.bat"をダブルクリックして実行できるように"qemu.bat"を編集します(GDBでデバッグするためのオプションも追加します)。
 具体的には、

----
C:\qemu\bin\qemu-tef_em1d.exe -s -S ^
-cpu arm1176jzf-s ^
-kernel rom.bin ^
-sd sd.img ^
-serial tcp:127.0.0.1:10000,server ^
-rtc base=localtime ^
-dipsw dbgsw=on ^
-nographic
-----

とします。
 オプション"-s"がGDB Serverの設定ですが、これは"-gdb"の短縮形です。"-s"でGDBが接続しない場合には、"-gdb tcp::1234,ipv4"みたいにすることで、接続するかもしれません。

 QEMUで実行するバイナリファイル"rom.bin"は、ソースファイルの"/kernel/sysmain/build/tef_em1d"のmakefileを使用して、"make emu"により作成します(当然、全てのビルドが正常に完了していて、必要なELFファイルが全て揃っている必要があります)。
 具体的には、MSYSで以下を実行します(binファイルの"qemu/bin"へのコピーを含む)。

----
export BD=/c/work/T-Kernel2.0/srcpkg/tkernel_source/
export GNU_BD=/c/gnutools
export _GNU_CONFIG=arm-*-eabi
export GNUARM_2=${GNU_BD}/${_GNU_CONFIG}
export PATH=/c/MinGW/msys/1.0/bin:${PATH}
cd ${BD}/kernel/sysmain/build/tef_em1d
make emu
cp -f rom.bin /c/qemu/bin
----

 PATHの指定には、"/c/MinGW/bin"も必要かもしれません。
 なお、T2SPに含まれている資料には、明確な記載が見当たらなかったのですが、デフォルトではビルド時のgccのオプションに"-g"が指定されていません。
 これを回避するためにビルド時の環境変数の設定として、"export mode=debug"を実行します。
 ただし、この環境変数を設定することで、余計なデバッグ用のマクロ定義が有効となるので、一部makefileの編集が必要で、"/etc/sysdepend/tef_em1d/makerules.sysdepend"の81行目の"CPPFLAGS += "の最後にある"-DDEBUG"を削除してください。

 そして、QEMUを実行して、GDBを接続する手順について。
 大まかな流れは、「QEMU起動→telnet接続→GDB起動(接続)」です。
 まず、"C:\qemu\bin"の"qemu.bat"を実行しQEMUを起動します。コマンドプロンプトが表示され、telnet接続待ちとなります。
 telnetは何でもよいのですが、ここではMSYSを使用して説明します。MSYSのtelnetは、MinGWのインストーラーで、パッケージ"msys-inetutils"がインストールされていれば使用できます。
 telnet接続のため、MSYSで"telnet localhost 10000"を実行します。
 正常にtelnet接続すると、

----
Connected to localhost.
Escape character is '^]'.
----

と出力されます(が、まだリンカスクリプトの修正が必要で、デフォルトのままだと、この時点でQEMUが落ちます。これについては、次回記載予定)。
 telnet接続後に、GDBの起動(接続)です。
 eclipseのPerspectiveを"Debug"に切り替え、"Debug Configurations"から上記で設定した"T-Kernel"を実行([Debug]ボタンをクリック)してください。
 正常に起動(接続)すると、eclipseのConsoleにそれっぽい出力があり、T-Monitorが正常に起動すると、telnetに、

----
T-Monitor/tef_em1d Version 2.01.00

TM>
----

と出力されます。
 ここで、telnet(T-Monitor)で、

go 0x70030000

を入力すると、カーネル部が起動され、正常に動作すればusermain()でブレークします(が、ソースコードの修正が必要で、デフォルトのままだとtelnetのエラー情報が出力され、カーネル部は正常起動しません。これについても、次回記載予定)。

 QEMU(デバッグ)を終了する場合には、telnet(T-Monitor)で"exit"を入力してください(eclipse側からの停止の実行はうまく行きませんので、QEMUを終了してください)。

| | コメント (0) | トラックバック (0)

2016/02/06

T2SPのT-Kernelソースコードのビルド(eclipseの設定)

 ファイルの展開とeclipseのワークスペースとプロジェクトの設定については、前々回の記事に記載しましたので、今回はその他の細かい設定について覚書です。

 まず、ビルドの設定について。

 eclipseでは、Makefileが格納されているフォルダを指定することで、そのMakefileを使用したmakeの実行が可能です。makeの実行は、メニューの[Project]->[Build Project](もしくは、プロジェクトで右クリックして[Build Project])ですが、いくつかの設定が必要です。
 メニューの[Project]->[Properties]の[C/C++ Build]->[Environment]で、MSYSでのビルド前の設定でも行なった、

[Variable]=[Value]
BD=/c/work/T-Kernel2.0/srcpkg/tkernel_source/
GNU_BD=/c/gnutools → gccクロスコンパイラをインストールしたフォルダ
_GNU_CONFIG=arm-*-eabi → gccクロスコンパイラのプレフィクス("*"は環境に合わせて変更)
GNUARM_2=${GNU_BD}/${_GNU_CONFIG}

の環境変数を追加します。
 これだけだと、

Error: Program "make" not found in PATH

とエラーになるので、PATHに"C:\MinGW\msys\1.0\bin"を先頭に追加します。具体的には、[Add...]ボタンで[Variable]に"PATH"を入力して[Value]をからの状態で[OK]ボタンをクリックすると、システムのPATHがValueに格納された状態で追加されるので、それを[Edit...]で編集することで追加します。
 PATHには"C:\MinGW\bin"も追加しておく必要があるかもしれません(現在の私の環境では設定の必要がないのですが、これは、必要なdllファイルを"C:\gnutools\bin"にコピーしているためだと思います。なぜコピーしているのか、については次回記載予定)。

 環境変数を設定したら、[C/C++ Build]の[Builder Settings]タブの[Build location]で実行するMakefileを格納するフォルダを指定します。
 これで、指定したMakefileでmakeが実行できるようになります。

 ELFファイル作成まで、まとめてビルドしたい場合には、ビルド実行用の.shを用意して、外部ツール"External Tools"として実行します。
 .shファイルの内容は、
----
export BD=/c/work/T-Kernel2.0/srcpkg/tkernel_source/
export GNU_BD=/c/gnutools
export _GNU_CONFIG=arm-*-eabi
export GNUARM_2=${GNU_BD}/${_GNU_CONFIG}
export PATH=/c/MinGW/msys/1.0/bin:${PATH}
export mode=debug
cd ${BD}/lib/build/tef_em1d
make
cd ${BD}/kernel/sysmain/build/tef_em1d
make
cd ${BD}/config/build/tef_em1d
make
cd ${BD}/monitor/cmdsvc/build/tef_em1d
make
make install
cd ${BD}/monitor/hwdepend/tef_em1d/build
make
make install
cd ${BD}/monitor/driver/flash/build/tef_em1d
make
make install
cd ${BD}/monitor/driver/memdisk/build/tef_em1d
make
make install
cd ${BD}/monitor/driver/sio/build/tef_em1d
make
make install
cd ${BD}/monitor/tmmain/build/tef_em1d
make
make install
----
という感じの内容で作成します。
 当然のことながら、環境変数の内容は、それぞれの環境に合わせて変更してください。
 上記は、前々回の記事の環境に合わせています。
 PATHの設定は、makeを実行するためです。
 環境変数"mode"に"debug"を設定しているのは、(おそらく)次回説明します。
 ファイル名は、説明上"build.sh"とし、"C:\work\T-Kernel2.0\srcpkg\tkernel_source"に格納します。

 この"build.sh"を外部ツールとして実行できるようにするには、 "Run->External Tools->External Tools Configurations..."で「External Tools Configurations」を開き、[Program]で右クリックして[New]を選択し、以下を設定します。

・[Name] … 適当な名称
・[Main]タブ内の以下を設定
 "Location" … C:¥MinGW¥msys¥1.0¥bin¥sh.exe
 "Working Directory" … ${workspace_loc:/tkernel_source}
 "Arguments" … "build.sh"(実行する".sh"(スクリプト)ファイル)
・[Build]タブ内の"Build before launch"のチェックを外す

 設定後に、[Run]ボタンをクリックすると、.shファイルが実行されます(2回目移行は、プルダウンメニューとして表示されるようになります)。

 次回は、デバッグの設定について記載する予定です(気が向いた時に)。

| | コメント (0) | トラックバック (0)

2015/05/29

T2SPのT-Kernelソースコードのビルド(修正の詳細)

 前回の記事で予告した「修正の詳細」です。

■ライブラリのビルドで発生した問題
----
【問題】
make: /usr/local/te/etc/platform: Command not found
../../../etc/makerules:134: /usr/local/te/etc/sysdepend/tef_em1d/makerules.sysdepend: No such file or directory
make: *** No rule to make target '/usr/local/te/etc/sysdepend/tef_em1d/makerules.sysdepend'. Stop.
【対応】
 環境変数BDが設定されていなかったので、デフォルト値が使用されてエラーとなっていた。
 make実行前に、BDにソースコードのルートを設定するために、
export BD=/c/work/T-Kernel2.0/srcpkg/tkernel_source/
を実行で解決。
----
【問題】
/etc/sysdepend/tef_em1d/makerules.sysdepend:32: *** 'GNU_BD' is not defined. Stop.
【対応】
 環境変数GNU_BDが設定されていなかったのでエラーとなっていた。
 make実行前に、gccクロスコンパイラのインストールフォルダ(targetフォルダ)を設定するために、
export GNU_BD=/c/gnutools
を実行で解決。
----
【問題】
/etc/sysdepend/tef_em1d/makerules.sysdepend:36: *** 'GNUARM_2' is not defined. Stop.
【対応】
 環境変数GNUARM_2が設定されていなかったのでエラーとなっていた。
 make実行前に、gccクロスコンパイラのbinを格納しているフォルダを設定するために、
export GNUARM_2=${GNU_BD}/arm-*-eabi
を実行で解決。
----
【問題】
/bin/sh: line 1: make: command not found
/bin/sh: line 2: make: command not found
【対応】
 MSYSの/binにパスが通っていなかったので、make(の実行ファイル)が見つからず、エラーとなっていた。
 "/etc/sysdepend/tef_em1d/makerules.sysdepend"の45行目に":/usr/bin"を追加(GNUARM_2の場合に、MSYSの/binにパスを通す)することで解決。
----
【問題】
make[1]: /c/gnutools/arm-*-eabi/bin/gcc4arm: Command not found
【対応】
 makefileで使用する"gcc4arm"が存在していなかったためエラーとなっていた。
 "te.Cygwin-i686.common.13.tar.gz"に格納されている"tool/etc/gcc4arm"を"/c/gnutools/arm-*-eabi/bin"にコピーして解決。
----
【問題】
gcc4arm: line 27: /c/gnutools/bin/arm_2-unknown-tkernel-gcc: No such file or directory
【対応】
 環境変数_GNU_CONFIGが設定されていなかったので、デフォルト値が使用されてエラーとなっていた。
 make実行前に、gccクロスコンパイラのプレフィックスを設定するために、
export _GNU_CONFIG=arm-*-eabi
を実行して解決。
("GNUARM_2"は"${GNU_BD}/${_GNU_CONFIG}"でよいことになった)
----
【問題】
"libconv-2.dllが見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションをインストールし直すとこの問題は解決される場合があります。"
のメッセージが表示される。
【対応】
 MinGWの/binにパスが通っていなかったので、必要なDLLファイルが見つからずにエラーとなっていた。
 "/etc/sysdepend/tef_em1d/makerules.sysdepend"の45行目に":/c/MinGW/bin"を追加(MinGWの/binにパスを通す)することで解決。
----

■カーネルのビルドで発生した問題
----
【問題】
-o kernel-ram.sys
ld.exe: target elf32-larm-tkernel not found
【対応】
 自前で用意した環境のBFDライブラリには、"elf32-larm-tkernel"の定義が無いためエラーとなっていた。
 "/kernel/sysmain/build/tef_em1d/kernel-ram.lnk"の19行目を、

"elf32-larm-tkernel"→"elf32-littlearm"
"elf32-barm-tkernel"→"elf32-bigarm"

に変更することで対応。
 以下のファイルでも同様の対応が必要。
"/kernel/sysmain/build/tef_em1d/kernel-rom.lnk"
"/config/build/tef_em1d/rominfo.lnk"
"/monitor/tmmain/build/tef_em1d/monitor.lnk"
"/config/launch-ramkernel/build/tef_em1d/rominfo.lnk"
----
【問題】
make: /c/gnutools/bin/arm_2-unknown-tkernel-objcopy: Command not found
【対応】
 makefileで使用されている"objcopy"のプレフィックスが固定になっていたため、実行ファイルが見つからずにエラーとなっていた。
 正しいプレフィクスを指定するために、"/etc/sysdepend/tef_em1d/makerules.sysdepend"の245行目の、
OBJCOPY = $(GNU_BD)/bin/arm_2-unknown-tkernel-objcopy

OBJCOPY = $(GNU_BD)/bin/arm-*-eabi-objcopy
に変更して解決(その上のCPPも同様の修正が必要)。
----
【問題】
/ld.exe: section .ARM.exidx loaded at [700481a0,700481a7] overlaps section .data loaded at [700481a0,700481cf]
【対応】
 2つ上の.lnkファイルの修正により、セクション.ARM.exidxが必要となっていたが、.lnkファイルに記載が無いため、セクション.dataと衝突していたためエラーとなっていた。
 セクション.ARM.exidxを明示的に指定するため、"/kernel/sysmain/build/tef_em1d/kernel-rom.lnk"のセクション".text"の直後(38行目)に、
__ARM_exidx = .;
.ARM.exidx : { *(.ARM.exidx*) }
を追加して対応。
----

| | コメント (0) | トラックバック (0)

2015/05/27

T2SPのT-Kernelソースコードのビルド

 先日用意したgccクロスコンパイラを利用して、トロンフォーラムが用意しているARM用のT-Kernelソースコードをビルドした際の覚書です。

 トロンフォーラムのソースコードダウンロードのサイトでは、T-Kernelの学習用に「T-Kernel 2.0 Software Package(以下、T2SP)」が用意されています。
 これには、QEMUというPCエミュレータが付属しているので、開発ボードがなくても作成したソフトウェアの動作確認ができます。
 T2SPには、Cygwin用クロスコンパイラ+eclipseの開発環境も含まれていますが、目的が異なるので今回は使用しません。
 ちなみに、T2SPの開発環境とQEMUの使用方法については、CQ出版社の雑誌インターフェース2012年5月号の特集記事が参考になります(T2SPに含まれるドキュメントを簡潔に記載している感じです)。

 開発環境は、先日用意したgccクロスコンパイラeclipseを予定したので、まずは最新のeclipse(バージョンはLuna SR2 (4.4.2) 、パッケージはEclipse IDE for C/C++ Developers)をダウンロードしてcドライブに展開しました。

 ダウンロードしたT2SPは、"C:\work"に展開しました。ソースコードは、"/c/work/T-Kernel2.0/srcpkg"にある"tkernel_source.tar.gz"なので、MSYSで"tar xvf tkernel_source.tar.gz"により、このフォルダにそのまま展開しました。

 eclipseのWorkspaceを"C:\work\T-Kernel2.0\srcpkg"に切り替え、File->New->Makefile Project with Existing Codeを選択して、「Existing Code Location」に"C:\work\T-Kernel2.0\srcpkg\tkernel_source"を指定し、プロジェクトとしました。

 開発環境としてはeclipseを使用することにしたのですが、ビルドはmakefileを利用するので、まずはMSYSでビルドしてみることにしました。
 参考としたのは、T2SPのドキュメント、
"T-Kernel2.0/srcpkg/doc/ja/tkernel.txt"
"T-Kernel2.0/srcpkg/doc/ja/tmonitor.txt"
です。
 その結果、以下の設定やファイルの修正が必要なことが分かりました。

----
1.ビルド前の環境変数の設定
export BD=/c/work/T-Kernel2.0/srcpkg/tkernel_source/
export GNU_BD=/c/gnutools → gccクロスコンパイラをインストールしたフォルダ
export _GNU_CONFIG=arm-*-eabi → gccクロスコンパイラのプレフィクス(環境に合わせて"*"は変更してください)
export GNUARM_2=${GNU_BD}/${_GNU_CONFIG}

2."etc/sysdepend/tef_em1d/makerules.sysdepend"の修正
・45行目に":/usr/bin:/c/MinGW/bin"を追加する(GNUARM_2の場合に、MSYSの/binとMinGWの/binにパスを通す)
・245行目の、
OBJCOPY = $(GNU_BD)/bin/arm_2-unknown-tkernel-objcopy

OBJCOPY = $(GNU_BD)/bin/arm-*-eabi-objcopy
に変更する(その上のCPPも同様の修正が必要)

3."gcc4arm"のコピー
・"te.Cygwin-i686.common.13.tar.gz"に格納されている"tool/etc/gcc4arm"を"/c/gnutools/arm-*-eabi/bin"にコピーする

4.".lnk"のOUTPUT_FORMATの引数変更
・ファイル、
"/kernel/sysmain/build/tef_em1d/kernel-ram.lnk"
"/kernel/sysmain/build/tef_em1d/kernel-rom.lnk"
"/config/build/tef_em1d/rominfo.lnk"
"/config/launch-ramkernel/build/tef_em1d/rominfo.lnk"
"/monitor/tmmain/build/tef_em1d/monitor.lnk"
について、
"elf32-larm-tkernel"→"elf32-littlearm"
"elf32-barm-tkernel"→"elf32-bigarm"
を変更する

5."/kernel/sysmain/build/tef_em1d/kernel-rom.lnk"に".ARM.exidx"の追加
・セクション".text"の直後(38行目)に、
__ARM_exidx = .;
.ARM.exidx : { *(.ARM.exidx*) }
を追加する。

6.perlのフォルダ指定を変更
・"/etc/mergesrec"の1行目を、
/usr/local/bin/perl → /usr/bin/perl
に変更する(他の同様のファイルも修正しておいたほうが良い)
----

 以上でELFファイルは作成されました。
 修正がなぜ必要だったかは、次の記事で記載する予定です。
 eclipseで必要な設定は、さらにその次の記事の予定です。
 また、ここまでで作成したELFではバグがあるので、その修正については…そのうち記載します。

 なお、T2SPに付属されている開発環境を使用すれば、このような苦労はないものと思われます。

| | コメント (0) | トラックバック (0)

2015/05/03

ARM用のgccクロスコンパイラ他の作成について

 必要があって、Windows上でARM用のgccクロスコンパイラ(+GDB)を作成しました。
 これについては、ネット上に数多くの情報があるのですが、時代と共に陳腐化しているものも混ざっており、そのためにハマったこともあるので、覚書としてまとめておきます(当然、この情報もいずれ陳腐化することでしょう)。
 なお、作業にあたって、以下の資料を参考にしました。

Interface (インターフェース) 2015年 03月号
CとGNU開発ツールによる組み込みシステムプログラミング 第2版

 特に、インターフェースの特集記事は、環境は異なるものの勉強になりました。

 作成した環境は、WindowsXP+MinGWで、各ツールのバージョンは、
binutils 2.25
gcc 4.9.2
newlib 2.2.0-1
gdb 7.9
です。
 newlib以外は、GNUオペレーティングシステムのリンク先からダウンロードしました。

 MinGWは、バージョンによってインストーラーが異なるらしく、私が利用したインストーラー(現時点の最新)は「MinGW Installation Manager」を利用するものでした。
 MinGW Installation Managerで、以下をMark for Installationとしました。

[Basic Setup]
mingw-developer-toolkit
mingw32-base
mingw32-gcc-g++
msys-base

[All Packages]
mingw32-libexpat … gdbのビルドで必要
mingw32-gmp dev … gccのビルドで必要
mingw32-mpc dev … gccのビルドで必要
mingw32-mpfr dev … gccのビルドで必要

 マークした後に、[Installation]→[Apply Changes]の「Apply」ボタンでインストールし、インストール後に"C:/MinGW/msys/1.0/etc"にある"fstab.sample"をコピーして、(ActivePerlは使用しない予定なので)、
c:/ActiveState/perl /perl
をコメントアウトして、"fstab"としました。これにより、"/mingw"が"C:\MinGW"に置き換えられるようになるので、例えば"cd /mingw/bin"の実行などが有効となります。
 Msysは"C:/MinGW/msys/1.0/msys.bat"で起動しますが、起動後にタイトルバーを右クリックして、プロパティを表示して、オプションタブの編集オプションの「簡易編集モード」と「挿入モード」にチェックを入れると、右クリックで選択範囲をコピーしたり、選択していないときは右クリックでクリップボードの内容をペーストできるようになるので便利です。
 Msys上では、"C:/MinGW/msys/1.0"は"/usr"となります。
 また、ドライブの指定は、例えばCドライブなら"/c/"を使用します。例えば"C:/MinGW/msys/1.0"は"/c/MinGW/msys/1.0"となります。

 MinGWの他に、Pythonをインストールしました。これは、GDBビルド時に"libpython27.a"が必要となるので、Active Pythonではなく、python.orgのPython2.7.Xをインストールしました(最初にActive Pythonをインストールしたらビルドできなくて悩みました)。

 クロスコンパイラの作成は、

1.binutilsのビルド&インストール
2.newlibビルド用のgccのビルド&インストール
3.newlibのビルド&インストール
4.gccのビルド&インストール
5.gdbのビルド&インストール

の順で行ないました。
 以下に、Msys上で実行した各ツールのビルド&インストール時のコマンドを記載します。なお、作業は"/usr/tmp"で行なうことを前提としています。
 また、作成したツールのインストール先は、"c:\gnutools"としています。prefixを指定しないと基本的に"/usr/local/bin"にインストールされるようですが、prefixのオプションを指定した方がパスを気にする必要性が少し減るようです。

1.binutilsのビルド&インストール
tar xvf binutils-2.25.tar.bz2
cd binutils-2.25
mkdir build
cd build
../configure --target=arm-*-eabi --prefix=/c/gnutools --disable-nls --enable-gold
make
make install

[補足]
 "arm-*-eabi"の"*"には適当な文字列を入れてください。
 ターゲットには"arm-elf"を指定することが紹介されていることが多いのですが、今回使用したgccのバージョンでは"arm-elf"はサポートされていませんでした。
 サポートしているターゲットについては、gccのソースコード解凍後の"INSTALL/specific.html"に記載されています。
 この件以外にも、解凍後の"README"や"INSTALL"には、必要な情報が記載されていることが多いので、目を通したほうが無難です(例えば、gccのconfigureは他のフォルダから実行しなければいけない("./configure"で実行してはいけない)、とか)。

 "--enable-gold"はリンカにgoldを使用することを有効にするオプションですが、指定しているとビルド時間がかなり長くなるようです。

2.newlibビルド用のgccのビルド&インストール
cd /usr/tmp
tar xvf gcc-4.9.2.tar.bz2
cd gcc-4.9.2
mkdir build
cd build
../configure --target=arm-*-eabi --prefix=/c/gnutools --disable-nls --disable-libssp --disable-shared --enable-languages=c
make
make install

[補足]
 make実行時に、
C:¥MinGW¥msys¥1.0¥bin¥make.exe: *** couldn't commit memory for cygwin heap, Win32 error 487
と出力されますが無視してmakeを再実行すれば良いらしいです(こちらのブログを参考にしました)。

3.newlibのビルド&インストール
cd /usr/tmp
tar xvf newlib-2.2.0-1.tar.gz
cd newlib-2.2.0-1
mkdir build
cd build
export PATH=/c/gnutools/bin:$PATH
../configure --target=arm-*-eabi --prefix=/c/gnutools
mkdir build
cd build

4.gccのビルド&インストール
cd /usr/tmp/gcc-4.9.2/build
../configure --target=arm-*-eabi --prefix=/c/gnutools --disable-nls --disable-libssp --disable-shared --enable-languages=c,c++ --with-newlib
make
make install

5.gdbのビルド&インストール
cd /usr/tmp
tar xvf gdb-7.9.tar.xz
cd gdb-7.9
mkdir build
cd build
export PATH=/c/gnutools/bin:/c/Python27:$PATH
../configure --target=arm-*-eabi --prefix=/c/gnutools --disable-nls --enable-gld --enable-gold --enable-expat --with-expat=yes
make
make install

[補足]
 MinGWで"mingw32-libexpat"をインストールしていないと、

checking for libexpat... no
configure: error: expat is missing or unusable

というエラーが出力されます。

 また、使用したgdbのソースバージョンだとmake実行時に、
----
gcc -DHAVE_CONFIG_H -I. -I../../../../gdb/gnulib/import -I.. -g -O2 -D__USE_MINGW_ACCESS -MT rename.o -MD -MP -MF .deps/rename.Tpo -c -o rename.o ../../../../gdb/gnulib/import/rename.c
In file included from ./sys/stat.h:44:0,
from ../../../../gdb/gnulib/import/rename.c:34:
c:¥mingw¥include¥parts¥time.h:65:8: error: redefinition of 'struct rpl_timespec'

struct timespec
^
./time.h:386:8: note: originally defined here
struct timespec
^
make[8]: *** [rename.o] Error 1
----
と出力されました。この問題については、"/c/MinGW/include/parts/time.h"の51行目の、

#if defined __need_struct_timespec && ! __struct_timespec_defined

#if defined __need_struct_timespec && ! __struct_timespec_defined && ! GNULIB_defined_struct_timespec

に変更することで対応しました。
 これは、"struct timespec"が"gdb-7.9/build/gdb/build-gnulib/import/time.h"の386行目で定義されているので、再定義を防ぐためです。

| | コメント (0) | トラックバック (0)

2015/04/12

ubuntuが自動アップデート後に起動しなくなった

 正確には、「起動するが、GUIに画面が切り替わらなくなった(unityが起動しない)」です。
 家人のパソコンでは問題がないので、ググってみると似たような症状の報告がたくさんヒットし、その中の一つ、nvidiaのドライバを、

sudo apt-get remove nvidia*

で削除して再起動することで、unityが起動するようになったので、その後、ドライバを再インストールすることで、とりあえず問題は解消しました。
 ただし、バージョン304だとunityが起動しない現象が再現してしまうので、現在は173を使用しています。
 動いているので深く原因を追求していませんが、どうも、使用しているビデオカードGeForce7300GSと、304の相性が良くないようです。

 以下、試したことのメモ書きです。

・CUI画面でのGnomeのterminalの起動設定
DISPLAY=:0.0 gnome-terminal
・GUIとCUIの切り替え
CUIへ:Ctrl+Alt+F1
GUIへ:Ctrl+Alt+F7

 その他、最初は「unityの問題」と思って、よく考えず、ヒットしたサイトに記載されていたunityのリセットを実行した結果、(当然のごとく)アイコンが初期化されてしまい、元に戻すのが大変でした。自業自得ですが。
 それから、試さなかったけど、nvidiaドライバのコマンドラインからのインストールは、

sudo apt-get install nvidia-[バージョン番号]-updates

らしいです。

| | コメント (0) | トラックバック (0)

2015/02/15

Ubuntuのカーネルのアップデート

 VMware Playerが起動しない問題で、家人のPCも同様の対応を行っている時に、私のPCのカーネルのバージョンと一致しないことに気が付きました。
 "uname -r"の結果は、家人のPCは「3.13.0-45」で、私のは「3.13.0-29」。数字を見る限り、私のPCのカーネルの方が古い。こちらのサイトによると、カーネルのベースは同じだけれどABIが古いらしい。でも、自動アップデートは実行しているし、「なぜ」と思いながら、以前自動アップデートが正常終了しなかった時があったことを思い出しました。
 そのあたりが原因かな、と同サイトを参考に、

sudo apt-get update
sudo apt-get dist-upgrade

を実行しましたが、アップデートされません。
 そもそも、"apt-get update"を実行すると、「W: GPG エラー」「公開鍵を利用できないため、以下の署名は検証できませんでした」と表示されています。この件は、こちらのサイトを参考に解決しましたが、それでも、アップデートされません。

 他に、カーネルをアップデートする方法を調べた結果、"synapticパッケージマネージャー"を使用すれば良いことが分かりました。"synapticパッケージマネージャー"をUbuntuソフトウェアセンターでインストールして起動し、まずインストール済みのカーネルを確認するため、(どこかのサイトを参考に)"linux-image-"と"linux-headers-"を検索すると、imageはないのにheadersがインストールされているバージョンが存在することが分かりました。
 「これが問題だったのか」と、まずは現在のカーネル以外のパッケージを削除して、再起動し、更に最新の"linux-image-generic"をインストールして、無事にカーネルのアップデートを完了しました。

 失敗すると、PCが起動しなくなるので、やや緊張しましたが。

[追記]

 このあと、VirtualBoxで仮想マシンが起動できなくなりました。
 "/etc/init.d/vboxdrv setup"を実行しろ、と表示されたので、端末で実行したところエラーとなります。
 ググったところ、どうもカーネルのヘッダーファイルがインストールされていなかったことが原因のようなので、こちらのサイトを参考に、

sudo apt-get update
sudo apt-get install linux-headers-$(uname -r)

で手動インストールしました。
 その後、"/etc/init.d/vboxdrv setup"を実行することで、仮想マシンが起動できるようになりました。

| | コメント (0) | トラックバック (0)

2015/02/14

UbuntuでVMware Playerのアップデート

 最近は、WindowsXPを起動する機会も減り、たまに使う時もVirtualBoxを利用していたのですが、久しぶりにVMware Playerを起動しようとしたら、

VMware Kernel Module Updater
Before you can run VMware, several modules must be compiled and loaded into the running kernel.

と表示され起動できませんでした。
 「キャンセル」「Install」の2つのボタンが用意されているので、「Install」を実行すればよいのだろう、とクリックしてみたら、インストールらしきものが実行されましたが、

Error
Unable to start services.
See log file /tmp/vmware-root/...

と表示され、また「VMware Kernel Module Updater」に戻ってしまいました。仕方なく「キャンセル」をクリックすると、そのまま終了です。

 困った時には、ググってみる、ということで調べてみたら、こちらのサイトに同様の現象を解決した話が載っていましたので、その内容に従い、

sudo ln -s /usr/src/linux-headers-3.x.x-x-generic/include/generated/uapi/linux/version.h /usr/src/linux-headers-3.x.x-x-generic/include/linux/version.h
sudo vmware-modconfig --console --install-all

を端末で実行したら、

make[2]: *** [/tmp/modconfig-2G4fCF/vmnet-only/filter.o] エラー 1
make[2]: *** 未完了のジョブを待っています....
make[1]: *** [_module_/tmp/modconfig-2G4fCF/vmnet-only] エラー 2
make[1]: ディレクトリ '/usr/src/linux-headers-3.x.x-x-generic' から出ます
make: *** [vmnet.ko] エラー 2
make: ディレクトリ '/tmp/modconfig-2G4fCF/vmnet-only' から出ます
Unable to install all modules. See log for details.

と出力され、うまくいきませんでした。

 14.04にアップしたことが問題なのかと、キーワードに追加してググって見つけたサイトのAnswerに、「特定のLinux上での、VMware Player 6.0.1の問題。6.0.2で解決している」というようなことが記載されていたので、VMware Playerをアップデートすることにしました。
 具体的には、こちらのサイトに記載されている内容に従い、

sudo apt-get install build-essential linux-headers-$(uname -r)
最新ファイルのダウンロード
gksudo bash (ダウンロードしたファイル)

を実行した結果、無事にインストールを完了し、VMware Playerが起動するようになりました。

| | コメント (0) | トラックバック (0)

2015/02/11

Ubuntuで解凍できないzipファイルについて

 Ubuntuで解凍できないzipファイルについての覚書です。

 環境テスト用のUbuntuが必要になったので、ubuntu Japanese Team公開されているVirtualBox用の仮想ハードディスクイメージを使用することを考えました。
 ところが、サイトからzipファイルをダウンロード後、ファイルマネージャーで「ここに展開する」を実行すると、エラーが発生して解凍できません。そこで、「terminal」で"unzip"を実行したところ、"need PK comat v4.5(can do v2.1)"と表示されました。
 その意味を調べた結果、ダウンロードしたzipファイルは、7zipで圧縮したもので、p7zipをインストールすれば解凍できることが判明しました。
 インストールの方法はいくつかあるようなのですが、Ubuntuソフトウェアセンターで、"7 zip"で検索("7"と"zip"の間にスペースを入れる)して、"7-Zip"をインストールするのが一番楽かと思います。

 私は、ググった結果、こちらのサイトを利用しましたが、結局Ubuntuソフトウェアセンターでのインストールでした。

| | コメント (0) | トラックバック (0)

2014/02/09

Ubuntu移行顛末記3 VMware PlayerにWindows98SEを

 前回のエントリーに記載したように、Windows98SEはVMware Playerにインストールすることにしました。
 それは、WindowsXPをホストにしたVMware PlayerでWindows98SEを動かして、ある程度のゲームができることは確認済みだったからです。
 まず、Ubuntu13.10へのVMware Playerのインストールについて覚書。

 VMware Playerの公式ページから「VMware Player 5.0.3 for Linux 64-bit」をダウンロード。
 インストール手順はPlayerのものが公式ページで見つからなかったので、Workstationのインストール手順を確認して、
sudo sh VMware-Player-5.0.3-1410761.x86_64.bundle
を実行すると、インストーラーが起動したので、あとは指示に従って無事インストールを完了しました。

 VMware Playerの仮想マシンへのWindows98SEのインストールについては、今回も他のより詳しいサイトに譲るとして、必要なドライバーは保存してあった(ドライバーについてはこちらを参照)ので、特に問題なく完了しました。
 VMware Toolsをインストールして、以前調べていたdxdiagのDirectDrawのテストをクリアする方法を実行して、さぁゲームをインストールしようとしたら、画面の挙動が変です。サイズを1024☓768に設定すると、一度は指定サイズになるのですが、ゲストを再起動すると設定した画面に戻りません。どうも、VMware Toolsで有効になる「ウィンドウサイズに合わせて自動的にゲストの解像度が変わる機能」が、Ubuntu13.10がホストの場合にはうまく機能しないようです(WindowsXPがホストの時には問題ありませんでした)。
 そこで、VMware Toolsはアンインストールすることにしました。ただ、ビデオカードとマウスのドライバーは使用する(ビデオカードのは必須ですが、マウスのはホストとの行き来が楽になるだけなのでなくても良い)ので、バックアップをとっておき、VMware Toolsをアンインストールした後、ドライバーを更新しました。
 これにより、目的の環境を構築することが出来ました。

| | コメント (0) | トラックバック (0)