コグノスケ


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

link もっと前
2019年3月4日 >>> 2019年2月19日
link もっと後

2019年3月4日

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

目次: ROCK64/ROCKPro64

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

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

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

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

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

編集者:すずき(2020/10/30 00:49)

コメント一覧

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



2019年3月3日

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

目次: ROCK64/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から転記しておくことにした。加筆した。

編集者:すずき(2020/10/30 00:49)

コメント一覧

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



2019年2月28日

作業スペース

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

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

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

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

編集者:すずき(2019/03/02 23:34)

コメント一覧

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



2019年2月26日

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日の日記を参照)なので、割愛します。

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の起動画面を拝めました。良かった良かった。

編集者:すずき(2023/09/24 11:43)

コメント一覧

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



2019年2月20日

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

編集者:すずき(2020/10/30 01:03)

コメント一覧

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



2019年2月19日

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

編集者:すずき(2023/09/24 11:42)

コメント一覧

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



link もっと前
2019年3月4日 >>> 2019年2月19日
link もっと後

管理用メニュー

link 記事を新規作成

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

最近のコメント5件

  • link 21年3月13日
    すずきさん (03/05 15:13)
    「あー、このプログラムがまずいんですね。ご...」
  • link 21年3月13日
    emkさん (03/05 12:44)
    「キャストでvolatileを外してアクセ...」
  • link 24年1月24日
    すずきさん (02/19 18:37)
    「簡単にできる方法はPowerShellの...」
  • link 24年1月24日
    KKKさん (02/19 02:30)
    「追伸です。\nネットで調べたらマイクロソ...」
  • link 24年1月24日
    KKKさん (02/19 02:25)
    「私もエラーで困ってます\n手動での回復パ...」

最近の記事3件

  • link 24年3月19日
    すずき (03/20 02:52)
    「[モジュラージャックの規格] 古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタク...」
  • link 23年4月10日
    すずき (03/19 11:48)
    「[Linux - まとめリンク] 目次: Linuxカーネル、ドライバ関連。Linuxのstruct pageって何?Linu...」
  • link 24年3月18日
    すずき (03/19 11:47)
    「[画面のブランクを無効にする] 目次: LinuxROCK 3 model CのDebian bullseyeイメージは10分...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
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 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

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

合計:  counter total
本日:  counter today

link About www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/20 02:52