コグノスケ


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

link もっと前
2019年1月13日 >>> 2018年12月31日
link もっと後

2019年1月13日

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

目次: ROCK64/ROCKPro64

完全に自分のためのメモですが、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というファイル名だと元々存在するカーネルと被っているので、リネームしています。

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

コメント一覧

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



2019年1月12日

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版です。

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

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

編集者:すずき(2023/09/24 12:01)

コメント一覧

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



2019年1月11日

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

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/01/12 23:39)

コメント一覧

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



2019年1月10日

スマートプラグ

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/01/12 23:22)

コメント一覧

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



2019年1月5日

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

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

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

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

コメント一覧

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



2019年1月4日

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/01/06 20:12)

コメント一覧

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



link もっと前
2019年1月13日 >>> 2018年12月31日
link もっと後

管理用メニュー

link 記事を新規作成

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

最近のコメント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月3日
    すずき (03/19 11:07)
    「[解像度の設定を保存する] 目次: LinuxRaspberry Pi 3 Model B (以降RasPi 3B)のHDMI...」
  • link 24年3月14日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信] 目次: ArduinoM...」
  • link 24年3月8日
    すずき (03/16 23:03)
    「[JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙] 目次: A...」
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 www.katsuster.net
RDFファイル RSS 1.0

最終更新: 03/19 11:07