愛用していたAgilentのオシロが壊れてしまいました。
久しぶりに電源を入れたら、ボタンに埋め込まれたLEDが一瞬だけ点灯して消灯します。
画面は映りません。
Keysightのサポートに修理依頼をしてシリアル番号を伝えたら、「2019年10月まで保証期間がありますから、無償で修理いたします」と折り返し電話が来ました。保証書をなくしてしまったのに、メーカーさんのほうでシリアル番号から調べてくれたようです。
しかも、サービスマンの方が事務所まで引き取りに来てくれました。
まさに、神対応！
次もAgilentを買いたくなります。
HTML5で動くオシロアプリをリリースします。
当面の間は、Cosmo-Z Mini用です。
なぜならば、Cosmo-ZにはADCの分解能や電圧フルスケールの設定を機器ごとに記録しておく仕組みがまだないからです。
Cosmo-Z Miniなら14bit精度で±0.5Vフルスケールと決めてあるので、そのスケールに合うようにプログラムをハードコー＠℃してしまっているからなのです。
アップデートのやり方はとても簡単です。
下記のページにある
http://www.cosmoz.jp/update.html
update-cszminiというファイルを作り、実行するだけです。
今年出荷したCosmo-Z Miniはupdate-cszminiは/rootに入っているので、起動したら/root/update-cszminiを実行するだけでOKです。
root@cszmini:~# /update-cszmini
Check and download system firmware...
Check and download libraries...
Check and download Web interface update...
Check and download project source.
アプリケーションをアップデートしました
BOOT.BINを置き換えますか？
実行する場合は yes と入力して下さい.
ここで何も書かずにENTERを押す
更新は行われませんでした。
これでWebSocketの波形サーバやライブラリなどがインストールされ、システム起動時に自動的に実行されます。
ユーザはhttp://cszmini/にアクセスするだけで、現在の波形がすぐに見られるようになりました。
ZYNQ+高速ADCで動くHTML5 Webオシロアプリで、時間軸スケールと、プレトリガの長さ変更できるようにしました。
下の図は正弦波。80MHzでサンプリングしていることが画面真ん中の上に書かれています。
時間軸スケールを変えて長時間見ていくと・・・
サンプリングレートが切り替わります。
どうせWebの画面は横1000ピクセルくらいなので、何万ポイントも送っても表示しきれません。
確かめたところ、WebSocketのライブラリ「libwebsockets」では巨大なデータを送信しても問題なく転送してくれるようですが、長時間(といっても100μのオーダーでも)見る場合には自動的にサンプリングレートを下げてデータ量を削減するようにしています。
だんだんオシロっぽくなってきたぞ。
今まで難解だったCosmo-Zの使い方が滅茶苦茶わかりやすくなって、我ながら驚いています。
やはり計測ツールのユーザインタフェースは標準的な「オシロスコープ」に似せて作るのが一番良いですね。
オシロ互換UIなら説明書がいらないし。
昨日、トリガをWebから操作できるようにしたのですが、カクカクとうごいてスムーズではありませんでした。
Chromeのログを見てみると、頻繁にWebSocketが切れている模様です。
信号が入らなくてトリガ待ちになっている状態で、別のコマンド（例えばトリガ設定）が入るとこのように接続が切れるということがわかってきました。
おそらく、libweboscketsがWRITEの処理中に次のパケットを受信すると、受信したコマンドを保持している変数が書き変わってしまうのでしょう。私のプログラムの作り方の問題です。
そこで、即興でキューの仕組みを作って、受信したコマンドをキューに入れて順番に処理するようにしたら解決しました。
これでトリガ電圧を変更しても接続が切れることなく、スムーズにできます。
Cosmo-Zで動くHTML5 Webオシロ(仮称)で、div/Vとoffsetの下に、チャネルごとのトリガ電圧の設定やカウントレートの表示ができるようにしました。
また、トリガのAUTO/NORMAL/SINGLEが使えるようにした。
また、見たいチャネルだけを絞れるON/OFFボタンが動くようになったので、波形がごちゃごちゃしてきたのをすっきりとさせることができるようになりました。
HTML5 Canvasのオシロアプリの画面がだんだん出来上がってきた。
まず、目の前にある本物のオシロを参考に画面の配色を変えました。
div/vの文字は、Run/Stopのボタンは昨日作成した自前のライブラリで作ったオブジェクトになっています。
Canvasのテキストを適当に書いているのではなく、見えないけどオブジェクトという殻で包むことができました。
CanvasObjects.draw()とやると、すべてのオブジェクトがforEachでひとつづつ再描画されていきます。
CSSなんて使わずに直接絵で描いている。
それなのにマウスのボタンを押せばちゃんとイベントが発生します。
ここまではうまくいった。
HTML5でオシロアプリを作ろうとしていたのだけど、ステータス表示とかボタンとかツマミ類をCSSで作るのは面倒なので、HTML5 Canvas上で「オブジェクト」を描画したり動かしたりするシンプルなGUIライブラリを作ることにしました。
一応、下の箱の中にテキストが書かれたやつは、マウスでつまんで動かせます。
何度目の車輪の再発明だろうか。
回り道のように感じるけど、これがきっと一番の近道だ。
電圧レンジやオフセットをcookieに保存するようにしました。JavaScriptでライブラリを使わずにCookieをベタに書いています。
何が嬉しいかっていうと、ブラウザを再読み込みしても設定が保たれるようになったことです。今まではF5を押すと電圧の設定などが毎回初期化されてしまっていたのでストレスがたまりましたが、これで気兼ねなくF5を押せます。
それから、オシロの画面によくある「0Vを示す矢印」を出すようにした。これで電圧が画面上で読めるようになった。
まだ時間軸拡大は苦手です。送ってくるデータ数を減らすことで拡大はできますが、そのたびにWebSocketのサーバ側ソフトを直さなければなりません。
いい感じに仕上がってきました。
次は時間軸を攻めるか、トリガを攻めるか。
HTML5 Canvas+WebSocketで動くブラウザオシロアプリで、波形下の「電圧/div」や「オフセット電圧」の部分をマウスでホイールすると、電圧レンジやオフセットの調整ができるようにしました。
Cosmo-ZのWeb波形表示画面が、オシロの操作性に近づいてきた。
どうやっているかというと、CanvasのonMouseMoveというイベントが起きたときにコールされる自前の関数で、マウスの座標がテキストを書いた座標の上にあるならば反転表示させるとか、ホイールされたらされたどのTextの上かというのを座標で調べて、該当するCHの「電圧/div」を切り替えることをやっています。
BorlandのVCLやC#の.NETではあたりまえのように動いているイベントの仕組みをゼロから作り直しています。
こういうのを車輪の再発明といって、無駄な努力というのかもしれません。Web界隈のライブラリを探せばいくらでもあるのでしょうが、自分で全部作ることにします。
「Cosmo-Z」でWebSocketのサーバを動かして、ADCで取得した波形をリアルタイムで転送してブラウザにHTML5 Canvasで描画することに成功しました！
上の図はNaIシンチレータで何らかのイベントが起きたときの波形です。
それをWebSocketで転送し、ブラウザのJavaScriptでCanvasに描いています。
毎秒230回以上の画面更新ができます。オシロに一歩近づいた。
そろそろCosmo-Zの開発を再開することにしました。
ハード(FPGA)からブラッシュアップするか、ソフトからブラッシュアップするか悩んだのですが、ソフトから直すことにしました。
目標は、
を目指します。
Cosmo-Zはただの高速ADCデータ収集装置ではなく、FPGAを積んでいるのが特徴です。そのFPGAで信号をリアルタイムに処理したり、イベントが起きたときだけ信号を保存するということができます。
そこでまず行ったのは、イベントキャプチャのプログラムの作り直しです。
今まではcosmoz.elfという1つのELFファイルに、ADCのリセットから、信号のキャプチャ、FFT、波形ファイルの扱いまですべての機能を詰め込んでいましたが1つ1つの機能を分離した、シンプルなツールを作ろうと思うわけです。
Cosmo-ZにNaIシンチレータをつないで10秒間の波形を取ってみました。
僅か10秒でも、ADCの波形を生で保存すれ1600Mバイトになりますが、イベントが起きたところだけを取っているので1.5Mバイトにしかなりません。しかもテキストファイルで1.5Mバイトです。バイナリにすれば4分の1に減るでしょう。
これをExcelで波形にしてみると、10秒の間に大小さまざまなイベントが起きたことがわかります。
1.99秒付近のものを拡大してみます。
イベントが起きたところだけを記録して、イベントが起きていないところは記録しない、というわけなのです。
8月15日は終戦の日。靖国神社へ行って参りました。
神社の中はこんな感じ。
神社の外はこんな感じ。
この日の丸を持った大行進は、穏やかで紳士的なデモ。
こっちは、反天連に対するカウンターデモ。
この後、天皇制に反対する集団が九段下の交差点をデモ行進するので、クレームの声を聴かせるというイベントが行われるそうです。
8月14日。銀座で反日デモに遭遇しました。
「「慰安婦」メモリアル・デー」というもので、主催者発表によれば参加者は250人とのことですが、そんなに人はいない。
せいぜい50人くらいで、日本人は半分くらいのように見えた。
いわゆる慰安婦デモなのですが、カメラを持ったマスコミっぽいのも来ていました。
SBS？どこの放送局？
このロゴは韓国の放送局でそういうのがSBSね？
でも、カメラはSONY製、レンズはCANON製。
不買運動しているんじゃないのか？
それに、安倍を監獄へとか書いたり、DHCもを一方的にヘイトと決めつけているてるコイツらのプラカードこそ、ヘイトスピーチである。
自分のアプリを作りたいわけですが、まずはlibwebsocketsのサンプルプログラムを見てみます。libwebsockets\minimal-examples\ws-server\ 配下のディレクトリにサーバ側のサンプルプログラムがたくさんあり、何が何だかわかりにくいのですがminimal-ws-server、minimal-ws-server-echo、minimal-ws-server-pmdあたりを参考にしました。
要約すると、libwebsockets(以下、LWSと略す)のプログラムは、
struct lws_context_creation_info info;
という構造体を作り、そのinfoの各種パラメータを設定して、
struct lws_context *context = lws_create_context(&info);
を作ります。
そして、
lws_service(context, タイムアウト[ms]);
でサーバを起動します。
基本的にコールバックで動いていて、コールバックされる関数は
info.protocols = protocols;
でprotocolsという構造体の中にプロトコル名やバッファサイズと共に格納されています。
{ \
"protocol-name", \
callback_func, \
sizeof(struct per_session_data__minimal), \
128, \
0, NULL, 0 \
}
そして、このプロトコルは1つのサーバのポートに複数登録できます。例えば、HTTPと、独自のWebsocketプロトコルの2つという具合にです。
コールバック関数は以下のようなプロトタイプをしています。
static int callback_func(struct lws *wsi, enum lws_callback_reasons reason,
void *user, void *in, size_t len);
wsiというのはすべての情報が詰まったハンドルのようなもの。reasonがコールバックが呼び出された理由です。
処理するべきreasonは
です。LWS_CALLBACK_PROTOCOL_INITは最初に呼び出され、lws_protocol_vh_priv_zalloc関数を使ってプロトコルごとに必要なローカルのメモリを確保します。リングバッファを作成したりするのもここです。LWS_CALLBACK_ESTABLISHEDは、通信のセッションが貼られると呼び出されます。
クライアントから何かデータを受信するとLWS_CALLBACK_RECEIVEが呼び出されます。inにlenバイトのデータが入っているのでmemcpyか何かして取り出します。
サーバからクライアントにデータを送るにはlws_write()を使うのですが、この関数はLWS_CALLBACK_SERVER_WRITEABLEの中で呼び出すようです。
つまり、何かのデータを受信して、それを処理してクライアントに応答を返したいという場合、RECEIVEの中で送信関数を呼び出すのではなく、次に送信可能になった時に送り出してもらうように登録するというふうにします。
登録するのが
lws_callback_on_writable(wsi);
で、呼び出されたLWS_CALLBACK_SERVER_WRITEABLEの中で
lws_write(wsi, バッファアドレス + LWS_PRE, 長さ, LWS_WRITE_TEXTまたはLWS_WRITE_BINARY);
とします。
気を付けなければならないのは、送信したデータが100バイトのときバッファは100+LWS_PRE(=16)バイトを確保しておく必要があり、送信データは&buf[LWS_PRE]から書き込んでおきます。websocketのデータにはヘッダが付くので、そのヘッダの分をバッファの先頭に付けれ置かなければならないようです。ユーザがヘッダを何かする必要はありません。mallocで確保したままの状態で構いません。
☀
さて、Javascriptからトリガを与えて、ZYNQ上のwebsocketサーバが応答を返すプログラムを作り、どのくらいのスループットが出るのかを試してみました。ZYNQ側はLAN9514接続の100BASE-TX、PC側はGitabitEtherです。
パケットサイズが1000バイトのときは0.8Mbyte、10kバイトのときは2.1MByte、100kバイトのときは2.2MByte、1Mバイトのときも2.2MByteでした。
すなわち、ZYNQのUSB経由の100Mイーサでも2.1～2.2Mバイト/秒の速度が出ていました。ボトルネックがZYNQのCPUの処理速度か、USB経由のLANか、ブラウザのJavascriptかはわかりませんが、手軽に動かすには十分な速度が出ると思っていいでしょう。
初期化の際のrx_buffer_sizeとtx_buffer_sizeをともに増やしてみました。転送速度は、
・・ちょっと速すぎる気がします。
詳しいことは後日改めて計測することにしましょう。
Cosmo-Zの近代化のため、ZYNQでwebsocketを動かそうとしています。
websocketというのは、Javascriptとサーバとの間で通信をするための仕組みですが、ajaxと比べて
というメリットがあります。
websocketのプロトコルは結構面倒なので、自分で作るよりも既存のライブラリを使ったほうがはるかに簡単にできます。（以前、MITOUJTAGオンライン用に自前のwebsocketを作ったが、大きなサイズのデータの転送では怪しかった）
使ったライブラリはlibwebsocketsというもの。最新バージョンはv3.1だと思われます。ネットにある様々なソースの断片はv3.1でないものが多いので、そのままでは動かない可能性があるでしょう。
Cosmo-Zで試したいところですが、まずは手元にあったZynqberryで実験します。
本体のインストールの前に、
$ apt install libssl-dev
$ apt install cmake
でOpenSSLの開発パッケージとcmakeを入れておきます。
それから、以下のコマンドでダウンロードとビルド、インストールを行います。
$ sudo git clone https://github.com/warmcat/libwebsockets
$ cd libwebsockets
$ mkdir build
$ cd build
$ cmake .. & make
$ sudo make install
git cloneのダウンロード先は、https://libwebsockets.org/repo/libwebsocketsではなく、https://github.com/warmcat/libwebsockets です。libwebsockets.orgのほうにすると、
root@zynqberry:~# sudo git clone https://libwebsockets.org/repo/libwebsockets
Cloning into 'libwebsockets'...
remote: Enumerating objects: 28888, done.
remote: Counting objects: 100% (28888/28888), done.
remote: Compressing objects: 100% (7594/7594), done.
error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
というエラーが出て、どのようにしてもインストールできませんでした。（Windowsのgitからcloneしても同様にダメなので、ZYNQのgitが壊れているのではなさそう）
次に、buildというディレクトリを作ってビルドするのですが、ダウンロードしてきたlibwebsocketにはbuildディレクトリはないので自分で作ってください。そして、buildディレクトリに移って、cmake .. && makeですが、一つ上の(つまりlibwebsocketの)ディレクトリでcmakeを走らせるという意味です。
cmakeというのは、簡単な記述でMakefileを生成してくれる便利なツールです。今回のインストールで初めて知りました。いやぁ、便利なものがあるものですね。次回からどんどん使わせていただきましょう。
ZYNQ上でビルドしても、それほど時間はかかりません。20分くらいでしょう。
そうしたら、サンプルのプログラムを試してみます。libwebsockets/minimal-examples/ws-server/minimal-ws-server-pmd に移動し、
$ cmake . & make
とタイプします。もし、
Lws configuration of LWS_WITHOUT_EXTENSIONS is incompatible with this
というエラーが出たら、CMakeLists.txtの68行目にある
require_lws_config(LWS_WITHOUT_EXTENSIONS 0 requirements)
を
require_lws_config(LWS_WITHOUT_EXTENSIONS 1 requirements)
にして再度ビルドします。
ビルドに成功したら、
./lws-minimal-ws-server-pmd
で起動しますが、もしここで.soのパスが見当たらずにうまく起動できない人は
LD_LIBRARY_PATH=/usr/local/lib:/usr/lib; export LD_LIBRARY_PATH
でパスを通しておいてください。
そうしたら、./lws-minimal-ws-server-pmdで起動します。
クライアントとなるPCでWebブラウザを立ち上げ、http://zynqberry:7681/と入力します。すぐにWebページが開き、下の図のようなページが表示されます。
ここでsendボタンを押すと、テキストボックスに入力された文字列がwebsocketでサーバに送られ、上のtextareaに表示されるというふうになっています。
このサンプルのすごいところは、同じポート(7681)なのに、Webページの表示とWebsocketの応答をプロトコルを切り替えられるところです。1つのポートで複数のサーバを同時に運用できるのです。
ZYNQで動くUbuntu 18.04LTSのイメージをリリースしました。
対象となるハードウェアはZynqberryですが、ご要望があれば他のボードにも拡張していく可能性があります。
特徴は、
となっています。
デフォルトで用意されているユーザはzynqで、パスワードはberryです。
rootのパスワードはrootです。
コンソール(USB COMポート経由)で接続した場合はユーザ名・パスワードを入力することなく、自動的にrootとしてログインされます。
SSHではrootではログインできませんので、特権操作が必要な場合はsudoまたはsuしてください。
このイメージファイルはzynqberry_ubuntu18_complete.imgという名前で、約3.3GByteのサイズがあります。
このファイルを、Win32 Disk Imagerなどを使って新しいSDカードに書き込みます。
SDカードは2つのパーティションが切られています。最初のパーティションはWindowsからも読める300MBのFAT32、2番目のパーティションはUbuntuのrootが入っているext4となっています。
SDカードをZynqberryに挿して起動すると、初回起動時に2番目のパーティションが自動的に拡張され、
SDカードの容量いっぱいまで拡張されますが、16GBのSDカードでも、32GBのSDカードでも使い切ることができます。書き込むのは最小のサイズのイメージファイルでよく、書き込み時間が短縮できます。利用可能な最小のSDカードは4GBです。
/home/shareに共有フォルダが用意されていて、Windowsから\\zynqberry でアクセスすることができます。また、zynqberryという名前でWindowsから名前解決することができます。
様々なデスクトップマネージャを試し、armhfでも安定して動作できるLXDEを採用しました。
HDMIコネクタにモニタをつなぎ、マウスとキーボードをつなげばスタンドアローンで使用することもできます。スタンドアローンでデスクトップ環境を利用するにはコンソールから
$ startx
と入力します。
または、Windowsのリモートデスクトップから接続することも可能です。リモートデスクトップでzynqberryに接続すると、下の図のような画面が表示されるので、SessionはXorg、ユーザ名はroot、パスワードはrootを入力してください。
リモートデスクトップが使えるようになります。この環境では無線LANの設定などがグラフィカルに行えます。
無線LANを有効にするには、USB LANアダプタを挿し、
$ nmcli device wifi connect [SSID] password [パスワード]
を入力します。
なお、現在のデバイスの状態を見るには、
$ nmcli device status
と入力します。
利用可能なSSIDの一覧を見るには、
$ nmcli device wifi
と入力します。
なお、無線LANを切断するには、statusで確認したデバイス名を用いて、
$ nmcli device disconnect デバイス名
と入力します。
データ解析に便利なJupyter notebookがあらかじめインストールされています。numpy pandas matplotlib seaborn scikit-learn plotlyがあらかじめインストールされていて、人工知能の研究・開発に便利なnumpyや、綺麗なグラフを表示するseabornなどもすぐに使えます。
Jupyter notebookなので、グラフの一部を拡大したり、回転したりすることもできます。
Jypyterを利用するには、
$ jupyter notebook --allow-root &
と入力し、コンソールに表示された http://zynqberry:8080/ をクリックします。
Jupyterのファイル一覧が表示されるので、New→Python3と操作します。
JupyterのPython入力画面が開くので、ここにコードを入力して実行してください。
ダウンロード先はこちらです。
フル機能を搭載したこのUbuntu18を利用することで、Zynqberryを「カスタマイズ可能な計測・制御プラットフォーム」として利用しやすくなります。
こちらのページからzynqberry_ubuntu18_complete.img.gzをダウンロードしてください。
Ubuntu18で快適なZYNQ生活をご堪能ください。
ZYNQのUbuntu 18.04にJupyterを入れる方法を確立しました。
Qiitaの記事で参考にしたのは下記の2つです。
最初に紹介した記事の要点は、
$ sudo apt-get install -y python-pip libpq-dev python-dev libpng12-dev libjpeg8-dev libfreetype6-dev libxft-dev
$ sudo pip install -U pip
$ sudo pip install numpy pandas matplotlib seaborn scikit-learn plotly ipython[notebook]
です。apt-getで様々なライブラリを入れた後、pipでnumpyからplotlyと、ipython[notebook]を入れるという手順です。
ただいくつか問題があって、ZYNQ(アーキテクチャ的にはarmhf)のUbuntu18ではこのままだと入りません。libpng12-devをlibpng-devにする必要があります。それから、scikit-learnあたりでエラーとなります。
Running setup.py bdist_wheel for scikit-learn ... error
Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-v9kpo07_/scikit-learn/setup.py';f=geta ttr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmp kuuydzfcpip-wheel- --python-tag
☀
2番目の記事ではRaspbianでpython2.7の環境のようですが、
$ sudo apt-get install libpng12-dev libjpeg8-dev libfreetype6-dev libxft-dev liblapack-dev libatlas-base-dev gfortran g++
$ sudo pip install numpy pandas matplotlib seaborn scikit-learn --no-cache-dir
とされています。
liblapack-dev libatlas-base-dev gfortranあたりが大事なところで、これがscikit-learnをインストールする当たりでlapackがないとかatrasがないとか、fortranがないとかエラーが出ていました。
☀
私が考えた、ZYNQのUbuntu 18.04にJupyterを入れる手順を以下に示します。
$ apt-get install libpng-dev libjpeg8-dev libfreetype6-dev
$ pip3 install numpy
$ pip3 install pandas
$ apt install liblapack-dev libatlas-base-dev gfortran g++
$ pip3 install cython
$ pip3 install matplotlib
$ pip3 install seaborn
$ pip3 install scikit-learn
$ pip3 install jupyter
$ pip3 install ipython[notebook]
cythonってなんだよ～とか思いながら、足りないといわれているパッケージを地道に入れていきます。ただし、この作業には大変な時間がかかります。pip3 installでは中でGCCが動いてコンパイルしているらしく、全部で12時間くらいはかかります。
☀
様々なサイトで見つけたサンプルを動かしてみた結果を示します。
ブラウザの中でグラフが表示できています。
なお、先頭行の
%matplotlib inline
を
%matplotlib notebook
にすると、グラフをインタラクティブに操作できます。
ただしこれができるようにするには、
$ pip3 install ipython[notebook]
でインストールしておかなければならないようです。そうしないと、
[IPKernelApp] ERROR | No such comm target registered:
というエラーが出て、グラフが表示されません。
☀
最終的に使うのかどうかわからないseaborn scikit-learnなどのパッケージも入り、このような綺麗なグラフが出せるようになりました。
Jupyterが動くようになったZYNQ Ubuntu18のイメージは近日中にダウンロードできるようにします。お楽しみに。
Raspberry Piでは1GBくらいのRaspbianのイメージをSDカードに入れて起動すると、最初の起動時にSDカードの最大限までパーティションを拡張してファイルシステムが構築されます。ユーザが何GBのSDカードを用意しても、容量一杯までパーティションを拡張してくれる。それなのにダウンロードする容量は最小限でよいという素晴らしい仕組みです。
同じことをZYNQで動くLinuxでもやってみたいのですが、どうしたらよいでしょうか？
☀
Raspberry Piでの自動拡張の仕組みは
「Raspberry Piで最小サイズのバックアップを作成する
https://dev.classmethod.jp/hardware/raspberrypi-backup-restore/」
のページが詳しいのですが、そのままZYNQ Linuxには適用できませんでした。
上のページの内容を読んでみると、Raspberry Piでは以下のような仕組みでパーティションの自動拡張を行っているようです。
パーティションを拡大しているコマンドはresize2fsなのですが、resize2fsは物理パーティションの拡張をしてくれません。
当然ながらZYNQのUbuntu 18.04ではresize2fs /dev/mmcbkl0p2を行ってもパーティションのサイズは拡張されませんでした。Raspberry Piとの違いは詳しく調べていませんが、物理パーティションと論理、拡張パーティションとかそういう違いなのでしょう。
☀
そこで、ZYNQ Ubuntu 18.04でも動くパーティション自動拡張のやり方を考えました。
Zynqberryを使って実験します。
① /etc/init.d/zb_parted_once というファイルを作る。中身は以下のとおり。
#!/bin/sh
### BEGIN INIT INFO
# Provides: zb_parted_once
# Required-Start:
# Required-Stop:
# Default-Start: 3
# Default-Stop:
# Short-Description: Maximize the root filesystem and partition # Description:
### END INIT INFO
. /lib/lsb/init-functions
case "$1" in
start)
log_daemon_msg "Starting zb_parted_onec, Maximize the root filesystem and partition"
ROOT_DEV=$(findmnt / -o source -n) &&
parted -s /dev/mmcblk0 unit s "print free" "resizepart 2 -1s" "print free" &&
resize2fs $ROOT_DEV &&
update-rc.d zb_parted_once remove &&
rm /etc/init.d/zb_parted_once &&
log_end_msg $?
;;
*)
echo "Usage: $0 start" >&2
exit 3
;;
esac
② 実行権限を与える
$ chmod 755 /etc/init.d/zb_parted_once
③ zb_parted_once が起動時に実行されるようにする。
$ update-rc.d zb_parted_once defaults
起動スクリプトとして実行する前に、まずは
$ parted /dev/mmcblk0
unit s
print free
resizepart 2 -1s
print free
を実行して、予備実験を行います。
実行前にはLinuxのパーティションは1.6GBほどで、後ろに広大なFree Spaceがあったのですが、resizepartの後でパーティション2が14GBに拡大されてFree Spaceが消えたのがわかります。esizepart 2 -1sというのは、パーティション2を最大セクタまで拡張するという意味です。
☀
このスクリプトを登録したSDカードをZynqberryに挿して起動してみると、
・・・
[ OK ] Reached target Basic System.
Starting Permit User Sessions...
[ OK ] Started Set the CPU Frequency Scaling governor.
Starting System Logging Service...
[ OK ] Started Regular background program processing daemon.
Starting Dispatcher daemon for systemd-networkd...
Starting Login Service...
[ OK ] Started Message of the Day.
Starting LSB: Maximize the root filesystem and partition...
[ OK ] Started D-Bus System Message Bus.
[ OK ] Started Login Service.
・・・
と、無事に起動時に実行されたようです。fdiskの結果は、
zb@zynqberry:~$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 14.4 GiB, 15489564672 bytes, 30253056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xacbccfd5
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 616447 614400 300M b W95 FAT32
/dev/mmcblk0p2 616448 30253055 29636608 14.1G 83 Linux
zb@zynqberry:~$
と、無事に最大まで拡張されました。
これで、最小サイズのSDカードイメージを配って、ユーザが用意したSDカードで利用可能な最大サイズまでパーティションを拡張するという、Raspbianみたいなことが自分のシステムでもできるようになりました。
ZynqberryでUbuntu 18.04が動くようになってGUI環境も整ってきたのですが、どのようにしたら確実にデスクトップマネージャが入るかを再現可能なように手順をメモしながら再チャレンジしました。
まず、LXDEとxinitを入れます。LXDEは軽量のデスクトップマネージャで、xinitはXをスタートするためのものです。
$ sudo apt install lxde
$ sudo apt install xinit
次に、lightdmのサービスを停止します。gnome関係のものが動いているとうまくログインできないことがあるので、止めます。
$ sudo systemctl disable lightdm
次にデスクトップマネージャの切り替えを行います。
root@zynqberry:~# sudo update-alternatives --config x-session-manager
There are 4 choices for the alternative x-session-manager (providing /usr/bin/x-session-manager).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/bin/gnome-session 50 auto mode
1 /usr/bin/gnome-session 50 manual mode
2 /usr/bin/lxsession 49 manual mode
3 /usr/bin/openbox-session 40 manual mode
4 /usr/bin/startlxde 50 manual mode
Press to keep the current choice[*], or type selection number: 4
update-alternatives: using /usr/bin/startlxde to provide /usr/bin/x-session-manager (x-session-manager) in manual mode
デフォルトではgnome-sessionになっているので、4番のstartlxdeを選択します。
これで再起動すると、コンソールが起動します。
ユーザ名とパスワードを入れて、startxで打てば、LXDEが立ち上がります。
なお、豪華なデスクトップマネージャにあこがれてlubuntu-desktopを入れても、ZYNQ 7000には重すぎてまともに動きません。LXDEが精一杯です。
以下はやってはいけない例です。
$ apt install -y lubuntu-desktop
$ apt install -y ubuntu-session
これをやると、ファイルのいろいろなところが書き変わるのでLXDEさえも起動しなくなります。
☀
デスクトップマネージャはLXDE以外は使い物になりませんが、LXDEが動くというだけで、その上で何かの作業ができるわけではありません。
firefoxが最初から入っていますが、とても重いのでネットサーフィンもきついでしょう。ブラウザアプリを動かすのも大変だと思います。
そもそも、そんな重いデスクトップ環境を整える意味はあるのかというと、
などに役に立つのではないかと思います。
☀
ちなみに、
$ sudo apt install xrdp
でXRDPを入れてリモートデスクトップ環境を整えても、同じくらい遅いです。どうやら画像表示のフレームバッファが遅いのではなく、ZYNQ 7000にとってUbuntu18+デスクトップ環境というのがそもそも重いのでしょう。
☀
スワップを有効にすれば、わずかに改善できるかもしれません。
$ dd if=/dev/zero of=/var/swap bs=1M count=1024
$ mkswap /var/swap
$ chmod 600 /var/swap
$ swapon /var/swap
Zynqberryのメモリは512Mバイトなのですが、freeコマンドで見るといつも苦しそうです。スワップを有効にすることで気休め程度に緩和される気がします。
ZYNQ+Ubuntu 18.04のデスクトップが動いたので、手順を確実にするため、再びゼロから入れなおしています。
前回の問題点は、
ということでした。
そういうわけで、再びUbuntu 18.04をゼロから入れてみることにします。ああ、インストールってなんて楽しいのだろう。せっかくなら、作業時にはSDカードいっぱいのパーティションで作業して、配布用SDカードのimgファイルを作るときには小さくしたいですね。
縮小されたSDカードの作り方は、Raspberry Pi用の情報を探せば出てきます。
基本的にはZynqberry上から自分自身のパーティションを縮小することはできないので、ZynqberryのSDカードを引っこ抜いて別のLinuxが動くPCで読み込んで操作します。
以下、ホストPCでの作業を示します。
まずは、fdiskで現状を確認します。
naitou@ubuntu:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 14.4 GiB, 15489564672 bytes, 30253056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xacbccfd5
Device Boot Start End Sectors Size Id Type
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 616447 614400 300M b W95 FAT32
/dev/sdb2 616448 30253055 29636608 14.1G 83 Linux
naitou@ubuntu:~$ sudo resize2fs -P /dev/sdb2
resize2fs 1.44.1 (24-Mar-2018)
Estimated minimum size of the filesystem: 345056
第二パーティションはセクタ616448からセクタ30253055の、29636608個のセクタに入っていることがわかります。1セクタ=512Byteなので、トータルの容量は15489564160バイト(約16GB)となります。
次にresize2fsで、ファイルシステムに必要な最小サイズを調べます。
naitou@ubuntu:~$ sudo resize2fs -P /dev/sdb2
resize2fs 1.44.1 (24-Mar-2018)
Estimated minimum size of the filesystem: 345056
このコマンドで使う345056という数値はブロック単位で、1ブロックは4096バイトです。したがって、インストール直後のZynqberry Ubuntu18のファイルシステムは345056×4096=1,413,349,376バイトあれば格納できることがわかります。
次にパーティションを縮小するのですが、ぎりぎりで作ってしまうとよくないので1024ブロックほど増やしたサイズに縮小します。
345056+1024=346080ブロック=2768640セクタにします。
naitou@ubuntu:~$ sudo parted /dev/sdb
GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) u s ・・・セクタ単位での表示にする
(parted) print free ・・・セクタ単位での表示にする
Model: Multiple Card Reader (scsi)
Disk /dev/sdb: 30253056s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 616447s 614400s primary fat32
2 616448s 30253055s 29636608s primary ext4
(parted) resizepart 2 2768640 ・・・パーティション2を2768640セクタに縮める
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
(parted) print free ・・・パーティションの状態を表示する
Model: Multiple Card Reader (scsi)
Disk /dev/sdb: 30253056s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
63s 2047s 1985s Free Space
1 2048s 616447s 614400s primary fat32
2 616448s 2768640s 2152193s primary ext4
2768641s 30253055s 27484415s Free Space ←パーティション2が縮んで空き領域が出来た
(parted) q
Information: You may need to update /etc/fstab.
これで、パーティションを縮めることができました。
最後にddを使ってイメージファイルを作成します。
naitou@ubuntu:~$ sudo dd if=/dev/sdb of=zynqberry_ubuntu18.img count=2768641 bs=512
これでイメージファイルが作成できました。
手順をまとめると、
ということになります。
いろいろな概念が出てきましたが、
ということかなと思います。
最近のコメント