コグノスケ

家のPC性能表、更新

昔（2017年5月2日の日記参照）作った我が家のPCのPassmarkスコア表に、Ryzen 7デスクトップ（2018年12月1日の日記参照）も加えました。

2年前はRyzen 7の8コアを欲しいなと思いつつも、何に使うか疑問に思っていましたが、Linuxのビルドに最適だということがわかって、とても役に立っております。買って良かった。

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

目次: ROCK64/ROCKPro64

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

ROCK64

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

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

クロスコンパイル用マシンにて実行

$ 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がカーネルを起動する際に下記のような選択肢が表示されます。

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の設定も同じ思想で作っています。

# 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

クロスコンパイル用マシンにて実行

$ 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というファイル名だと元々存在するカーネルと被っているので、リネームしています。

Hello! Zephyr OS!!

目次: Zephyr

海外で最近話題らしい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版です。

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で設定する項目が多少違います。

$ ./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の実行です。

$ 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 -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

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

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

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するため、何らかのサーバーを経由しているのでしょう。

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

スマートプラグ

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

ROCK64のアナログオーディオ - その7 - 32kHz → 44.1kHzの順でPCMを再生できない問題解決

目次: ROCK64/ROCKPro64

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という名前を付けています。

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

RockchipのI2Sクロック

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

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と、正しく再生できているときの各分周器の出力周波数、分周比は下記のとおりです。

ちなみに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より低いと、設定を諦めてしまう実装になっています。

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

//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() 関数を指しています。

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

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ブロックだけで解決できないとき、親クロックに対して再帰呼び出しを行い、親の設定を変更しようとする仕組みになっています。

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

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

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

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

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

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

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

#!/bin/sh

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

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

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