ターゲット基板開発環境一覧

Raspberry PI 2 が到着しました(&虹色な謎四角)

先日に発売になった Raspberry PI 2 が手元に到着しました。
ARM v7 の 4コアになったことと、Windows10 の話があったことでつい購入に踏み切ってしまいました。
定番の Raspbian をインストールして、思ったよりもサクサクとシステムが動いて、「お、やるな」と思っていたのですが、なにやら画面の右上部に変な虹色の四角が緩やかな点滅をしていることに気づきました。

rainbow_square_pi2

まだあまりメジャーな情報じゃないのか、検索に引っかかり辛かったのですが、友人にこの謎を教えてもらいました。
なんと、電源電圧の閾値低下によるものだそうです。
参考: https://x1japan.wordpress.com/2015/02/20/rpi-what-is-right-up-square/

というわけで、太めのケーブルやマザーボードからの直結に変更してみたところ、この謎の虹色四角は消すことができました。
虹色の四角が表示されている環境では SDカードのアクセスが妙に不安定なことがあって、それもこの電源の低下が招いていたのかなと思います。今のところは消えている状態では安定しているように思います。

追記

プログラムをコンパイルしたり、WiFi アダプタをつけた場合には虹色四角が復活してしまいました。やっぱりちゃんとACアダプタ経由で電源とらないとダメかもしれません.


Eclipse から Jetson TK1 へのリモートデバッグ(Luna編)

今までは eclipse に Indigo を用いていましたが、 Kepler では同じ設定ができようできないとコメントをいただきましたので、 eclipse のバージョンを引き上げて Luna にて同じことができないか検証してみました。ある意味で、ARMのプログラムを作成してデバッグする 第5回の続編、 第6回みたいな感じになってます。

設定についての詳細な内容は以前の記事のほうを参照してください。ここでは Luna によってどのあたりの変更が必要になるのか、という点で記述しておきたいと思います。

設定方法

必要なツールチェインへのパスは通っている&準備が完了しているという前提で話を進めます。
従来の “Standard Create Process Launcher” の代わりに、 “Legacy Remote Create Process Launcher” を選択します。

luna_remotedbg_select_launcher

あとは Debug Configuration の設定を以下のように設定していきます。
このあたりは従来のものと変更がないように思いますが、念のためスクリーンショットを示しておきます。

luna_remotedbg_main
luna_remotedbg_debugger

これらを設定した後で、デバッグ実行させてみた状態が以下のようになります。
うまくステップインできて変数の値も確認できています。
luna_remotedbg_image

まとめ

とりあえず Legacy Remote Create Process Launcher が使えれば、ほぼ同様の手順でリモートデバッグを構築できることが確認できました。ただ標準の GDB(DSF) Automatic/Manual Remote Debugging Launcher を用いては今のところ成功させることができませんでした。


MIPS Creator CI20 で OpenGL 使えるようになった

以前に試したときには OpenGL 2.1 がまともに使えなかったのですが、 2015/01/15 に公開されたベータバージョンのイメージからは使用可能になったようです。

以前のものは OpenGL 2.1 対応といいつつもなぜかそれ以降の拡張も使用可能であるとAPIの結果は返ってきたのですが、今回改めて確認してみると正しい範囲になったような感じです。

基本的には OpenGL 2.1 の必須+浮動小数テクスチャへの書き込みサポート&MSAAのレンダーターゲットを使用可能といった範囲になっているようです。以前使えるように見えたインスタンシングやジオメトリシェーダーが使えなくなってしまった点は残念な気がします。

イメージを適用する

基本的には配布サイト(http://www.elinux.org/CI20_Distros) から該当イメージをダウンロードし、SDカードに dd コマンドを使って書き込んで、 MIPS Creator CI20 に差し込んで eMMC の内容を更新という手順で OK です。
 ただなるべくなら eMMC を常用したくないので SDカードからの起動および通常使用としたいところです。そこで入手したイメージから起動SDを作る方法を示したいと思います。

起動SDを作るためには、以前の記事内容(MIPS Creator CI20 を SDカード起動にする)を参考にします。
この説明の課程で出てくる uImage をどのように作るかが今回は問題になりますが、 rootfs2015-01-15_16_49_47.tar の中に含まれている /boot/vmlinux.img をその uImage の代用とします。それ以外は同様で、以下のコマンドのようにしてSDカードを構成します。

# ./make-flash-card-ci20-sd.sh /dev/sdX vmlinux.img rootfs2015-01-15_16_49_47.tar

問題なければ、書き込んだSDカードで起動できると思います。 SDXC の 64GB のものを使用しましたが、速度は出ませんがうまく動いているようです。

コンパイラ

今回の 20150115 版のカーネルおよびイメージでうまく動くことが確認できたので、クロスコンパイラを作り直すことにしました。
MIPS Creator CI20 用の環境としてクロスコンパイラは整備されていないようだったので、 Ubuntu 用, MinGW 32bit/64bit 用として3種類のアーカイブを用意することにしました。
こちらのページで配布していますので、必要な方はこちらからどうぞ。


クロスコンパイラ (MIPSCreatorCI20 / Jetson TK1)

生成したクロスコンパイラのアーカイブを置いておきます。
不具合等があるかもしれませんので、使用する際には自己責任でお願いします。
シンボリックの解決の問題で、 tar アーカイブを展開する際にエラーメッセージが出るかもしれませんが、問題ないかと思っております。

Jetson TK1

Ubuntu 上のクロスコンパイラはメーカーが公式に用意してくれているため、生成していません。

MIPS Creator CI20

補足

これらのコンパイラは crosstool-py というツールを用いて、Ubuntu 上で作成しております。
また MinGW 版は Windows7 SP1 にて動作確認を行っております。


MIPS Creator CI20 を SDカード起動にする

MIPS Creator CI20 には eMMC があり、ここからデフォルトでは Debian が起動するようになっています。しかしご存じの通り書き換え回数問題があるため、出来るだけ SDカードなど交換がきく外部ストレージからブートさせたいと思います。
今回、それがうまく出来たので手順を記事化しようと思いました。

必要なもの

  1. UbuntuなどのLinux環境。仮想マシンでも可。
  2. 上記の環境で使えるカードリーダー。SDカードの書き込みを行います
  3. MIPS用のクロスコンパイラ

手順

Ubuntuで作業することを想定しています。まずは必要なツールをインストールします。

https://github.com/ZubairLK/ci20_other_files のリポジトリをクローンして、作成のためのスクリプト等を取得します。

この中に、工場出荷状態のカーネル(uImage_ci20_production_20140625)も含んでいるので、まずはこちらを利用させてもらいます。
そして、elinux.org から取得できる rootfs-20140625.tar をダウンロードしておきます。

そろったら、dev以下にアクセスするので root で作業します。とはいっても便利なスクリプトなのでやることは以下のように簡単な手順です。
環境変数ではクロスコンパイラのプレフィックスやパスを設定しています。

うまくいけば書き込みが成功します。エラーが出た場合には足りないものをインストールなどして下さい。

MIPS Creator CI20 に書き込んだSDカードをセットして、ジャンパーピンをSDカードからのブートに切り替えて下さい。
この状態でリセットして起動させると SDカードから起動してくると思います。物によるとは思いますが、結構遅いです・・・。

起動してディスク容量などを確認してみると以下のように明らかな差異を確認できました。
sdboot-debian-ci20


MIPS Creator CI20 用Mingw版クロスコンパイラ

先日のものでは Hello,World 程度のコンソールアプリでは問題なかったものの、他のライブラリをリンクした際に正常に処理できなかったので、早速クロスコンパイラ関連を作り直しました。

今回の物も完全とはいえないのですが、まだ使えるようになったと思うのでここに公開したいと思います。

使い方・注意点

適当な場所に展開して下さい。デバッガーとしての gdb が少々怪しく、 eclipse からは mipsel-unknown-linux-gnu-gdb_for_eclipse を使用し、コンソールでがんばる方は mipsel-unknown-linux-gnu-gdb を使うようにしてみてください。なぜか後者の方は eclipse からうまく扱えなかったので・・・。またデバッグ時にはターゲットの lib らの情報が欲しいようなので、 sysroot ディレクトリを gdb の set sysroot で設定してあげるようにしてください。

なお、本ツールを用いての不具合等については当方で責任は負いかねますので、その点をご了承下さい。

ダウンロード

前回の公開記事のほうでリンクを張り直しました
新ファイルイメージ公開のため、クロスコンパイラの作り直しを行いました。こちらのほうをご参照ください「クロスコンパイラ (MIPSCreatorCI20 / Jetson TK1)

補足

今回のクロスコンパイラを用いて、簡単な OpenGL ES 2.0 のアプリケーションを Windows で作成して実行してみました。ターゲットに含まれていた各ライブラリをリンクして無事にアプリができたことを確認してみたつもりです。

ci20_gles20

なお CI20 では一見、普通の OpenGL が使えるようにライブラリが含まれているように見えましたが、実際のところは glCompileShader 関数で Segmentation Fault してしまいます。 OpenGL ES 2.0 で処理を記述すれば問題なく glCompileShader も正常終了しました。


ようやくクロスコンパイラ出来た

ここ最近ひたすらクロスコンパイラの準備に励んでいた理由の1つに、Imagination Technologies の Creator CI20 が手元に届いたから、というのがありました。そしてようやくですが Linaro の環境を真似して、 Creator CI20 用の環境を準備してみました。うまく動かない部分もあるかもしれませんが、ひとまずは下記に示すように Windows 環境での開発が出来そうなところまで到達出来たと思います。

ci20-on-eclipse

eclipseの基本的な設定は、Jetson TK1のときと同様の手順で行ってあります。1点違うのは今回は .gdbinit ファイルを作成したことです。この gdbinit ファイルの中では、 CI20 から取り出した include, lib らなどの場所、いわゆるsysrootの設定が記載してあります。

これらのビルド済みツールチェインを以下の場所で公開してみます。また使用しているCI20用のsysrootらについてもこのツールチェインの中に含めてみました。
eclipse らで使用する際には、このsysrootを指すように gdbinit を設定してください。

Download for MIPS Creator CI20 Toolchains(Pre-Built)


Download (ci20_mipsel-unknown-linug-gnu_mingw32.tar.xz)
上記の場所にファイルをおいてあります。


新ファイルイメージ公開が公開されたため、クロスコンパイラの作り直しを行いました。こちらのほうをご参照ください「クロスコンパイラ (MIPSCreatorCI20 / Jetson TK1)

不具合とかあっても対処できませんので、利用は自己責任でお願いします。

蛇足的メモ

結局 crosstool-ng の中でカナディアンクロスでコンパイラを作成しました。これでもクロスの gdb 作成過程で expat のライブラリが見つからないとかでエラーになる始末で、最終的にはあきらめました。結果、MinGW の環境で gdb だけはクロスターゲットのものを make して同梱する形にしました。強引な感じで心配ですが、とりあえず動いているようなので様子見です。

カナディアンクロスの際には単に build, host, target を指定するだけでは終わらず、ビルドホストからhost, target の両クロスコンパイラがまずは必要になるようです。そのため linux -> mips, linux -> mingw32 といったツールチェイン&コンパイラを作成してから作業しました。今回の場合では linux -> mingw32 のクロスコンパイラを基盤に使用していくことになったので、これもまた crosstool-ng にて生成させることにしました。

外部ツールに頼ってしまっていますが、ようやくやりたいことが実現したので満足です。より詳細な内容は今回の手順の中身を追っていけば把握できるでしょうし、そのうちこの中身を手作業で追いかけてみたいなとは思います。


ARMのプログラムを作成してデバッグする 第5回

前回でボタン1つでリモートデバッグが開始できるところまで到達して完結したのですが、友人からSftp使えない環境では使えないと指摘を頂きました。今回はそれに対処してみようと思います。

sftpが封じられている場合でも ssh,scp らは利用可能であることが多いです。そのためこれらを用いる方向で対処します。eclipse に Remote System Explorer をインストールしましたが、これのさらなるオプションで scp を使える物があります。「RSE SCP File Services(Incubation)」とプラグイン名はなってます。
 これを今まで作成してきた環境にセットアップすると、sftpの代わりに scp を使用して実行体を送ってくれるようにできます。注意事項としては Remote System Explorer 本体とのバージョン整合性を取ってあげることです。間違ったバージョンを入れるとこのSCPプラグインが見えないようです(自分の場合はそうだった・・)


cygwinでクロスgccのmakeは出来たが・・・

クロスコンパイラを自力でビルドしたいという、同じような病気に既にかかっている方がいらっしゃるようで、その情報が非常に参考になりました。こちらを参考にして自分もまたクロスコンパイラ gcc の make に勤しんでいます。

世の中のいろいろな情報により gcc の make は出来るようになっていますが、上記で掲載されている生成用のスクリプトがかなり勉強になります。スクリプトの動作は Ubuntu 14.04 にて確認してうまく動いたので、これを元に cygwin で作業してみることにしました。

先日の日記にあるように、 eglibc 2.13 や gcc については、 cygwin 環境ならではの問題点があるのでこれらについてパッチを当てる形で上記のスクリプトに改良を加えてみました。

この結果、 cygwin 環境でもうまく gcc が生成させることが出来、待望の「スレッドモデル: posix」と表示されるクロスコンパイラ gcc となりました!

今確認出来ているものの構成要素は以下の通りです。

  • gmp-4.3.2
  • mpfr-2.4.2
  • mpc-0.8.1
  • binutils-2.21.1
  • gcc-4.5.3
  • eglibc-2.13
  • linux-3.0.45
  • target: arm-none-linux-gnueabi

しかしながら・・・

これで一応 cygwin の中で クロスgcc がスレッドモデルが posix となるところまででき、また elf バイナリが出力できるところまでは確認できました。しかしながら、いざターゲットに持って行くと正常に実行できるバイナリになっておらず・・・。まだ完成とはならなかったようです。

クロスコンパイラ gcc の完成はターゲットでちゃんと実行できる物ができて、初めて完成といえるのでまだちょっとかかりそうです。欲を言えば、デバッグがちゃんとホストでできるように gdb も準備できるまでが、環境構築のフェーズですね。まだまだかかりそう・・・。


クロスコンパイラgcc作成に再びチャレンジ中

クロスコンパイラ gcc を作成したい!という病気に再びかかってしまいまして、リトライ中です。色々と試行錯誤の結果 Linux 環境下では何となくうまくいくようになってきまして、現在最終目標である Windows 環境下で動く gcc を作りたいと思って作業中です。
 このとき、まずはと思って cygwin を使用しているのですが、結構これが罠でした。 cygwin がというよりは Windows の標準の挙動がマズイ点もあるんですが次のような問題に出遭ってしまいました。

cygwinで eglibc, gcc をビルドするのに致命的だった点

.os, .oS という中間ファイルを生成していた点で windows が通常大文字小文字を区別していないため、同一ファイルとして扱ってしまうこと。これを回避するために、.oST として Makefile らを修正する必要がありました。
結構有名な話のようで、 glibc でも同様だとか。これらについてはパッチが出回っているのでそれを適用すれば OK な模様です。
なお、 eglibc の cygwin ビルドについては、他にもまだ修正箇所があるのでこれもまたパッチを適用して回避します。

cygwin 用のパッチが不十分で、まだエラーが出ることがあります。そのため、以下のようにソースコードに修正を加えて対処します (diff形式で出しておきます) 。自分の場合では、 rpc/types.h が見つからない!というエラーが出ました。

そのほかにも gcc 4.5.3 の make では問題が発生しました。自分の環境も影響しているかもしれませんが、 gcc のビルドステップ3番目の箇所で libstdc++ の作成箇所でコンパイル内部エラーが発生してしまいました。
これについては、どうやらプリコンパイル済みヘッダの挙動が影響しているらしく、 cygwin 環境時には使用しない方向で、 –disable-libstdcxx-pch オプションをつけることで対処してみました。

gcc の make ってやはり大変です。 cygwin という環境も手伝ってなおさらです。