日々

link permalink

小型 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 から転記しておくことにした。加筆した。

[編集者: すずき]
[更新: 2019年 2月 4日 22:23]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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

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

1〜5 です。

うらみちお兄さん(3巻)
いわゆる「お母さんといっしょ」の体操のお兄さんが主人公、歌のお姉さん、歌のお兄さん、マスコットの中の人が準主役のギャグマンガです。
お兄さんお姉さんたちは、ブラック社会の大人の事情や抑圧に精神をやられており、子供たちの前では笑顔を振りまきますが、それ以外はやさぐれています。子供たちが妙に悟っているのも面白いです。
桐谷さん ちょっそれ食うんすか!?(6巻)
ゲテモノ食を愛する女子高生、桐谷さんが主人公のグルメマンガです。
昆虫や深海魚、爬虫類など、日本ではあまり食べない食材にチャレンジし続けます。世の中には色々な食材があるもんだと感心します。あとがきを見ると、作者さんが実際にチャレンジした食材を作品にしているそうです。
じけんじゃけん(5巻)
推理小説マニアでミステリ研の女子高生、その彼女に惹かれてミス研に入った男子高校生が主役のギャグマンガ。
ミステリのネタが所々に入っていますが、ミステリ要素は強くなく、強いて言えば日常系です。元ネタがわからなくても困りませんが、わかるともっと面白いのだろうか?タイトルからもわかるように、舞台は広島です。登場人物の女子達はほぼ全員が広島弁です。気になる。
天地創造デザイン部(3巻)
神様が発注してくる曖昧でデタラメな要件の生物を、デザイン部の皆さんがウンウンうなりながら設計していくギャグマンガです。雑学の要素も強いです。
ギャグのオチに神様のメチャクチャな要望に応えた、メチャクチャな生物が登場しますが、でっち上げの架空生物ではなく、実在する生物(たまに伝説上の生物なども登場します)であるところが、へえ!と唸らせる面白さの 1つです。お話の中で登場した生物の解説ページまで付いており、面白くて為になる作品です。
ハクメイとミコチ(7巻)
小人のハクメイとミコチの2人の気ままな生活と、周囲の人々との交流を描く、ファンタジー系のマンガです。
文章がヘタで説明できませんが、2人の住んでいる世界の描画が素晴らしいです。実際に住んだらやや不便そうではありますが、この世界に住みたいと思うこと間違いなしです。

6〜10 です。

フラジャイル 病理医岸京一郎の所見(13巻)
患者の前には出ませんが、検査結果を診断する病理医が主人公の医療系マンガです。
現代医療の問題点にグサグサ切り込んでいきます。主人公の岸先生は超優秀ですが、かなりの曲者で周囲との衝突が絶えません。いろいろ揉めまくりますが、最終的には何とかなるので安心して楽しめます。
へんなものみっけ!(3巻)
博物館の事務員として左遷(なのか?)されてきた公務員が主人公で、博物館の研究者や裏方の活動を描いたマンガです。雑学もあります。
博物館の裏方は一般の見学者からはわかりませんし、職員にならない限りまず見られません。自分の知らない世界が垣間見えて面白いです。
マージナルオペレーション(12巻)
子供だけの傭兵集団を率いる「子供使い」アラタが主人公の現代軍事物のマンガです。中東が出発点で、世界の様々な国で活躍します。12巻ではミャンマー編が盛り上がってきます。
たまに 1巻から読み返すと、画も話も結構テイストが変わっていると思います。子供たちを傭兵に送り込んでいることを知って苦しむ初期、覚悟を決めて傭兵業を続ける中期〜、いずれも面白いです。戦争するので、人が死ぬシーンが割と出てきます。苦手な人は注意です。
魔法少女特殊戦あすか(9巻)
理不尽系+魔法少女+現代軍事物のマンガです。かつて世界を救ったマジカルファイブという魔法少女のリーダー、あすかが主人公です。魔法少女ものって残酷にしなきゃいけないルールでもできたんですかね?
魔法少女なので魔法の力で戦いますが、明らかに殴って撃って斬っていて、敵も味方も重傷で血みどろです。捕まえて拷問したり、マジカル自白剤とか素敵ワードが飛び交う、エグさ満点の作品です。画は綺麗ですがグロいシーンが多いので、苦手な人は注意です。
幼女戦記(12巻)
冷酷で優秀だが神を信じない現代サラリーマンが主人公で、魔法の存在する第一次世界大戦直前のヨーロッパに似た世界に転生します。しかも幼女として。ジャンルとしては近代〜現代軍事物のマンガ。
主人公は後方で楽したいと思っていますが、やることが全て裏目に出て最前線や激戦区に投入され続けます。全員が真面目にやっていて、結果も上々ですが、奇跡的に想いだけがすれ違い続けます。ギャグじゃないのにギャグ要素を感じる面白い作品です。戦争で人が死ぬシーンがそこそこあります。苦手な人は注意です。

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

[編集者: すずき]
[更新: 2019年 2月 4日 22:38]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

Rock64 HDMI オーディオ

先日購入した 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 チャネルの割り当てを要求するとき、次のような呼び出し関係になります。

RK3328 の 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節加筆。

[編集者: すずき]
[更新: 2019年 2月 5日 00:59]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

クロック分周器

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

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

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

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

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

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

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

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

[編集者: すずき]
[更新: 2019年 2月 13日 00:23]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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 から転記しておくことにした。追記、文章の組み換えをした。

[編集者: すずき]
[更新: 2019年 2月 19日 00:28]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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 から転記しておくことにした。追記した。

[編集者: すずき]
[更新: 2019年 2月 21日 00:43]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

RISC-V のコンパイラ

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 から転記しておくことにした。少し加筆。

[編集者: すずき]
[更新: 2019年 2月 21日 00:46]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

RockPro64 の HDMI Audio

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

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

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

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

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

[編集者: すずき]
[更新: 2019年 2月 21日 00:33]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報