コグノスケ

小型 HDMI ディスプレイ購入

小型の HDMI ディスプレイを買いました。ELECROW というメーカーの LR10FHD01 という製品です。Amazon で 1万円くらい。

買ったきっかけですけども、ROCK64 の HDMI 出力を見たかったことと、サーバの VGA 出力が壊れたのか、今持っている小型 VGA ディスプレイが映らなくなってしまったため、代替品が欲しかったからです。

• サイズ: 10インチ
• 液晶方式: 光沢あり、IPS 液晶らしい（確認しようがないけど）
• 解像度: 最大 Full HD つまり 1920x1080
• 入力方式: HDMI or VGA
• 電源: 付属の AC アダプタ

見ての通りスペックはそこそこ良く、価格もお安いです。その分、細かいところはいい加減です。

音量調整がバカで Volume 1 でも近所迷惑なデカい音が鳴ります。しかも最大音量は 100 です。こんなバカでかい音で誰が使うんでしょう？ミュートにできることがせめてもの救いです。

OSD メニューはヘボいです。日本語が選択できますが、漢字は中国語の字体、訳が意味不明、ハングルが混ざるなど、やる気ゼロです。英語に変えた方がマシです。

HDMI 入力もバグっていて、HDMI 挿抜もしくは電源 ON/OFF で画面表示が右にズレて、音が出なくなります。もう一度電源 ON/OFF すると直ります……。

OSD に表示される謎の日本語

本体に型番が書いておらず、箱を捨ててしまうと型番が分からなくなります。

細かいところは手抜き感が漂いますが、映れば全て良しです。

メモ: 技術系の話は Facebook から転記しておくことにした。加筆した。

続編が楽しみなマンガ 10作品

目次: マンガ紹介 - まとめリンク

お気に入りのマンガ紹介シリーズ。

最近読んだ、これからも続編が楽しみなマンガ 10作品。並びは、あいうえお順です。

1〜5 です。

うらみちお兄さん（3巻）

いわゆる「お母さんといっしょ」の体操のお兄さんが主人公、歌のお姉さん、歌のお兄さん、マスコットの中の人が準主役のギャグマンガです。
お兄さんお姉さんたちは、ブラック社会の大人の事情や抑圧に精神をやられており、子供たちの前では笑顔を振りまきますが、それ以外はやさぐれています。子供たちが妙に悟っているのも面白いです。

桐谷さん ちょっそれ食うんすか！？（6巻）

ゲテモノ食を愛する女子高生、桐谷さんが主人公のグルメマンガです。
昆虫や深海魚、爬虫類など、日本ではあまり食べない食材にチャレンジし続けます。世の中には色々な食材があるもんだと感心します。あとがきを見ると、作者さんが実際にチャレンジした食材を作品にしているそうです。

じけんじゃけん（5巻）

推理小説マニアでミステリ研の女子高生、その彼女に惹かれてミス研に入った男子高校生が主役のギャグマンガ。
ミステリのネタが所々に入っていますが、ミステリ要素は強くなく、強いて言えば日常系です。元ネタがわからなくても困りませんが、わかるともっと面白いのだろうか？タイトルからもわかるように、舞台は広島です。登場人物の女子達はほぼ全員が広島弁です。気になる。

天地創造デザイン部（3巻）

神様が発注してくる曖昧でデタラメな要件の生物を、デザイン部の皆さんがウンウンうなりながら設計していくギャグマンガです。雑学の要素も強いです。
ギャグのオチに神様のメチャクチャな要望に応えた、メチャクチャな生物が登場しますが、でっち上げの架空生物ではなく、実在する生物（たまに伝説上の生物なども登場します）であるところが、へえ！と唸らせる面白さの 1つです。お話の中で登場した生物の解説ページまで付いており、面白くて為になる作品です。

ハクメイとミコチ（7巻）

小人のハクメイとミコチの2人の気ままな生活と、周囲の人々との交流を描く、ファンタジー系のマンガです。
文章がヘタで説明できませんが、2人の住んでいる世界の描画が素晴らしいです。実際に住んだらやや不便そうではありますが、この世界に住みたいと思うこと間違いなしです。

6〜10 です。

フラジャイル 病理医岸京一郎の所見（13巻）

患者の前には出ませんが、検査結果を診断する病理医が主人公の医療系マンガです。
現代医療の問題点にグサグサ切り込んでいきます。主人公の岸先生は超優秀ですが、かなりの曲者で周囲との衝突が絶えません。いろいろ揉めまくりますが、最終的には何とかなるので安心して楽しめます。

へんなものみっけ！（3巻）

博物館の事務員として左遷（なのか？）されてきた公務員が主人公で、博物館の研究者や裏方の活動を描いたマンガです。雑学もあります。
博物館の裏方は一般の見学者からはわかりませんし、職員にならない限りまず見られません。自分の知らない世界が垣間見えて面白いです。

マージナルオペレーション（12巻）

子供だけの傭兵集団を率いる「子供使い」アラタが主人公の現代軍事物のマンガです。中東が出発点で、世界の様々な国で活躍します。12巻ではミャンマー編が盛り上がってきます。
たまに 1巻から読み返すと、画も話も結構テイストが変わっていると思います。子供たちを傭兵に送り込んでいることを知って苦しむ初期、覚悟を決めて傭兵業を続ける中期〜、いずれも面白いです。戦争するので、人が死ぬシーンが割と出てきます。苦手な人は注意です。

魔法少女特殊戦あすか（9巻）

理不尽系＋魔法少女＋現代軍事物のマンガです。かつて世界を救ったマジカルファイブという魔法少女のリーダー、あすかが主人公です。魔法少女ものって残酷にしなきゃいけないルールでもできたんですかね？
魔法少女なので魔法の力で戦いますが、明らかに殴って撃って斬っていて、敵も味方も重傷で血みどろです。捕まえて拷問したり、マジカル自白剤とか素敵ワードが飛び交う、エグさ満点の作品です。画は綺麗ですがグロいシーンが多いので、苦手な人は注意です。

幼女戦記（12巻）

冷酷で優秀だが神を信じない現代サラリーマンが主人公で、魔法の存在する第一次世界大戦直前のヨーロッパに似た世界に転生します。しかも幼女として。ジャンルとしては近代〜現代軍事物のマンガ。
主人公は後方で楽したいと思っていますが、やることが全て裏目に出て最前線や激戦区に投入され続けます。全員が真面目にやっていて、結果も上々ですが、奇跡的に想いだけがすれ違い続けます。ギャグじゃないのにギャグ要素を感じる面白い作品です。戦争で人が死ぬシーンがそこそこあります。苦手な人は注意です。

メモ: 趣味の話は Facebook から転記しておくことにした。

ROCK64 で HDMI オーディオを使う

目次: ROCK64/ROCKPro64 - まとめリンク

先日購入した HDMI モニタのおかげで、ROCK64 の I2S0 つまり HDMI Audio の動作確認ができました。

しかし以前（2018年 11月 11日の日記参照）悩んでいた通り、単純に I2S0 を有効にすることはできません。DMA チャネルが足りない問題が発生するためです。

ROCK64 に搭載されている Rockchip RK3328 の DMAC は、16 の DMA チャネルを持っていますが、そのうち 8ch しか同時に使えない仕様になっています。

苦肉の策

現在の linux-next の ROCK64 向けデバイスツリーでは、既に 7ch を使用（I2S1 2ch, SPDIF 1ch, SPI0 2ch, UART2 2ch）していますから、ここに 2ch を使用する I2S0 を追加すると合計 9ch になって、オーバーしてしまいます。

仕方ないので UART2 の DMA 割り当てを解除して、I2S0 に割り当てるパッチを投稿しました。

予想通りの反応

私がパッチに書いた説明が悪かったのだと思いますが、メンテナーの Heiko さんから「どうして UART2 の DMA チャネルを I2S0 が使えるのかわからない」という返事がきました。ですよね……私も最初意味不明でしたし。

できる限り説明を加えて返事しましたが、理解してもらえると良いな。

わかりづらい仕様書

ややこしいことに、RK3328 の仕様書を見ると、各 DMA チャネルには ID が（仕様書では Req number）が振られていて、ぱっと見 16 チャネルが全て同時に使えそうに見えるんですよ。

この仕様書から「各 DMA チャネルは独立しているけど、全てのチャネルが同時に使える訳ではない」という意味を読み取れる人はなかなかいないと思います。

DMA チャネルの割り当て

少なくとも私は DMA の Req number とチャネル数の関係を理解するのは無理だったので、DMAC のドライバ（PL330）を追いかけました。

サウンド系から DMA チャネルの割り当てを要求するとき、次のような呼び出し関係になります。

rockchip_pcm_platform_register()
  devm_snd_dmaengine_pcm_register()
    snd_dmaengine_pcm_register()
      dmaengine_pcm_request_chan_of()
        dma_request_slave_channel_reason()
          of_dma_request_slave_channel()
            ofdma->of_dma_xlate() => of_dma_pl330_xlate()
              dma_get_slave_channel()
                dma_chan_get()
                  pl330_alloc_chan_resources()
                    pl330_request_channel()

まず、関数 of_dma_pl330_xlate() にはローカル変数 chan_id が登場します。これが DMA の ID に相当します。例えば UART2 の送信側なら chan_id = 6 になります。

元になる数字はどこから来るかというと、of_dma_match_channel() でデバイスツリーから情報を貰っています。RK3328 の場合、デバイスツリーで DMA チャネルを指定する際は、Req number を書くようです。

次に、関数 pl330_request_channel() に構造体 struct pl330_dmac のメンバー channels という配列が登場します。この channels の数が DMAC の DMA チャネルの数と等しいです。Req number とは無関係に、DMA チャネルを要求されると先頭から埋まっていきます。

こんな仕様が初見でわかる訳ないじゃない。むり。

メモ: 技術系の話は Facebook から転記しておくことにした。1節加筆。

クロック分周器

Linux のクロックフレームワークで実装できるクロック分周器のドライバは 2種類あります。

1つは integer divider で、入力されたクロック周波数の 1/3 や 1/4 など整数比の周波数で出力するハードウェアです。もう 1つは fractional divider で、周波数を x/y にするハードウェアです。

後者の fractional divider ドライバは、標準動作とカスタム動作のドライバが書けます。

標準動作の場合、分子と分母に設定できる値に、何ら制約がないものとして動作します。カスタム動作のドライバは、特殊な制約のあるハードウェア向けです。

今のところカスタム動作の fractional divider ドライバを実装しているのは Rockchip だけです。Rockchip の場合、分母が分子の 20 倍以上でなければ出力周波数が不安定になる制約があるようです。

Rockchip が変な仕様であることは間違いないと思いますが、Linux に対応しているだけ、まだマシとも取れますね。

世の中には「どうしてこうなった？？」としか思えない、変な仕様のハードウェアがたくさん存在しますし……。

メモ: 技術系の話は Facebook から転記しておくことにした。

ROCKPro64 のシリアル文字化け - オシロスコープで解析

目次: ROCK64/ROCKPro64 - まとめリンク

以前（2018年 12月）に ROCKPro64 を購入したのですが、シリアルが文字化けして使い物にならず、ずっとお蔵入りになっていました。

最初はケーブルの接続や、接地がおかしいのかと思いましたが、GND 側はきっちり 0V でした。どうも単純な原因ではなさそうだったので、オシロスコープで信号を見ることにしました。テストパターンとして 0 と 1 が交互に出現し、一番転送が難しいパターンと思われる 0x55 'U' の文字を出力しています。

正常に出力できている ROCK64 と比較すると、ROCK64 は出力が 0 → 1 → 0 と変化する際に 0V → 3V → 0V のように電圧が振れますが、ROCKPro64 は、0V → 2.48V → 0V のように立ち上がり側が遅く、中途半端な電圧になっています。

下記の画像の青色の線が ROCK64 のシリアル出力で、オレンジ色の線が ROCKPro64 のシリアル出力です。どちらも 1秒ごとに 'U' を出力して、最初の立ち下がり（Start Bit、必ず 0）にトリガを掛けています。

ROCK64 のシリアル出力の波形

ROCKPro64 のシリアル出力の波形

ROCK64 は綺麗な波形ですが、ROCKPro64 は 0V → 3V への立ち上がりが間に合っていないことが分かるかと思います。

文字化けの原因ですけども、シリアルの転送速度（1.5Mbps、1ビット 666ns）に対し、0 → 1 の立ち上がりが遅すぎる（650ns くらい）からでしょう。出力側は 1 を送出しているつもりでも、信号が立ち上がるのが遅いため、受信側は 0 だと解釈してしまう場合があります。

転送速度を落とせば改善するかもしれません。しかし Rockchip の U-Boot はなぜか 1.5Mbps 固定で転送してくる困った奴で、下手にシリアルの転送速度を変えると U-Boot が操作できなくなり、非常に使いづらいのです。イマイチですね……。

ROCKPro64 のシリアル出力の文字化けを改善する

ROCKPro64 には Rockchip の RK3399 と言う SoC が搭載されていて、RK3399 は一部のピンの Drive Strength、つまりピンに流せる電流量を調整できます。決して特殊な機能ではなく、大抵の SoC が持つ普通の機能です。

ROCKPro64 がコネクタに引き出しているシリアルは UART2 です。UART2 は GPIO4_C4（TX）と GPIO4_C3（RX）というピンに割り当てられています。幸運なことに RK3399 ではこれらのピンの Drive Strength が変更できるので、設定値を振って（※）オシロで波形を見てみました。

下記の画像が測定結果です。1枚目はデフォルトかつ最小の 3mA、2枚目は最大の 12mA 設定です。出力している文字は前回同様 0x55 'U' で、トリガも前回同様 Start Bit の立ち下がりに仕掛けています。オシロの Rising, Falling Time 解析を ON にしたので、立ち上がり、立ち下がりに掛かった時間も一緒に表示されています。

Drive Strength = 3mA のときのシリアル出力波形

Drive Strength = 12mA のときのシリアル出力波形

字が若干見づらいので、一応書いておくと、立ち上がりの時間は 650ns → 300ns くらいに改善しました。良い感じですね。

ちなみにスクリーンショットの色が変で、文字が読みづらいのは仕様です。Tektronix さん、スクリーンショット背景の白黒反転処理、バグってますよ……？？

それはさておき Drive Strength の変更で、ROCKPro64 のシリアル文字化けはかなり改善されました。しかし完全ではなく大量に出力した際に若干文字化けします。

さらなる改善のためには、シリアルの転送速度を落とすくらいしか思いつきません。が、U-Boot の書き換えをするのが面倒くさいので、また今度にします……。

（※）レジスタ名は GRF_GPIO4C_E で、アドレスは 0xff77e138 です。書き込む値は 0x03c00xx0 をお勧めします。xx の部分はドライブ能力を最小にするなら 00 で、最大にするなら 3c です。

メモ: 技術系の話は Facebook から転記しておくことにした。追記、文章の組み換えをした。

ROCKPro64 のシリアル文字化け - 回路図を見る

目次: ROCK64/ROCKPro64 - まとめリンク

ROCKPro64 のシリアル文字化けの原因は、RK3399 の端子ドライブ能力不足が原因である可能性は高そうですが、最大値の 12mA に設定しても立ち上がりが遅い（立ち下がり 50ns 以下に対し、立ち上がり 300ns 以上かかる）点が気になります。

SoC 以外に原因があるとすれば、ボードの回路くらいですが、回路となると門外漢も良いところで、確かめ方がわかりません。

ROCKPro64 の Schematics を素直に信じると、SoC の出力ピンが直接コネクタに接続されていて、抵抗も何もないように読めます。RK3399 は SoC 裏面がハンダ付けされている（BGA）ため、コネクタ〜SoC 端子間に、本当に抵抗や断線がないかどうかは確かめようがありません。

文字化けの頻度はかなり減ったので、今のままでもそれなりに使えますが、なぜ立ち上がりだけが異常に遅いのか、釈然としません。うーん……。

ドライバ観点からの ROCK64 や ROCKPro64 の使いやすさ

ROCK64 というか Rockchip RK3328 の HDMI ドライバは drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c です。このドライバは多くの処理を drivers/gpu/drm/bridge/synopsys/dw-hdmi.c つまり Synopsys DesignWare の HDMI IP 用のドライバに頼っています。

Synopsys の HDMI ドライバは映像出力と、音声出力の機能を持っています。映像側の作りは知りませんが、音声側は ASoC フレームワークに合わせて作られています。そのお陰で ROCK64 に HDMI 音声出力対応を追加するときは、デバイスツリーに記述を足すだけで良く、非常に楽でした。

Synopsys のドライバは linux-next に Upstream されていますが、コミットログを見る限り Synopsys のメールアドレスの人はあまり出現しません。

社外の人や、会社と関係のない所属の人がわざわざドライバに修正をコミットしてくれるなんて、凄いことだと思います。人気のある IP のドライバを OSS にすると、色々な人が直してくれて、正のスパイラルが構築される、良い例と言えるでしょう。

この辺の根回しの良さは、さすが IP 屋さんの Synopsys って感じがしました。

メモ: 技術系の話は Facebook から転記しておくことにした。追記した。

RISC-V 向けクロスコンパイラ

目次: GCC を調べる - まとめリンク

Crosstool-NG は RISC-V に対応していないのかと思っていたら、Experimental オプション（CT_EXPERIMENTAL）を Y に設定したら RISC-V が選べるみたいです。

GCC のビルドは ARM 向けに昔チャレンジしましたが、結構面倒くさいので、コンパイラを含むツールチェーンを簡単にビルドできる Crosstool-NG の存在は非常にありがたいです。あとは LLVM にも対応してくれたら最高なんですけどね。

Experimental というだけあって RISC-V 32bit 用のコンパイラはビルドエラーになってしまって作成できません。RISC-V 64bit 用のコンパイラは作成できます。

作成したコンパイラで適当なコードをビルドして逆アセンブルを見ると、命令長が 32bit のものと、16bit のものが混在していました。そういえば ARM も ARM 命令と Thumb 命令の 2種類の命令長があります。最近は RISC でも命令長可変の仕様が流行りなんでしょうか？

メモ: 技術系の話は Facebook から転記しておくことにした。少し加筆。

ROCKPro64 の HDMI Audio を有効にする

目次: ROCK64/ROCKPro64 - まとめリンク

RK3399 の Drive Strength 設定を Max にしたことで、文字化けだらけでポンコツ状態だった ROCKPro64 のシリアルが割とまともになったので、最近は ROCKPro64 を触っています。

どうも linux-next の ROCKPro64 のデバイスツリーは HDMI Audio を有効にするのを忘れている？ようで、HDMI から音が出ません。有効にするパッチを LMKL に投げつけておきました……といっても、たった 3行のパッチです。

動かしたら一瞬で気づくはずですが、誰も直さなかったのかなあ？

ROCK64 も ROCKPro64 も割と有名な部類のボードですが、Rockchip Linux じゃなくて、わざわざ linux-next で動かす人は少ないかもしれませんね。

メモ: 技術系の話は Facebook から転記しておくことにした。

RISC-V 64 向け Linux 開発環境の構築

目次: GCC を調べる - まとめリンク

以前 AArch64 向けに開発環境を構築しました（その 1、その 2）。今回は流行りの RISC-V に対して作成してみます。

全く違うアーキテクチャですが、AArch64 向けと同じツール、ほぼ同じ手順が使えます。ツールを整備してくれた開発者の皆様には感謝の極みです。

• クロスコンパイラ: crosstool-NG
• ブートローダ: riscv-pk
• カーネル: linux-next
• ルートファイルシステム: busybox + 手作業
• エミュレータ: qemu

さっと動かしてみたかったので、前回との変化点としては buildroot を使わず、busybox のみの最小環境を作成しています。buildroot は後日チャレンジしたいと思います。

クロスコンパイラ

Crosstool-NG の ct-ng のビルド方法は前回と全く同じ（2018年 7月 15日の日記を参照）なので、割愛します。

$ ./ct-ng menuconfig
- Paths and misc options  --->
    [ ] Try features marked as EXPERIMENTAL
      選択する

- Target options  --->
  Target Architecture (alpha)  --->
    riscv に変更する

  [ ] Use the MMU
    選択する

  Bitness: (32-bit)  --->
    64-bit に変更する

- Operating System  --->
    Target OS (bare-metal)  --->
      linux に変更する

- C-library  --->
    C library (musl)  --->
      glibc に変更する


$ ./ct-ng build
[00:34] /

設定も AArch64 のときと大体同じですが、大きな違いは EXPERIMENTAL を有効にする点です。通常は Target Architecture の選択肢に RISC-V が存在しません。

また、現時点だと 32bit 版はビルドエラーになるようなので、64bit 版を選択しています。

カーネル

AArch64 のビルドとほぼ同じです。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ cd linux-next

$ export ARCH=riscv
$ export CROSS_COMPILE=riscv64-unknown-linux-gnu-

$ make defconfig

$ make all

ビルドが成功するとソースコードのトップディレクトリに vmlinux が生成されるはずです。

ブートローダ

AArch64 では qemu の -kernel オプションに Image ファイルを渡せば起動しましたが、RISC-V では Image ファイルを渡してもエラーになり起動しません。

調べてみると、qemu で RISC-V 向けの Linux を動作させるには、Image ではなくブートローダ付きの vmlinux を渡してあげる必要があるみたいです。

$ git clone https://github.com/riscv/riscv-pk
$ cd riscv-pk

$ mkdir build
$ cd build

$ ../configure --enable-logo --host=riscv64-unknown-linux-gnu --with-payload=../linux-next-riscv/vmlinux

$ make

成功すると build ディレクトリの下に bbl という名前のファイルができます。これがブートローダ＋カーネルのバイナリです。bbl は Berkeley Boot Loader の略です。

このリポジトリの名前 pk は Proxy Kernel の略で、RISC-V のプロセッサ開発を行う際に、周辺のハードウェアを作り込む代わりに、ホストのシステムコールを呼び便利な実行環境を提供するためのソフトウェアのようです。

プロキシカーネルに用事はないんですけど、付属品のブートローダに用事があります。

この riscv-pk はビルドシステムがちょっとイマイチで、build ディレクトリを作らずに configure や make をすると、ソースコードの入っている pk ディレクトリが吹っ飛びます。ご注意ください……。

ルートファイルシステム

以前は buildroot を使って全自動で initramfs を生成してもらいましたが、今回は趣向を変えまして、手動で initramfs を作ります。

$ git clone https://git.busybox.net/busybox

$ cd busybox
$ export CROSS_COMPILE=riscv64-unknown-linux-gnu-

$ make menuconfig

- Settings  --->
  [ ] Build static binary (no shared libs) (NEW)

$ make

ビルドに成功すると busybox という実行ファイルが生成されるはずです。

次に initramfs を作成します。基本的な流れはディレクトリに必要なファイルを配置し、cpio で固めるだけです。

$ mkdir initramfs-work-riscv
$ mkdir initramfs-work-riscv/root
$ cd initramfs-work-riscv/root

$ mkdir bin
$ cp ../../busybox/busybox bin/
$ ln -s busybox bin/sh
$ ln -s bin/busybox init

$ mkdir dev
$ sudo cp -a /dev/tty* dev/

$ find . | cpio --format=newc -o > ../initramfs.cpio

本来は init, sh 以外のシンボリックリンクも作った方が良いです。このあと、qemu で動かしてみたらわかりますが、すごく不便です。/dev/tty も横着してホストマシンのデバイスファイルをコピーするのではなく、mkdev で作るべきです。

が、しかし、美しい initramfs は次回トライする buildroot にお任せしましょう。今回は適当なまま行きます。

実行

実行する設定は AArch64 とは違います。qemu の引数は多すぎるし難しすぎるので、全く覚えられません。私の場合は、動かすたびにわからなくなるので、調べることが多いです。

$ qemu-system-riscv64 -machine virt -kernel riscv-pk/build/bbl -initrd initramfs-work-riscv/initramfs.cpio -serial stdio

    
bbl loader
              vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
                  vvvvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvv
rr                vvvvvvvvvvvvvvvvvvvvvv
rr            vvvvvvvvvvvvvvvvvvvvvvvv      rr
rrrr      vvvvvvvvvvvvvvvvvvvvvvvvvv      rrrr
rrrrrr      vvvvvvvvvvvvvvvvvvvvvv      rrrrrr
rrrrrrrr      vvvvvvvvvvvvvvvvvv      rrrrrrrr
rrrrrrrrrr      vvvvvvvvvvvvvv      rrrrrrrrrr
rrrrrrrrrrrr      vvvvvvvvvv      rrrrrrrrrrrr
rrrrrrrrrrrrrr      vvvvvv      rrrrrrrrrrrrrr
rrrrrrrrrrrrrrrr      vv      rrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrr          rrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrr      rrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrr  rrrrrrrrrrrrrrrrrrrrrr

       INSTRUCTION SETS WANT TO BE FREE
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] No DTB passed to the kernel
[    0.000000] Linux version 5.0.0-rc7-next-20190225 (katsuhiro@blackbird) (gcc version 8.2.0 (crosstool-NG 1.23.0.610-db4fdf0)) #2 SMP Tue Feb 26 19:07:38 JST 2019
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (1691648 bytes)
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x0000000087ffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
...

[    0.346331] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.348500] NET: Registered protocol family 17
[    0.349051] Key type dns_resolver registered
[    0.370752] Freeing unused kernel memory: 192K
[    0.370952] This architecture does not have kernel memory protection.
[    0.371164] Run /init as init process
can't run '/etc/init.d/rcS': No such file or directory

Please press Enter to activate this console.
/ # ls
-/bin/sh: ls: not found
/ # busybox uname -a
Linux (none) 5.0.0-rc7-next-20190225 #2 SMP Tue Feb 26 19:07:38 JST 2019 riscv64 GNU/Linux

無事 Linux の起動画面を拝めました。良かった良かった。

作業スペース

現在住んでいる家には私の作業部屋がないので、リビングの食事するテーブルで、ROCKPro64 などのボードとオシロスコープとノート PC を置いて波形を見ています。

リビングのテーブルは広くて色々置けるものの、食事するときは邪魔なので撤去する必要があります。場合によって機材や配線の再セットアップが発生するのが難点です。あと、水が掛かる可能性があり、精密機械（オシロスコープとか）を置くには適していない気がしますが、他に置く場所もありません。

最近は、作業の中断から再開までの時間を短縮するため、リモートで作業するようにしています。ノート PC はリモートアクセス端末として使い、メイン PC にリモートアクセスして作業しています。ノート PC のネットワークを切ったり、シャットダウンしたりしても、メイン PC の開発、解析の環境はそのまま保持されますから、すぐに作業に復帰できるという寸法です。

ソフトウェアの開発をするなら十分な環境ですが、ROCKPro64 の UART 出力を解析したときのようにオシロスコープが必要になってくると、リモートアクセスだけではうまくいきません。今のところ、オシロスコープを常用することはないので問題はありませんが、今後必要になったときはもう一工夫いりますね……。