link もっと前
   2019年 1月 13日 -
      2019年 1月 4日  
link もっと後

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

日々

link permalink

ROCK64 と Tinker Board の U-Boot 設定メモ

ROCK64 の話へのリンク一覧。

完全に自分のためのメモですが、ROCK64 と Tinker Board で使用している U-Boot の distro boot の設定ファイル(extlinux.conf)を貼っておきます。

ROCK64

オリジナルのファイルに linux-next の起動用設定(label kernel-next の部分)を追加しました。

ROCK64 の extlinux.conf

menu title select kernel

label kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524
    kernel /boot/vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
    initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
    devicetreedir /boot/dtbs/4.4.132-1075-rockchip-ayufan-ga83beded8524
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

label kernel-next
    kernel /boot/Image
    initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
    fdt /boot/rk3328-rock64.dtb
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4

label kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524-memtest
    kernel /boot/vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
    initrd /boot/initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
    devicetreedir /boot/dtbs/4.4.132-1075-rockchip-ayufan-ga83beded8524
    append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4 memtest
ROCK64 のカーネル更新
クロスコンパイル用マシンにて実行

$ cd linux-next
$ scp arch/arm64/boot/Image arch/arm64/boot/dts/rockchip/rk3328-rock64.dtb 192.168.1.xxx:~/


Rock64 にて実行

$ sudo cp Image /boot/ ; sudo cp rk3328-rock64.dtb /boot/ ; sync ; sudo reboot

CPU が AArch64 なので生成されるイメージファイルは Image です。デバイスツリーは rk3328-rock64.dtb です。ネットワーク経由で ROCK64 のユーザ(なんでもよいですが)のホームディレクトリにコピーし、ボード側で /boot にコピーして使っています。また initrd はオリジナルのものを拝借しています。

1行目の menu title select kernel が結構大事で、この行を書いておくと U-Boot がカーネルを起動する際に下記のような選択肢が表示されます。

U-Boot の menu
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1433 bytes read in 28 ms (49.8 KiB/s)
select kernel
1:      kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524
2:      kernel-next
3:      kernel-4.4.132-1075-rockchip-ayufan-ga83beded8524-memtest
Enter choice: 

この設定はとにかくボードから SD カードの抜き差しをやりたくない一心でできています。

  • オリジナルのカーネル(選択肢 1番)と linux-next カーネル(選択肢 2番)を簡単に切り替えられる
  • 何もしないときは安全サイドに倒れる(=時間切れで選択肢 1番が勝手に選ばれる)

普段は boot メニューで 2番を選び linux-next カーネルを起動します。もし起動しないカーネルを書き込んでしまったり、ネットワークが死んでいるカーネルを書き込んでしまい、カーネルの更新ができなくなったときは、リブートし 1番を選び元々書かれていたカーネルを起動して復旧させます。

何も選択せず放置すると 1番が勝手に選ばれますので、おかしくなったら電源を ON/OFF して放置すれば、必ずオリジナルのカーネルが起動します。ボードが少し遠くに置いてあって、AC 電源 ON/OFF から U-Boot の選択肢タイムアウトまでの間にキー入力ができないので、このような設定にしています……。

Tinker Board

Tinker Board の設定も同じ思想で作っています。

Tinker Board の extlinux.conf

# cat /boot/extlinux/extlinux.conf
menu title select kernel

label kernel-4.4
    kernel /zImage
    fdt /rk3288-miniarm.dtb
    append  earlyprintk console=ttyS1,115200n8 root=/dev/mmcblk0p2 rw init=/sbin/init

label kernel-next
    kernel /linux-next
    fdt /rk3288-tinker.dtb
    append  earlyprintk console=ttyS1,115200n8 root=/dev/mmcblk0p2 rw init=/sbin/init
ROCK64 のカーネル更新
クロスコンパイル用マシンにて実行

$ linux-next
$ scp arch/arm/boot/zImage arch/arm/boot/dts/rk3288-tinker.dtb 192.168.1.xxx:~/


Tinker Board にて実行

# cp /home/katsuhiro/zImage /boot/linux-next; cp /home/katsuhiro/rk3288-tinker.dtb /boot/; sync; reboot

ROCK64 との違いは CPU が AArch32 なので生成されるイメージファイルは zImage であることと、デバイスツリーは rk3288-tinker.dtb であることでしょうか。

カーネルをネットワーク経由で更新する点は同じですが、zImage というファイル名だと元々存在するカーネルと被っているので、リネームしています。

[編集者: すずき]
[更新: 2019年 1月 13日 21:44]
link 編集する

コメント一覧

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



link permalink

Hello! Zephyr OS!!

海外で最近話題らしい Zephyr OS を動かしてみました。

Linux に似ている、という説明をどこかで見ましたが、ビルドシステムに関して言えば全く似ていません……。コードは似ているのかもしれませんが、見ていません。

動かし方は Zephyr OS の Getting Started にあります。

事前準備

Zephyr OS をビルドするためには、いくつか Python のパッケージをインストールする必要があります。pip を実行しても良いという方は pip3 install --user -r zephyr/scripts/requirements.txt で、依存するモジュールをインストールしてくれるそうです。

私は以前 pip で Python 環境が壊れて嫌な思いをしたので、apt-get で頑張りました。参考までに下記のパッケージをインストールしています。環境は Debian Testing amd64 版です。

apt-get でインストールしたパッケージ(参考)
python3-colorama python3-yaml python3-pyelftools
python3-sphinx-rtd-theme sphinx-rtd-theme-common python3-breathe
ninja-build sphinx-common

パッケージが足りない場合の探し方ですけども、パッケージが足りないときは Python のエラーメッセージに ModuleNotFoundError: No module named 'aaaa' こんなメッセージが出ることが多いです。apt-file search aaaa を実行すると、パッケージ名がずらーっと出てきますので、その中から python3- で始まるパッケージを探してください(Python3 モジュールのパッケージは python3-xxxx という名前が多い)。

コードの取得

Getting Started の通り
git clone https://github.com/zephyrproject-rtos/zephyr
です。

クロスコンパイラの準備

Getting Started には Zephyr SDK とやらをインストールせよと書いてありますが、色々大切な部分が全部ぶっ飛んでいてわからなくなっている感じがします。幸い crosstool-NG にも対応していると書いてあったので、crosstool-NG を使ってみました。

基本的には以前紹介した(2018年 7月 15日の日記参照)、AArch64 Linux 用の環境と同じ手順ですが、./ct-ng menuconfig で設定する項目が多少違います。

crosstool-NG ビルド
$ ./ct-ng menuconfig

Target options --->
  Target Architecture   --->
    arm にする
  Bitness:   --->
    32-bit にする

Toolchain options  --->
  Tuple's vendor string
    zephyr にする

Operating System  --->
  Target OS   --->
    bare-metal にする


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

しばらく待つと arm-zephyr-eabi というプレフィクスを持つクロスコンパイラが生成されるはずです。

クロスコンパイラの指定

Zephyr OS のビルドに使用するクロスコンパイラを、~/.zephyrrc に環境変数を定義して指定します。変な作りだなあ……。

クロスコンパイラの指定

export ZEPHYR_TOOLCHAIN_VARIANT=xtools
export XTOOLS_TOOLCHAIN_PATH=/home/katsuhiro/x-tools

注意点としては XTOOLS_TOOLCHAIN_PATH の x-tools の後のパスは勝手に arm-zephyr-eabi が使われ、自由に指定できないことです。この点については Linux の CROSS_COMPILE 環境変数とは異なるうえ、Zephyr の方が後発にも関わらず退化しています。どうしてこうなった……。

ビルド準備

ビルドする前に 2手ほど準備が必要です。1手目は環境変数のセットアップです。

環境変数のセットアップ
cd zephyr
source zephyr-env.sh

2手目は cmake の実行です。

cmake の実行
$ cd sample/hello_world
$ mkdir build

$ cd build
$ cmake -GNinja -DBOARD=qemu_cortex_m3 ../

Zephyr version: 1.13.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.2", minimum required is "3.4")
-- Selected BOARD qemu_cortex_m3
Parsing Kconfig tree in /home/katsuhiro/share/projects/oss/zephyr/Kconfig
Loading /home/katsuhiro/share/projects/oss/zephyr/boards/arm/qemu_cortex_m3/qemu_cortex_m3_defconfig as base
Merging /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/prj.conf
Configuration written to '/home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build/zephyr/.config'
-- Loading /home/katsuhiro/share/projects/oss/zephyr/boards/arm/qemu_cortex_m3/qemu_cortex_m3.dts as base
-- Overlaying /home/katsuhiro/share/projects/oss/zephyr/dts/common/common.dts
-- Cache files will be written to: /home/katsuhiro/.cache/zephyr
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/katsuhiro/x-tools/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc
-- Performing Test toolchain_is_ok
-- Performing Test toolchain_is_ok - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build

CMake を採用しているプロジェクトは大抵、ソースコードのトップディレクトリにある CMakeLists.txt を指定しますが、Zephyr OS の場合、sample/* の下にある CMakeLists.txtを使わなければなりません。わからんわ、そんなの。変な作りだな……。

間違って Zephyr OS のトップディレクトリにある CMakeLists.txt を指定すると、こんなエラーメッセージで怒られます。

cmake を間違ってトップディレクトリの CMakeLists.txt に対して実行したとき
$ cmake -GNinja -DBOARD=qemu_cortex_m3 ../
CMake Error at CMakeLists.txt:13 (message):
  A user error has occured.

  cmake was invoked with '/home/katsuhiro/share/projects/oss/zephyr'
  specified as the source directory,

  but it must be invoked with an application source directory,

  such as '/home/katsuhiro/share/projects/oss/zephyr/samples/hello_world'.

  Debug variables:

  CMAKE_CACHEFILE_DIR:



CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.13)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!

エラーメッセージからは、何が悪いのか全く分かりません……。

ビルドと実行

ビルドと実行は難しくありません。どちらかというとここまでたどり着くのがかなり面倒くさいです。

ビルドと実行
$ cd sample/hello_world/build
$ ninja
[1/103] Preparing syscall dependency handling
 
[98/103] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:        8604 B       256 KB      3.28%
            SRAM:        4160 B        64 KB      6.35%
        IDT_LIST:         120 B         2 KB      5.86%
[103/103] Linking C executable zephyr/zephyr.elf


$ ninja run
[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m3
qemu-system-arm: warning: nic stellaris_enet.0 has no peer
***** Booting Zephyr OS zephyr-v1.13.0-3162-g73956a398e *****
Hello World! qemu_cortex_m3

何をしているのか全然わかりません。仕方ないので build.ninja ファイルから qemu を実行しているところを発掘してみたら、下記のコマンドを実行しているようです。

実際に実行しているコマンド
$ /usr/bin/qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -vga none -net none -pidfile qemu.pid -serial mon:stdio -kernel /home/katsuhiro/share/projects/oss/zephyr/samples/hello_world/build/zephyr/zephyr.elf

qemu-system-arm: warning: nic stellaris_enet.0 has no peer
***** Booting Zephyr OS zephyr-v1.13.0-3162-g73956a398e *****
Hello World! qemu_cortex_m3

期待される結果が良くわからないんですが、これで動いたと言って良いんだろうか…??

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

コメント一覧

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



link permalink

スマートプラグの利用規約

TP-Link のスマートプラグを利用するには KASA Smart というアプリをスマホに入れないと微塵も動きません。このアプリの利用規約には同意不可能な条項があって、

法的資格
(中略)お客様は利用にあたりお客様に適用するすべての法律を遵守しなければなりません。準拠法が利用を禁ずる場合はお客様は本サービスを利用することはできません。

ユーザーのコンテンツ
(中略)
2. 世界のあらゆる場所で享受できるユーザーコンテンツに対する全ての人格権を放棄し、そのような権利の主張ができないことを確認する。

と書いてあります。TP-Link は、ユーザーがフォーラムに投稿した質問、レビュー、回答などを勝手に使うけど、文句言わないでね?と言いたいみたいです。

その主張については同意しますけど、、、

日本では著作者人格権は譲渡できません(著作権法 59条)、放棄規定はありませんが、包括的に放棄はできないと考えられており、日本において TP-Link の利用規約に Yes と答えることはできません。

規約内で矛盾がある場合に、利用者が同意してしまうと、この契約はどうなるんでしょう、無効になるの…?

TP-Link は中国の会社ですから、この利用規約は中国でもほぼ同じなのではないかと思うんですが、中国って著作者人格権の放棄はできるんですかね?

スマートプラグを使ってみた

規約のことは忘れて、スマートプラグを使ってみました。

スマホから電源 ON/OFF の指示を送ると、スマートプラグから「カッ!!」というかなり大きめのリレー音がしてうるさいです。今日も元気なことがわかって安心……?

使って初めて知ったのですが、スマホからスマートプラグへの電源 ON/OFF の指示は必ず TP-Link のサーバーに飛んで行くんですね。インターネット接続のできない場所ではスマホのアプリが起動しないため、電源 ON/OFF 指示ができません。

インターネット接続がなくても、スマートプラグ本体の電源ボタンを押せば電源 ON/OFF できますが、そこまで行けるなら Tinker Board を直接リセットした方が遥かに早いです。

昔のネットワーク対応電源タップとの違い

昔から、ネットワーク対応の AC タップは売られていましたが(Ping を打つと電源が落ちる、Web インタフェースで ON/OFF できるなど)、いずれも 1万円〜数万円の製品です。

従来製品と比較して、サーバーの維持費も追加で必要なはずなのに、大抵のスマートプラグは 2,000円〜5,000円で販売されています。機能の割に破格の値段だと思います。

単純に考えると、外出中(=インターネット側から)に、宅内の電源を ON/OFF するため、何らかのサーバーを経由しているのでしょう。

嫌らしく考えると、スマートプラグはサーバーを経由させることで、ユーザーの生活情報を強制的に奪えますから、将来に情報が何かに使えることを見込んで、破格の値付けでばら撒いているのでしょう。

[編集者: すずき]
[更新: 2019年 1月 12日 23:39]
link 編集する

コメント一覧

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



link permalink

スマートプラグ

Tinker Board 上で linux-next を実行すると reboot 時にハングしてしまい、その後ウンともスンとも言わなくなるので、外部からボードの電源 ON/OFF する方法を探していました。考え付いた方法は 3つです。

リセット信号を外部から送る
Tinker Board はリセットスイッチが搭載されているので、リセットスイッチを物理的に外して、別のボードの GPIO などを繋げばリセットできます。
USB の電源を ON/OFF する
USB micro B プラグでの給電のため、USB の電源を ON/OFF することができれば、コールドリセットできます。
AC ON/OFF する
当たり前ですが AC アダプタ(AC 100V → USB)の電源を ON/OFF すれば、コールドリセットできます。

1番目は下手なハンダ付けをして、失敗するとボードが壊れることと、制御用にもう 1つボードが要るのは何だかダサいのでやりたくありません。

2番目の線で探していたのですが、USB の給電を ON/OFF できる製品って、意外とないですね……。

仕方なく 3番目の線で、TP-Link のスマートプラグ HS105 を購入しました(メーカーの製品サイト)。Amazon で 2,600円です。Wi-Fi が内蔵されている割に、ずいぶん値段が安いですね。

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

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

コメント一覧

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



link permalink

linux-next で ROCK64 のオーディオが動かない、その 7

  • 2018年 10月 14日 - I2S と クロックレジスタ
  • 2018年 11月 10日 - I2S の DMA 問題と、残りの 3つの問題
  • 2018年 11月 11日 - I2S2 を認識しない問題解決(DMA チャネル数の問題だった)
  • 2018年 11月 28日 - I2S1 が動かない問題解決(クロックゲート定義のバグを直した)
  • 2018年 11月 29日 - アナログオーディオが動かない問題解決(ACODEC ドライバがなかったから移植)
  • 2018年 12月 23日 - 44.1kHz の PCM を再生できない問題解決(GPLL クロック定義のバグを直した)
  • 2019年 1月 5日 - 32kHz → 44.1kHz の順で PCM を再生できない問題解決(fractional divider の実装を変えた)

ROCK64 で 32kHz → 44.1kHz の順に再生するとエラーになる

年末に喰らった A 型インフルエンザのダメージも回復したので、RK3328 の I2S1 の MCLK(マスタークロック)の設定がおかしくなる問題の追跡を再開しました。

思っていた以上に難しくて理解できず、かれこれ 1週間以上費やしてしまいましたが、やっと見えてきました。

ざっくり言えば Rockchip の SoC が持つクロック分周器の構成がかなり変わっていることが関係している、と言えるんじゃないでしょうか。良し悪しはさておいて、問題の原因になっています。

現象と再現方法

再現方法はとても簡単です。48kHz → 44kHz の順で再生すると正常に再生できますが、32kHz → 44kHz の順で再生するとエラーになって再生できません。これだけです。

Rockchip のクロックと分周器

早速、問題の原因を説明したいところですが、Rockchip のクロックがどのように繋がっているか説明しないと、全く何も意味が分からないと思いますので、軽く説明します。

RK3328 や Rockchip の 他の SoC は、1〜128分周まで可能な Integer Divider と、有理数で分周(例えば 7/500 など、分子、分母は 16ビット精度の整数で指定可能)が可能な Fractional Divider の 2つを持っています。

RK3328 の TRM(Technical Reference Manual)では、前者に i2s1_pll_div、後者に i2s1_frac_div という名前を付けており、Linux のクロックドライバでは前者に clk_i2s1_div、後者に clk_i2s1_frac という名前を付けています。

媒体 Integer Divider Fractional Divider
TRM(Technical Reference Manual) i2s1_pll_div i2s1_frac_div
Linux Clock ドライバ clk_i2s1_div clk_i2s1_frac

今後は Linux の名前で表記しますが、接頭辞の clk_ は省きます。

Rockchip の I2S クロック

I2S 系のクロックは Integer Divider と Fractional Divider の両方を利用可能です。他のハードウェアブロックは Integer Divider しか使えませんが、UART と I2S と S/PDIF は両方使えるようです。

PLL と分周器と I2S1 の接続は下記のようになっています。

PLL, 分周器, I2S1 のクロック接続関係
CPLL --> | selector |-----> i2s1_div --+--> | selector |--> I2S1 MCLK
GPLL --> |          |  ,---------------'    |          |
                       `--> i2s1_frac ----> |          |

図からもわかる通り、必要に応じて i2s1_frac は使ったり、使わなかったりします。

例えば 48kHz, 32kHz で再生する場合は、GPLL -> i2s1_div -> I2S1 の経路が使われます。i2s1_frac は使いません。44kHz で再生する場合は、GPLL -> i2s1_div -> i2s1_frac -> I2S1 の経路が使われます。

サンプリング周波数 Fs と、正しく再生できているときの各分周器の出力周波数、分周比は下記のとおりです。

Fs i2s1_div 出力 i2s1_div 分周比 i2s1_frac 出力 i2s1_frac 分周比
32kHz 8.192MHz 1/60 未使用 未使用
44.1kHz 491.52MHz 1/1 11.2896MHz 147/6400
48kHz 12.288MHz 1/40 未使用 未使用

ちなみに i2s1_div の入力は GPLL が選択されることが多く、周波数は 491.52MHz で固定のようです。CPLL/GPLL の周波数は可変のはずですが、切り替わったところを見たことがありません。まあ、GPLL は今回の話に関係ないから、どうでも良いですけど……。

クロックドライバの動作

Linux のクロックドライバは、セレクタで選択可能なクロック系統(この場合だと i2s1_div と i2s1_frac)全てに対して、同じ目標周波数で設定して、目標に一番近い周波数を出力できるクロック系統を選択する仕組みになっています。

例えば先ほど 44.1kHz の再生のときは i2s1_frac が選ばれると言いましたが、実はこのときクロックドライバの裏側では、

  • i2s1_div: CPLL 1.2GHz / 107 = 11.214954MHz
  • i2s1_frac: i2s1_div 491.52MHz * 147/6400 = 11.2896MHz

この 2つの選択肢(※)が提示されており、i2s1_frac の方が目標値に近い(誤差 0)ため、i2s1_frac が選択されています。

(※)正確に言うと 12MHz clkin もあるので 3つの選択肢から選びますが、ここでは説明を省いています。12MHz clkin が選ばれることはほぼありません。

問題の原因

先ほど示した表のとおり、32kHz の再生後は i2s1_div の出力が 8.192MHz になります。この状態で 44.1kHz を再生しようとすると、クロックドライバは i2s1_frac の出力を 11.2896MHz にしようと試みます、しかし…。

今のクロックドライバは i2s1_frac の親にあたるクロック、つまり i2s1_div の周波数が目標の出力周波数 11.2896MHz より低いと、設定を諦めてしまう実装になっています。

コードで言うとこの部分です。

Fractional Divider のドライバ(一部)

//drivers/clk/clk-fractional-divider.c

static long clk_fd_round_rate(struct clk_hw *hw, unsigned long rate,
			      unsigned long *parent_rate)
{
	struct clk_fractional_divider *fd = to_clk_fd(hw);
	unsigned long m, n;
	u64 ret;

	if (!rate || rate >= *parent_rate)  //★★この部分★★
		return *parent_rate;

	if (fd->approximation)
		fd->approximation(hw, rate, parent_rate, &m, &n);
	else
		clk_fd_general_approximation(hw, rate, parent_rate, &m, &n);

	//...

32kHz → 44.1kHz の再生時は rate = 11.2896MHz, *parent_rate = 8.192MHz となり、★の部分の if 文が発動します。これは「i2s1_frac は 8.192MHz しか設定できません」という結果を返すことと等しいです。

この結果を受けたクロックドライバの選択肢は下記のようになります。

  • i2s1_div: CPLL 1.2GHz / 107 = 11.214954MHz
  • i2s1_frac: i2s1_div 8.192MHz

いずれも目標の 11.2896MHz と合いませんが、目標に近いのは i2s1_div と言えます。このためクロックドライバは i2s1_div が最適と判断し、I2S1 のマスタークロックが 11.214954MHz というおかしな値に設定されてしまいます。

このマスタークロック周波数は、サンプリング周波数 44.1kHz の整数倍ではないため、サウンドドライバがエラーと判断して PCM 再生を止めてしまいます。

48kHz → 44.1kHz の再生で問題が起こらない理由

48kHz → 44.1kHz の再生時は rate = 11.2896MHz, *parent_rate = 12.288MHz となるため、★の if 文を突破して fd->approximation の呼び出しに到達します。Rockchip の Fractional divider の場合、この関数ポインタは rockchip_fractional_approximation() 関数を指しています。

この関数は変わった処理で、ある条件を満たすと、親のクロックを使うのを諦めて、親の親のクロックを使う処理になっています。

Rockchip の Fractional Divider ドライバ(一部)

static void rockchip_fractional_approximation(struct clk_hw *hw,
		unsigned long rate, unsigned long *parent_rate,
		unsigned long *m, unsigned long *n)
{
	struct clk_fractional_divider *fd = to_clk_fd(hw);
	unsigned long p_rate, p_parent_rate;
	struct clk_hw *p_parent;
	unsigned long scale;

	p_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
	if ((rate * 20 > p_rate) && (p_rate % rate != 0)) {  //★★目標値が親クロックの 20倍より大きく、割り切れないとき★★
		p_parent = clk_hw_get_parent(clk_hw_get_parent(hw));  //★★親の親(CPLL か GPLL)を使う★★
		p_parent_rate = clk_hw_get_rate(p_parent);
		*parent_rate = p_parent_rate;
	}

通常ならば、存在するかどうかわからない「親の親のクロック」の存在を仮定しており、Rockchip のクロックトポロジー(PLL -> i2s1_div -> i2s1_frac)と、ハードウェア制約に強く依存した特殊な処理になっていることが伺えます。

しかし、この特殊処理のおかげで i2s1_div の周波数が i2s1_frac にとって扱いづらい変な値に設定されていたとしても、親の親(CPLL か GPLL)の周波数に戻すことができます。

48kHz → 44.1kHz の再生時に i2s1_frac だけでなく、i2s1_div の周波数まで変わってしまっているのは、なんだか不思議だなあと思った方も居るかもしれません。その理由は、この関数が親クロックの周波数目標値を書き換えてしまうから、だったんです。

参考

ここまで読んでいただいている方はほぼゼロだと思いますが……、分周器 i2s1_div と i2s1_frac の設定が可能かどうか?どちらを選ぶべきか?を判定する部分は、こんな感じの呼び出し経路になっています。

クロック周波数設定時のコールツリー

rockchip_i2s_set_sysclk
  clk_set_rate
    clk_core_set_rate_nolock
      clk_core_req_round_rate_nolock
        clk_core_get_boundaries
        clk_core_round_rate_nolock // I2S1 クロックの設定
          clk_core_determine_round_nolock
            clk_mux_determine_rate
              clk_mux_determine_rate_flags // I2S1 手前のセレクタの設定
                __clk_determine_rate
                  clk_core_round_rate_nolock       // i2s1_div の設定
                    clk_core_determine_round_nolock
                      clk_composite_determine_rate // i2s1_div のセレクタの設定
                        clk_divider_round_rate // Integer divider の設定
                __clk_determine_rate
                  clk_core_round_rate_nolock   // i2s1_frac の設定
                    clk_core_determine_round_nolock
                      clk_composite_round_rate // i2s1_frac のセレクタの設定
                        clk_fd_round_rate      // Fractional divider の設定
                          rockchip_fractional_approximation // Rockchip の Fractional divider 固有の設定

何度も同じ関数名が出てきて奇妙に見えると思いますが、目標となるクロック周波数の設定を 1ブロックだけで解決できないとき、親クロックに対して再帰呼び出しを行い、親の設定を変更しようとする仕組みになっています。

良くできている素晴らしい仕組みだとは思うのですが…、関数ポインタを使って高度に抽象化されているため、コードを見てもどの関数が呼ばれるのか、もう全く全然わかりません。動作もかなり追いづらいし、デバッグが辛いです……。

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

コメント一覧

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



link permalink

git プロトコルの社内プロキシ越え

Yocto を使ったプロジェクトをビルドする際に、Git プロトコルを使わないとアクセスできないリポジトリがあります。

Git プロトコル(git:// から始まる URL のリポジトリ)は無害なんですけど、大抵の社内プロキシを越えられなくて苦労するので、越え方をメモしておきます。

まず Git のプロキシ設定を行います。この例では git-proxy というコマンドを使ってくれと指示しています。

Git 側の設定

git config --global --add core.gitProxy git-proxy

そんなコマンドはないので、自分で作ります。パスの通った場所、例えば ~/bin/git-proxy のようなファイルを作成して、下記のシェルスクリプトを書いておきます。

自作 Git プロキシコマンド

#!/bin/sh

exec socat STDIO PROXY:192.168.x.x:$1:$2,proxyport=8080

もちろん別途 socat コマンドのインストールが必要です。Debian なら apt-get install socat でインストールできます。

最初は netcat でやってみたんですがダメでした。何でだろ?

[編集者: すずき]
[更新: 2019年 1月 6日 20:12]
link 編集する

コメント一覧

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



link もっと前
   2019年 1月 13日 -
      2019年 1月 4日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

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

最終更新: 5/11 15:12

カレンダー

<2019>
<<<01>>>
--12345
6789101112
13141516171819
20212223242526
2728293031--

最近のコメント 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 サイトの情報