「 Jetson TK1 」一覧

Jetson TK1 を USB メモリ起動にした記録


Jetson TK1 で USB HDD を使用して起動させたいとのコメントがあったので、とりあえず USB メモリを代用としてこちらから起動する方法にトライしてみました。
今更 TK1 という感じもありますが、 Jetson TX1 は性能がよくてほしいところではあるんですが価格ネックですね。
jetsontk1_with_usb
今回の作業は Windows 上に VMware Player で構築した Ubuntu 15.10 環境で作業しています.

続きを読む


Jetson TK1 で USB WiFi ドングルを使う


以前 RaspberryPI で USB WiFi ドングルの話を書きましたが、同じものを Jetson TK1 で使えるのでは?と思って試してみました。

予想外にも、装着して起動してみても wlan0 のインターフェースは出現しませんでした。よくよく見るとドライバっぽいものはロードされており中途半端な感じです。
起動ログを確認すると rtlwifi/rtl8192cufw_TMSC.bin がロードできない意が出力されており、確かにファイルがフォルダごと存在していませんでした。

http://elinux.org/Jetson/Network_Adapters の部分を確認すると USB WiFi アダプタとしては使用可能な部類になっています。しかし丁寧にこの表の下部を読んでみるとそこにダウンロード先が書いてあります。 rtl8192cufw.bin.zip というものです。

このファイルをダウンロードして展開すると、見事に rtl8192cufw_TMSC.bin があるので、これをドライバが期待するパスに配置してあげます

これで再起動すると無事に wlan0 が使用可能状態となり、ネットワークが使用可能となりました。

またパワーマネジメント関連も同じようにあるのか?と確認したところ、
/sys/module/rtl8192cu/parameters の中にはそのような項目が存在しませんでした。
ただしばらく放置してみて、外部からTK1に向けて ping を打ってみると反応しませんでした。同じような気配です。対処する方法についてはまだ見つかっていません。

今回の件とは違う話になりますが、JetsonTK1はシステム全体がもっさりとしている気がします。Raspberry PI ではその重さとかは感じませんでしたが、同じディストリビューションではないですし、簡単に比較はできません。(Ubuntu vs Debian ですし)
RPI2が非力なことを自覚しておりそれに合わせたディストリビューション選択、および、コンポーネントの導入をしているため自分の思っていた以上に軽快に動いていた感なのかと思っています。


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 を用いては今のところ成功させることができませんでした。


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


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

Jetson TK1

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

MIPS Creator CI20

補足

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


Jetson TK1 のSDカード起動について


maker faire tokyo 2014 にて購入した Jetson TK1 @NVIDIAケース付き での話になりますが、 SDカードからの起動において若干問題がありそうです。もしかしたら製品バージョン関係ないのかもしれませんが。

その問題とは、 SDXC のカードではうまく起動できない、という点です。たまーに起動成功したりもするようですが、条件を特定できませんでした。失敗の時にはコンソール画面で何らかのエラーコールスタックがつらつらと表示されていました。

SDXCカードのメーカーによるものかと2社ほど試してみましたがどちらもダメで、 SDHC のものなら大体のメーカーのものでもうまくいくような感じでした。試したものは 21.2 のバージョンの L4T です。もしかしたらそのうち U-BOOT なりカーネルなりのバージョンが更新されて、 SDXC を気にしなくても夜なる日が来るかもしれません。今のところは、 SDHC あたりのカードを想定しておくと余計なトラブルに巻き込まれなくて済むかなと思います。


あけましておめでとうございます


2015年明けましておめでとうございます。今年も本ブログをよろしくお願いいたします。
折角なので、福袋的なものを用意してみました。 MIPS Creator CI20 用、Jetson TK1 用のクロスコンパイラのアーカイブです。
Ubuntu で作成しましたが、 Ubuntu 用と Windows MinGW (32bit) 用の2種類準備してみました。


Download Jetson TK1 GCC 4.8 for Linux (465MB)
Download Jetson TK1 GCC 4.8 for MinGW (582MB)
Download MIPS CI20 GCC 4.8 for Linux (279MB)
Download MIPS CI20 GCC 4.8 for MinGW (376MB)

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

不具合等残っているかもしれませんが、よろしければご利用くださいませ。


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 という環境も手伝ってなおさらです。


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


前回まででコードのクロスコンパイルをeclipse上で行うところまで出来たので、今回はデバッグについて設定を行っていきたいと思います。ターゲット上で動いているプログラムに対するデバッグとなるので、リモートデバッグを設定するという感じになります。

gdbserverを手動で起動する系

まずはターゲットでgdbserverを手動で動かして、そこに eclipse が接続を行う、というタイプで設定してきます。どこに問題があるか切り分けるためにも、まずはここから設定します。ワンタッチでリモートデバッグという点については後半で説明します。

コンパイル後出来上がったターゲット用のelfファイルをターゲット(実機)へ転送します。デフォルトだとDebugフォルダ以下に出来ていると思います。 Remote System Explorer パースペクティブを開いて、そのファイルを sftp 経由でターゲットの適当な場所へコピーします。
ここでは、 Jetson TK1 ターゲット標準ユーザーである ubuntu ユーザーのホームにプログラムを送ることにしました。
エクスプローラーからファイルを Remote Systems タブ内へのドラッグアンドドロップで任意の場所に転送できます。( eclipse 内でファイルのD&Dする方法はちょっと見当たらず・・・)

ターゲットでの操作

プログラムを転送したら、ターゲットでgdbserverでそのプログラムを実行します。
eclipse の Remote Systems から ssh Terminal を起動して操作するか、ターゲットのキーボードをたたいてコマンドを実行して下さい。
初回の転送後はファイルが実行属性が付いていないので、それも設定する必要があります。

実際に待っているとこうなります。
waiting_gdb

eclipseのデバッグ設定

この待ち受けしているターゲットに対して、gdb接続をするための設定を行っていきます。
プロジェクトを右クリックして、 Debug As / Debug Configuration を選んで、設定画面を出して下さい。

そして、「C/C++ Application」を選んで、 New Launch Configuration ボタンを押してコンフィグを作成します。作成すると以下のような感じになると思います。

debug_configuration_1

そして、画面下部のほうにある 「Using GDB(DSF) Create Process Launcher – Select Other 」 のリンク部分をクリックして、次のように設定します (Standard Create Process Launcher を選択)。

standard_create_process_launcher

次に、Debuggerタブを開きます。そして以下の設定に変更します。(Standard Create Process Launcher を選択しないと以下の設定ができないんです)。

  • Debugger: gdbserver
  • GDB Debuger: D:\Linaro\gcc-linaro-arm-linux-gnueabihf-4.8-2014.04\bin\arm-linux-gnueabihf-gdb.exe

debugger_tab_gdbserver

上記を見てわかるとおり arm-linux-gnueabihf-gdb.exe のフルパスが入っています。ここは各自の環境に合わせて修正してください。

この中の「connection」タブを開き、以下のように設定して下さい。

  • Type: TCP
  • IP Address: ターゲットのIPアドレス
  • Port Number: 2345

これらの設定が終わったら、Apply ボタンを押して、Debug ボタンを押してデバッグを開始します!!
うまく設定ができていれば以下のようにブレークポイントを設定したところで停止します。
eclipse_debugbreak

全てを自動で!ボタン1つでリモートデバッグを開始

今までのものがうまくできていれば、もう後一歩で手軽なリモートデバッグができるようになります。ここで実現することは、ビルドしたファイルを転送し、 eclipse のデバッガ操作を受け付けるようにする、といったものです。すなわち前章で手作業をした部分ですね。

ターゲットの設定

今回は特に必要ありません。gdbserverがパスの通った場所に配置されていればOKです。

eclipseの設定

先ほどと同じですが、デバッガ設定の部分が異なります。ですので、Debug Configurationの画面を開きます。

今度は「C/C++ Remote Application」を選んで、 New Launch Configuration ボタンを押してコンフィグを作成します。作成すると以下のような感じになると思います。

debug_configuration_remote_1

ここで先ほどと同様に、画面下部のほうにある 「Using GDB (DSF) Automatic Remote Debugging Launcher – Select Other 」 のリンク部分をクリックして、次のように設定します ( Standard Remote Create Process Launcher を選択)。
debug_configuration_remote_2

すると戻ったときに画面が変わりますので、以下のように編集します。基本的には、以前に作成した接続情報を選択したり、実行体バイナリを配置するパスを記入したりといったことになります。

debug_configuration_remote_3

みてわかるとおり、実行前の処理で実行属性をつけています。続いて、Debugger タブを開いてさらに設定をおこないます。
基本的には、さきほどやったように使用する gdb のフルパスを入れたり、プロトコルを設定したりします。

debug_configuration_remote_4

ここでプロトコルを「mi2」に指定してます。これがポイントで、 default, mi1 とか設定の場合、自分の環境ではうまくデバッグ接続を確立できませんでした。

設定が終わったら、 Apply ボタンを押して、 Debug ボタンを押して、リモートデバッグを開始します。うまくいけば以下のようにブレークポイントで停止した状態になると思います。

debug_configuration_remote_result

まとめ

ようやくボタン1つでリモートデバッグができるところまでたどり着けました。しかも基本 Windows 環境なので、通常Windowsを使っているユーザーには開発の敷居が低くなった、と自負しております。 VMPlayer に Ubuntu などの Linux 環境を入れてそこで開発するスタイルに比べれば、動作が比較的軽いと思いますし、その点でも環境はよくなったと思います。
今回、makeの都合で若干MinGWのお世話になってしまいますが、それでも cygwin よりはまだWindowsよりといっていいと思います。cygwin でコンソールでがんばって開発するスタイルもまたアリだと思いますけど、やっぱりデバッギングは GUI が色々とあった方が効率よいですしね!

今回は Jetson TK1 で行いましたが、他のターゲット(Raspberry PIや類似基板、他のボードなど)でも、そこそこ同じ手順で環境実現出来るんじゃないかと予想しています。またそれらのものを触る機会があったらご報告したいと思います。やってみた方のコメントもまた募集しておきたいと思います。