link もっと前
   2019年 3月 5日 -
      2019年 2月 24日  
link もっと後

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

日々

link permalink

RockPro64 のシリアル文字化け - 結論

RockPro64 シリアル文字化けの話のまとめ。

RockPro64 のシリアル UART2 が文字化けする問題に決着がつきました。

LKML(Linux Kernel Mailing List)に生息するナイスガイ達のおかげで、自分が持っている RockPro64 だけが異常値を示していることがわかりました。皆、普通にオシロスコープ持っているみたいですし、アイパターンまで見ていた人もいて、LKML すげーな……と感心しました。

私のボードは、おそらくどこかにハンダ不良があり、RK3399 から UART2 ピンまでの抵抗値が異常に高くなっていると推測されます。

テスターで抵抗値を見ればわかるはずですが、RockPro64 はボードのシルクに部品番号が全く書いておらず、どこにプローブを当てたら良いかさっぱりわかりませんでした。残念。

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

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

コメント一覧

  • kml 
    > 自分が持っている RockPro64 だけが異常値を示していることがわかりました。

    オシロの波形見てて気がつかなかったのかな?

    以下、具体例だが
    https://github.com/ayufan-rock64/linux-build/releases/download/0.7.9/bionic-minimal-rockpro64-0.7.9-1067-arm64.img.xz
    https://github.com/ayufan-rock64/linux-build/releases/download/0.7.14/bionic-minimal-rockpro64-0.7.14-1081-arm64.img.xz
    前者は、比較的マシだがその兆候は出てる。
    後者は、貴方が提示した写真とほぼ同等で、操作不能な程のレベル
    (どのkernel、例えば "armbian" でもその兆候は出ているが、その程度は上記前者レベル
     多少の取りこぼしはあるかもしれないが、まだ十分操作可能なレベル)

    何れも u-boot の段階では問題無いのに、kernelに制御が移った後で ご指摘の症状
    私の手持ち全てが(3台)同一症状、kernel依存と見るのが妥当だと思うな

    もし、貴方が指摘した際に使ったものと同一のkernelを使えば おそらく全数がそうなる

    それと、同等の報告が 既に去年の夏頃に挙がってる
     
    (2019年03月20日 21:30:58)
  • すずき 
    > オシロの波形見てて気がつかなかったのかな?

    えーと、私が他のカーネル(ayufan-rock64 とか)の動作を見なかったのか?という意味でしょうか?
    そういう意味でしたら linux-next 以外は見ていないです。


    > 何れも u-boot の段階では問題無いのに、kernelに制御が移った後で ご指摘の症状

    確かに U-Boot は文字化けしないですね。Drive Strength の設定を見るとデフォルト値(3mA)だったので、他の設定が影響しているのかもしれません。

    後で U-Boot の UART2 出力についても、オシロスコープで波形見てみます。


    > 私の手持ち全てが(3台)同一症状、kernel依存と見るのが妥当だと思うな

    情報ありがとうございます。

    うーん、そうなんですか。私は 1台しか持っていないので個体不良かどうか見分けがつかないです。

    海外の人たちはなぜ同じ症状に遭遇しないのだろう。。。
     
    (2019年03月21日 17:45:56)
open/close この記事にコメントする



link permalink

RockPro64 のシリアル文字化け - LKML での議論

RockPro64 シリアル文字化けの話のまとめ。

メンテナーの Heiko さんからは「共通部分を変えようとしているから、他のボードの関係者にも聞いてくれ」とのことでした。そりゃそうだなと、RK3399 のボードのデバイスツリーを変えていそうな人達に CC でメールしてみたところ、お返事がきました。

Tony さんは、ROC RK3399 PC と RockPro64 の 2つのバージョン(V2.0 と V2.1、私が持っているのは V2.1)など、色々なボードでの立ち上がり、立ち下がり時間の測定値を教えてくれました。いずれも私が観測しているような症状はないとのことです。

Robin さんは、アイパターンを見てくれて、やっぱり異常はないと教えてくれました。

念のため、ピンに何か繋いでいる(インピーダンスが低い、立ち上がり時間が遅く計測される)のか、何も繋いでいない(インピーダンスが高い、立ち上がり時間が速く計測される)のかも確認しましたが、UART-USB 変換ボードをジャンパケーブルで繋いでいるとのことでした。

うーん。話を総合すると、どうも私のボードの個体不良っぽいです。パッチは取り下げておきました。やりとりは面白かったですが、結果的には皆さんを混乱させてしまっただけでしたね。

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

コメント一覧

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



link permalink

RockPro64 のシリアル文字化け - パッチ投稿

RockPro64 シリアル文字化けの話のまとめ。

(主に俺のために)RockPro64 のシリアル文字化けを直すべく、Rockchip RK3399 のシリアル UART2 の drive strength を 3mA から 12mA にするパッチを LKML(Linux Kernel Mailing List)に送ってみました。ま、ダメ元です。

RockPro64 だけ何でこんなに Rising time が長くなるのでしょう?

Rockchip RK3328 搭載の Rock64 は、特に問題がないように見えます。RockPro64 同様に Rock64 も RK3328 から Pi-2 コネクタに直で信号を出しているはずなのに。

RK3399 の方がプロセス進んでるから、I/O ドライブ性能が低いのでしょうか。結局、問題の原因は良くわからないままです。

パッチを送ってから気づいたのですが、タイトルに RK3399 向けのパッチと説明を忘れていたり、RockPro64 しか確認できていない症状なのに、共通ファイル rk3399.dtsi に変更入れていたり、色々マズいです。そんなもん RockPro64 のデバイスツリーに入れてよ……、ってリジェクトされる気がします。

おそらく他の RK3399 のボードも RK3399 と UART のピンを直結していれば、同じ症状が起きると思うんですが、私は他のボード持っていないからわかりません。

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

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

コメント一覧

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



link permalink

作業スペース

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

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

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

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

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

コメント一覧

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



link permalink

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

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

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

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

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

クロスコンパイラ

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

crosstool-NG ビルド
$ ./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 のビルドとほぼ同じです。

linux-next コード取得、セットアップ、ビルド
$ 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 を渡してあげる必要があるみたいです。

ブートローダ riscv-pk コード取得、セットアップ、ビルド
$ 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 を作ります。

busybox コード取得、セットアップ、ビルド
$ 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 で固めるだけです。

initramfs 作成
$ 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 実行
$ 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 の起動画面を拝めました。良かった良かった。

[編集者: すずき]
[更新: 2019年 2月 27日 01:32]
link 編集する

コメント一覧

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



link もっと前
   2019年 3月 5日 -
      2019年 2月 24日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

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

最終更新: 6/17 23:30

カレンダー

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

最近のコメント 5件

  • link 19年05月17日
    すずき 「試してみたら、同じみたいです。\nわざわ...」
    (更新:05/25 10:35)
  • link 19年05月17日
    hdk 「実際に試したわけではないので素朴な疑問な...」
    (更新:05/23 21:07)
  • 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)

最近の記事 3件

link もっとみる
  • link 19年06月15日
    すずき 「[GCC を調べる - その 4 - RTL を眺める] RTL ...」
    (更新:06/17 23:30)
  • link 19年06月14日
    すずき 「[GCC を調べる - その 3 - RTL の出力] GCC の...」
    (更新:06/17 22:25)
  • link 19年06月03日
    すずき 「[抗生物質] 病院に行くと大抵の場合、何らかの抗生物質が処方されま...」
    (更新:06/09 15:04)

こんてんつ

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