link もっと前
   2019年 3月 25日 -
      2019年 3月 16日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

RockPro64 のシリアル文字化け - U-Boot との比較

RockPro64 シリアル文字化けの話のまとめ、第二章。

RockPro64 は「U-Boot だと文字化けしない」という指摘をいただいたので確認したところ、確かに文字化けしません。

Drive Strength の設定はデフォルト値(3mA)のままにも関わらず、オシロスコープで UART TX 側の波形を見ると Rise/Fall Time が 77ns/59ns と優秀な値です。


RockPro64 U-Boot のシリアル出力の波形

とりあえずボード不良ではなかったことがわかって良かったものの、何が原因で linux-next は文字化けしているかわからず、振出しに戻ってしまいました。

あえて波形を劣化させる設定?

電源 ON から波形を観察し続けると linux-next もブートプロンプトの途中までは波形が綺麗です。linux-next は途中で波形が鈍る設定をわざとしていることになります。

原因がわからないので、当てずっぽうでデバイスツリーの色々なノードを ON/OFF していったところ、io_domains ノードの audio-supply プロパティを変更すると UART TX の波形が劣化することがわかりました。

このプロパティを読み取るドライバは drivers/power/avs/rockchip-io-domain.c にあります。追ってみると RK3399 の GRF のレジスタ 0xff77e640 の bit 1(audio_gpio3d4a_ms)の値を設定していました。仕様書を見ると IO domain(とは何だ?)の駆動電圧を設定するビットでした。クリアすると 3.0V、セットすると 1.8V の意味です。

現在の linux-next は 1.8V 設定にしており、波形が鈍っています。U-Boot はレジスタに何も設定しないらしく、デフォルトの 3.0V 設定のままでした。

試しに linux-next 起動後、UART TX の波形が鈍ったことを確認したのちに、audio_gpio3d4a_ms を無理やりクリア、つまり IO domain works as 3.0V 設定に変えてみたところ、波形がシャキーンと綺麗になりました。

ああー、原因はこれだ。

どう直すべきか

レジスタの値を色々変えてみたところ、bit 1 audio_gpio3d4a_ms を 3.0V にするか、bit 1 audio_gpio3d4a_ms と bit 3 gpio1830_gpio4cd_ms を両方とも 1.8V 設定に変えると直ることがわかりました。

しかし RockPro64 の回路図を見ると、GPIO1830 は 3.0V で、VCCA1V8 は 1.8V に設定する方が正しいように見えます。

正しいはずの設定になのに UART の波形が鈍ってしまい、設定を間違えているはずの U-Boot は UART の波形が綺麗です。どうしてこうなるのか良くわかりません。原因はわかったものの、真因がわからなくて直し方もわからない、困ったタイプですね。

おまけ

IO domain を 3.0V に変更し、Drive Strength 12mA の設定と組み合わせると、Rise/Fall Time が 30ns/34ns とさらに速くなります。


IO domain 3.0V + Drive Strength 12mA のときの RockPro64 シリアル出力の波形

あまりに急激に立ち上がりすぎるせいか、良く見ると Rise Edge がオーバーシュートしていますね……。

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

[編集者: すずき]
[更新: 2019年 4月 1日 01:49]
link 編集する

コメント一覧

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



link permalink

レジスタダンプ、書き換えツール memaccess

ツールのソースコードは GitHub に置いています

前職のころレジスタダンプと、レジスタ値書き換えのための fa という素敵なアプリ(Free Access の略と聞いた)を使っていました。

このアプリは、/dev/mem 経由でメモリの指定したアドレスを読んだり書いたりできるアプリです。何だそんなもの……と思うかもしれませんが、低レイヤデバッグには便利でして、開発の皆さんが愛用していたことを覚えています。

オリジナルの fa はデカくて無駄の多いコードだったので、何年か前に全部捨てて書き直しました。さらに他の人が書き直していなければ、今も使われているのではなかろうか?

現職とレジスタダンプ

なんと転職後もレジスタダンプが必要なシーンによく遭遇します。半導体の仕事と低レイヤデバッグは切っても切れない関係みたいです。

最初はカーネルドライバを書いて readl で読んで、printk して…、などとやっていましたが、あまりにも面倒くさくてやってられません。やっぱり fa のようなものが欲しいなあと思い立ち、土日でパパパーっと書いて、GitHub に放り込んでおきました。

アプリの実装は /dev/mem を mmap して読み書きするだけで、特に知識も要りません。たぶん誰でも書けます。

アプリの名前ですが、Free Access だと Wi-Fi スポットみたいで変だな……と思って、ma(memaccess, memory access の略)にしておきました。memory dump にしたかったのですが、有名なツールと同じ名前で紛らわしいのでやめました。

もし memory dump でレジスタ読み書きができれば、わざわざアプリを作る必要はなかったのですが、しかし memory dump はバイナリで出力する方に重きを置いており、エディト機能もなさそうで、設計の方向性が違いました……。残念。

[編集者: すずき]
[更新: 2019年 3月 27日 21:52]
link 編集する

コメント一覧

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



link permalink

初めての OpenVX on ARM

先日(2018年 11月 14日の日記参照)動かした OpenVX + OpenCV のデモを AArch64 上でも動かそうと思います。クロスコンパイルではなく ARM 上でセルフコンパイルします。環境は Debian 9、ボードは RockPro64 です。

ビルド

前回同様 OpenVX ライブラリをビルドする必要がありますが、単純に make するとビルドに失敗します。

OpenVX ライブラリのビルド on AArch64
[GCC] Compiling C99 vx_debug.c
gcc: error: unrecognized argument in option '-mabi=aapcs-linux'
gcc: note: valid arguments to '-mabi=' are: ilp32 lp64
gcc: error: unrecognized command line option '-mapcs'; did you mean '--specs'?
gcc: error: unrecognized command line option '-mno-sched-prolog'; did you mean  -Wno-sign-promo'?
gcc: error: unrecognized command line option '-mno-thumb-interwork'; did you mean '-fno-sched-interblock'?
concerto/finale.mak:289: recipe for target '/home/katsuhiro/projects/openvx/out/LINUX/aarch64/release/module/debug/vx_debug.o' failed

Makefile に不要なオプションが指定されていてビルドが失敗しているようなので、削除します。

concerto の Makefile からオプションを削除

diff --git a/concerto/compilers/gcc.mak b/concerto/compilers/gcc.mak
index aca2556..0295e39 100644
--- a/concerto/compilers/gcc.mak
+++ b/concerto/compilers/gcc.mak
@@ -125,9 +125,9 @@ endif
 endif

 ifeq ($(TARGET_FAMILY),ARM)
-$(_MODULE)_COPT += -mapcs -mno-sched-prolog -mno-thumb-interwork
+#$(_MODULE)_COPT += -mapcs -mno-sched-prolog -mno-thumb-interwork
 ifeq ($(TARGET_OS),LINUX)
-$(_MODULE)_COPT += -mabi=aapcs-linux
+#$(_MODULE)_COPT += -mabi=aapcs-linux
 endif
 endif

ちなみに cmake によるビルドも可能ですが、ARM に対応できていないように見えます。

make の設定からオプションを削除

diff --git a/cmake_utils/CMake_linux_tools.cmake b/cmake_utils/CMake_linux_tools
.cmake
index caaa017..dc2371f 100644
--- a/cmake_utils/CMake_linux_tools.cmake
+++ b/cmake_utils/CMake_linux_tools.cmake
@@ -32,10 +32,10 @@ if(BUILD_X64)
 else()
   if (TARGET_CPU STREQUAL "Atom")
     # architecture will be according to ATOM
-    set(ARCH_BIT -m32 )
+    # set(ARCH_BIT -m32 )
   else ()
     # need to force a more modern architecture than the degault m32 (i386).
-    set(ARCH_BIT "-m32 -march=core2" )
+    # set(ARCH_BIT "-m32 -march=core2" )
   endif (TARGET_CPU STREQUAL "Atom")
 endif()

正しい直し方ではありませんが、とりあえず x86 向けの設定を改造して、x86 用のオプションを外すとビルドが通ります。

サンプルのビルド

OpenVX ライブラリのビルドが通ったら、サンプルをビルドします。

concert でビルドしたライブラリを指定して、サンプルをビルド
$ cd openvx_tutorial/tutorial_exercises/solution_exercise1
$ g++ -I ../include -L /path/to/openvx/out/LINUX/aarch64/release/ solution_exercise1.cpp \
  -lopencv_imgproc -lopencv_highgui -lopencv_core -lopenvx

もし cmake でライブラリを作った場合は、ライブラリの生成先ディレクトリが異なります。下記のようにします。

cmake でビルドしたライブラリを指定して、サンプルをビルド
$ cd openvx_tutorial/tutorial_exercises/solution_exercise1
$ g++ -I ../include -L /path/to/openvx/build/sample/framework/ solution_exercise1.cpp \
  -lopencv_imgproc -lopencv_highgui -lopencv_core -lopenvx

実行する際は、HDMI 出力などの GUI 画面に表示してもよいですし、vncserver などの画面にも表示できます。下記の例は vncserver に表示する例です。

concert でビルドしたライブラリを指定して、サンプルを実行
$ DISPLAY=:1 \
  LD_LIBRARY_PATH=/path/to/openvx/out/LINUX/aarch64/release/ \
  ./a.out

もし cmake でビルドしたライブラリを使う場合、ライブラリがバラバラのディレクトリに置かれているため、LD_LIBRARY_PATH に指定するパスがやや長くなります。

cmake でビルドしたライブラリを指定して、サンプルを実行
$ DISPLAY=:1 \
  LD_LIBRARY_PATH=/path/to/openvx/build/sample/framework/:/path/to/openvx/build/sample/targets/c_model/:/path/to/openvx/build/sample/vxu/:/path/to/openvx/build/libraries/extras/:/path/to/openvx/build/libraries/debug/ \
  ./a.out

もし cmake でビルドしたライブラリでトラブルが起きたときは、cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo と指定してデバッグ情報を有効にしてビルドすることで、デバッグしやすくなります。

VNC と OpenCV

TightVNC サーバーを使うとアプリケーションの実行時に下記の警告が出ます。

VNC サーバーによっては下記の警告が出る
Xlib:  extension "RANDR" missing on display ":1".

警告が出ても動作はするのですが、気になる方は下記のように TigerVNC をインストールするなど、RANDR に対応した VNC サーバーを使ってください。

TigerVNC サーバーのインストール
# apt-get install tigervnc-standalone-server
[編集者: すずき]
[更新: 2019年 3月 25日 23:23]
link 編集する

コメント一覧

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



link permalink

たまにズレちゃう Windows 10

Windows 10 は自動的に Windows Update を実行し、勝手に PC を再起動することがあります。その際にウインドウの幅がズレることがあります。


タイトルバーとウインドウの幅がずれる

ウインドウの幅が多少ズレても実用上害はありませんが、この状態と同時に発生する、フォント表示がボヤボヤになって、サイズがおかしくなり、非常に読みづらくなる症状が辛いです。目が痛くなってきます。

いずれの症状も PC を再起動すると直ります。直る理由すらわかりませんが、今のところ直らなかったことは一度もありません。

不思議なことに Windows Update 後に必ずズレた状態になる訳ではなく、何か他の条件があるようです。人が見ていない夜中に再起動して、勝手にこの状態にハマるので、詳細は確認しようがないです。

我が家での Windows の存在意義

最近の Windows は再起動により、作業中のアプリケーションが全て終了され、当初かなりイライラしていました。

しかし今は「Windows で大事な作業をしない」ことにより、諦めがつきました。デスクトップ PC は勝手に再起動されては困るので、Windows ごと消しました。さようなら〜。

ノート PC は再起動されても特に問題ないので Windows を残しています。なぜなら最近 Windows 上で実行しているアプリケーションは、

ブラウザ
強制終了されても最後に開いていたページを覚えている。
VNC クライアント
強制終了されても Linux マシンが動き続けているので問題ない。

しかないからです。あとは、たまに音楽プレーヤーや Steam を起動しますが、起動しっぱなしにはしません。たとえ強制終了されたとしても問題はありません。

この使い方はほぼシンクライアントですね。わざわざカスタムオーダーまでして Core i5-8250 と外部グラフィックス AMD Radeon RX550 を積んだのに、彼らが Steam 以外で活用されることはありません……。

つまり、もっとゲームをやりなさいということだな??

[編集者: すずき]
[更新: 2019年 3月 23日 15:06]
link 編集する

コメント一覧

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



link permalink

RockPro64 と PCI Express

RockPro64 には PCI Express スロットが実装されています。せっかくあるので試そうと思い、玄人志向の SATA インタフェース増設カード(SATA3-PCIE-E2)と、USB 3.0 インタフェース増設カード(USB3.0R-P2H2-PCIE)を買いました。

結論から先に言うと RK3399 の PCI Express コントローラは有効にできましたが、RockPro64 の信号品質が良くないのか USB のカードしか認識しませんでした。残念です。

唯一認識される USB のカードも PCI Express のライザーカードで延長すると認識しなくなります。認識できるギリギリの信号なんですかね。

RockPro64 で PCI Express カードを認識できないときのログ
rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!

認識されないときはこんなエラーログが出ています。うーん。

有効にするだけでは動かない RK3399 の PCI Express コントローラ

RK3399 の PCIe コントローラもちょっと癖があって、ep-gpios プロパティを指定しないと probe 時にエラーで落ちます。このドライバは GPIO を使ってレギュレータを操作し、PCI Express への電源供給を制御したいようです。

通常、デバイスドライバで電源制御を実装したい場合 vpcie12v-supply のようなレギュレータを指定するプロパティを使いますが、なぜ GPIO を使っているのでしょうね……?

しかもうまくないことに RockPro64 の場合、既に PCI Express 用レギュレータのデバイスノードが定義されており、常に PCI Express の電源を ON にしています。そのため PCI Express のデバイスノードに GPIO を追加すると「もう使われているよ!」と怒られてしまいます。

どう直すのが正しいのかわかりませんが、とりあえず PCI Express のドライバを改造し、GPIO のエラー処理を削ったら先に進みました。しかし良くハングするようにもなりました。イマイチだ……。

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

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

コメント一覧

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



link もっと前
   2019年 3月 25日 -
      2019年 3月 16日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 5/11 15:12

カレンダー

<2019>
<<<03>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント 5件

  • link 19年04月01日
    すずき 「どの CPU というかシステムでも同じ傾...」
    (更新:04/05 11:03)
  • link 19年04月01日
    hdk 「去年Ryzen 7 1700で測りました...」
    (更新:04/02 22:48)
  • link 19年03月05日
    すずき 「> オシロの波形見てて気がつかなか...」
    (更新:03/21 17:45)
  • link 19年03月05日
    kml 「> 自分が持っている RockPr...」
    (更新:03/20 21:30)
  • link 19年03月10日
    すずき 「ありがとー!!」
    (更新:03/13 09:46)

最近の記事 3件

link もっとみる
  • link 19年05月09日
    すずき 「[RockPro64 の PCIe] RockPro64 の PC...」
    (更新:05/11 15:12)
  • link 19年04月29日
    すずき 「[クロスビルド用ツールチェーン - その 2] クロスビルド用ツー...」
    (更新:05/07 00:39)
  • link 19年04月27日
    すずき 「[クロスビルド用ツールチェーン - その 1] クロスビルド用ツー...」
    (更新:05/07 00:39)

こんてんつ

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 サイトの情報