コグノスケ

Zephyr OS で遊ぼう その 11 - Zephyr 2.3.0 に対応する

目次: Zephyr を調べる - まとめリンク

Zephyr 2.3.0 にバージョンアップしたところ、また Hoge ボードのビルドが通らなくなりました。

一点目は UART ドライバの CMakeLists です。zephyr_library_sources_if_kconfig() がなくなったため、書き方が変わりました。

commit 244f826e3c7333bb92fb53a65c50ee5cbd8a2ea0
Author: Carles Cufi <carles.cufi@nordicsemi.no>
Date:   Fri Jul 31 13:52:40 2020 +0200

    cmake: remove _if_kconfig() functions

    This set of functions seem to be there just because of historical
    reasons, stemming from Kbuild. They are non-obvious and prone to errors,
    so remove them in favor of the `_ifdef()` ones with an explicit
    `CONFIG_` condition.

    Script used:

    git grep -l _if_kconfig | xargs sed -E -i
    "s/_if_kconfig\(\s*(\w*)/_ifdef(CONFIG_\U\1\E \1/g"

    Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>

# drivers/serial/CMakeLists.txt

zephyr_library_sources_if_kconfig(uart_spike.c)

下記に変更

zephyr_library_sources_ifdef(CONFIG_UART_SPIKE uart_spike.c)

二点目は整数型です。Zephyr は u8_t, u16_t, u32_t のような独自の整数型を持っていましたが、C99 の型に置き換えられました。drivers/serial/uart_spike.c の実装を書き換える必要があります。

commit a1b77fd589dbe7284c17b029f251426a724abd47
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Wed May 27 11:26:57 2020 -0500

    zephyr: replace zephyr integer types with C99 types

            git grep -l 'u\(8\|16\|32\|64\)_t' | \
                    xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g"
            git grep -l 's\(8\|16\|32\|64\)_t' | \
                    xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g"

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

三点目は DT_INST_0_SPIKE_UART_SPIKE_LABEL マクロです。こいつは元々、訳のわからない名前で直しようがないので、SiFive のシリアルドライバの履歴を参考に直します。履歴を見ると 2回ほど変わっています。

マクロ名のルールは DT_INST_<INSTANCE>_<COMPAT>_<PROP> だったみたいです。今初めて知りました。やっぱりこの書き方は意味不明と思ったのか、DT_INST_PROP(0, label) という形式になりました。さらに今は DT_INST_LABEL(0) という形式に落ち着いています。

★★DT_INST_PROP(0, label) になったコミット

commit 8f84520130a346957ac2e2bdff1d6a51bca13af0
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Tue Mar 10 17:24:43 2020 -0500

    drivers: serial: uart_sifive: convert to new DT API

    Use the new devicetree.h API instead of the legacy macros.

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>


★★DT_INST_LABEL(0) になったコミット

commit 74d459fb66b10a5a0614a582fb0375d8b4a78c9e
Author: Kumar Gala <kumar.gala@linaro.org>
Date:   Thu Apr 2 13:13:47 2020 -0500

    drivers: serial: sifive: use DT_INST_LABEL macro

    Replace a few cases that should have been DT_INST_LABEL instead.

    Signed-off-by: Kumar Gala <kumar.gala@linaro.org>

このマクロの罠はそれだけに留まらず、ソースコードの先頭に下記マクロを定義する必要があります。依然として訳がわかりません。Zephyr は DviceTree 周りの仕様が不安定です。

// zephyr/drivers/serial/uart_spike.c

#define DT_DRV_COMPAT spike_uart_spike

最後はリンカーです。これは元々のコードのコンフィグが間違っていたことに起因します。ROM 領域がないのに CONFIG_XIP が有効になっていました。

$ ninja

...

x-tools/riscv64-zephyr-elf/lib/gcc/riscv64-zephyr-elf/8.3.0/../../../../riscv64-zephyr-elf/bin/ld: invalid origin for memory region ROM
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

エラーメッセージからは何が原因か読み取れないですね。こういうときはビルドディレクトリのリンカースクリプト（zephyr/linker.cmd）をうまく行く場合と、うまく行かない場合で見比べます。

/* zephyr/build/zephyr/linker.cmd */

 OUTPUT_ARCH("riscv")
 OUTPUT_FORMAT("elf32-littleriscv")
MEMORY
{
    ROM (rx) : ORIGIN = 541065216, LENGTH = 12582912
    RAM (rwx) : ORIGIN = 0x80000000, LENGTH = ((16) << 10)
    IDT_LIST (wx) : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

/* zephyr/build/zephyr/linker.cmd */

 OUTPUT_ARCH("riscv")
 OUTPUT_FORMAT("elf32-littleriscv")
MEMORY
{
    ROM (rx) : ORIGIN = ROM_BASE, LENGTH = ROM_SIZE    /* ★★ここがおかしい★★ */
    RAM (rwx) : ORIGIN = 0x80000000, LENGTH = ((32) << 10)
    IDT_LIST (wx) : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

このスクリプトは下記のファイルから生成されているようです。Hoge ボードは ROM 領域を使う前提ではないので、領域そのものが要りません。ROM 領域を葬るには CONFIG_XIP を n にすれば良さそうです。ファイルは boards/riscv/hoge/hoge_defconfig です。

// include/arch/riscv/common/linker.ld

MEMORY
{
#ifdef CONFIG_XIP
#if DT_NODE_HAS_COMPAT_STATUS(DT_CHOSEN(zephyr_flash), soc_nv_flash, okay)
#define ROM_BASE DT_REG_ADDR(DT_CHOSEN(zephyr_flash))
#define ROM_SIZE DT_REG_SIZE(DT_CHOSEN(zephyr_flash))
#elif DT_NODE_HAS_COMPAT_STATUS(DT_CHOSEN(zephyr_flash), jedec_spi_nor, okay)
/* For jedec,spi-nor we expect the spi controller to memory map the flash
 * and for that mapping to be the second register property of the spi
 * controller.
 */
#define SPI_CTRL DT_PARENT(DT_CHOSEN(zephyr_flash))
#define ROM_BASE DT_REG_ADDR_BY_IDX(SPI_CTRL, 1)
#define ROM_SIZE DT_REG_SIZE_BY_IDX(SPI_CTRL, 1)
#endif
    ROM (rx)  : ORIGIN = ROM_BASE, LENGTH = ROM_SIZE    /* ★★ CONFIG_XIP が無効ならこの行ごと消える★★ */
#endif
    RAM (rwx) : ORIGIN = CONFIG_SRAM_BASE_ADDRESS, LENGTH = KB(CONFIG_SRAM_SIZE)
    /* Used by and documented in include/linker/intlist.ld */
    IDT_LIST  (wx)      : ORIGIN = 0xFFFFF7FF, LENGTH = 2K
}

以上の修正を入れて動かします。

$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build zephyr-v2.3.0-2349-g0769bb760b2a  ***
Hello World! hoge

やっと動きました。良かった良かった。

Zephyr OS で遊ぼう その 10 - QEMU の変化に対応する

目次: Zephyr を調べる - まとめリンク

最近の RISC-V 向け QEMU で spike, virt を起動すると、下記のようなエラーで怒られてしまいます。

$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf

qemu-system-riscv32: Unable to load the RISC-V firmware "opensbi-riscv32-spike-fw_jump.elf"

このエラーの原因は QEMU RISC-V 向けの仕様変更によるものです。machine が spike, virt のときに、自由に BIOS を選べるように変わりました。ですが Zephyr を起動する際には、特に BIOS は必要ないため、none を指定すれば OK です。

$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build v2.2.0-rc1-123-gcaca3f60b012  ***
Hello World! hoge

Zephyr だけでなく QEMU も日々進化しているのですね。

駐車場での事故

先週、突然知らない番号から電話が掛かってきました。何だか焦った様子でした。要約すると「アパートの駐車場で隣に駐車している者です、駐車しようとして、あなたの車にぶつけてしまいました」とのことでした。車の様子を確認したところ、見事にバンパーの右前が取れていました。ああー……。

レガシィのバンパーが取れた

後日、保険屋さんと修理屋さん（スーパーオートバックス）から電話があり、車を引き取りに来る日時等を決めました。そして今日、レガシィさんはフロントバンパー修理のため旅立っていきました。

修理屋さん曰く「右ライトも Assy 交換で新品になるだろう」とのこと。新品交換後の右ライトに対し、古ぼけた左ライトの明るさがアンバランスになるのはうまくないので、左ライトの研磨もお願いしました。残念ながら左ライトの研磨は保険が効かず自費になりそうですが、曇っていたライトが明るくなるから良しとしましょう。

代車

代車はホンダのフィットでした。

代車のフィット、外観

代車のフィット、インパネ

総じて良い車だと思います。レガシィとの違いとしては、

• フロントがかなり斜めってる、真上の日差しがダッシュボードを照らし前が見えない
• アクセルがフニャフニャ、踏んでもあまり速度が変わらない（遊びが大きい？？）
• ブレーキがある点から急激に効いて怖い

昔のフィットに乗ったときは、アクセルオフ時のエンブレが急で、車酔いしたので、正直好きな車ではなかったのですが、今のフィットは素敵な車です。新しい車って確実に良くなってますね。

ADAS（前車の車間検知、車線逸脱の警告）も搭載されていて面白いです。たまに誤検知？するのか、何もないところで突然ピー！と警告音が鳴ったり、車線逸脱の警告とともにハンドルがンゴゴー！って言い出すのはご愛敬です。

ROCK64 を Raspberry Pi 3 のケースに無理やり格納

目次: ROCK64/ROCKPro64 - まとめリンク

先日 KADHAS VIM2, VIM3 を購入したため、ARM ボードがさらに増え置き場がなくなりました。既存のボードをコンパクトに収納できないかと画策し、目を付けたのが ROCK64 です。現在 ROCK64 は純正ケースに入れて使っていますが、ギリシャの神殿を思わせる立派な柱と、無駄にでかいアクリル板のせいで、すっっごい邪魔です。

ROCK64 の純正ケース

ROCK64 は Raspberry Pi 3 とほぼ同じ大きさですから、Raspberry Pi 3 のケースを流用できるはずです。

ケース選び

改造のベースになるケースは、TinkerBoard や Raspberry Pi 3 の格納で活躍している Physical Computing Lab の 3ple Decker Raspberry Pi ケース（公式サイトへのリンク）です。

Rasberry Pi 3 は電源が USB micro B ですが、ROCK64 は AC アダプタなので、全く形が合いません。アクリルケースの穴を削って広げる必要があります。もう一か所、ROCK64 の個体差か（or 単に設計の問題か？）ヘッドホンジャックがケースとズレていて、プラグが刺さらないため、これも直さないといけません。

電源コネクタ周辺（削る予定の部分を黒く塗っている）

ヘッドホンジャック周辺（削る予定の部分を黒く塗っている）

削り方はリューターにプラスチック用のビットを付けてゴリゴリ削るだけです。厚さも面積も大したことないので、力業でどうにでもなると思います。アクリルを削ると変なにおいがしますね。焦げてるのかな……？

加工後のケース

ケースを削り終わりました。ROCK64 の端子がちゃんと外から見えています。

細かい不都合

元より ROCK64 用のケースではないので、様々な不都合が発生します。

• ROCK64 の 22pin のピンヘッダ（Pi P5+ Bus）がケースで隠れて配線できない
• ROCK64 の PWR, RESET ボタンが押せない
• ボードの固定が甘くなる

Pi P5+ Bus が使用不能になる点は諦めました。Rasberry Pi 3 にはないピンヘッダなので致し方無しです。このピンヘッダから引き出していた S/PDIF が利用不可能になりました。さよなら S/PDIF さん。

PWR, RESET ボタンはケースを開ければ押せますが、面倒です。今後は PWR ボタンに頼らない運用を考えるべきでしょう。

ボードが固定できない問題はどうにもなりませんでした。microSD の上部を抑えるケース側のツメがうまくハマりません。

ボードを固定するケース側のツメ

もう少しきちんと調べてみると、ROCK64 は Rasberry Pi 3 より microSD スロットに厚みがあるせいで、microSD の上部を抑えるケース側のツメがうまくハマらないようです。

Raspberry Pi 3 の場合

ROCK64 の場合

スロットの厚さはどうしようもないので、泣く泣くケース側のツメを折りました。

ツメがないので、microSD カードがケースに引っ掛かってギリギリケースに固定されている状態です。ROCK64 の 40pin のピンヘッダ（Pi-2 Bus）にジャンパケーブルを抜き差しすると、microSD にかなり力が掛かります。これは良くないですね……。

Pi-2 Bus へのケーブル抜き差しは結構固いため、そのうち microSD スロットが変形するか、microSD が折れて壊れると思います。幸いなことに、今は頻繁にピンヘッダのケーブル抜き差しはしませんから、しばらくこの状態でも使えるでしょう。

サーバ向けプロセッサでは最強の Intel

Twitter で Cavium Thunder X3 はサーバ向け汎用 ARM SoC ではなくなるかもしれない、という話を見かけました。Cavium（今は Marvell に買収されました）は独自 ARM CPU コアを作って頑張ってたメーカーです。

ARM 自体はまだまだめげることなく、サーバ向けに売りたい（Arm のサーバ向け戦略十年の計は実を結ぶか、新プロセッサ「Neoverse」 - MONOist）ようですが、肝心の ARM 系 SoC メーカーやサーバベンダーが ARM 系サーバで成功している様子がないです。

以前 Qualcomm Centriq も鳴り物入りでサーバ向け ARM SoC に参入しましたが、2018年にあっさり撤退（Arm SoC の開発部門を秘かに閉鎖していた Qualcomm - EE Times Japan）しています。モバイルの王者 Qualcomm をもってしても困難な道のようです。

サーバ向けプロセッサは Intel が 9割取っているらしいので、崩すのはなかなか容易ではありませんね……。

ARM メニーコア系 SoC

サーバ向けとして発表されている ARM メニーコア系 SoC を列挙してみました。年代はチップがローンチされたおおよその時期です。間違ってたらごめんなさい。

• Ampere Altra（2020, ARM Neoverse N1, 80コア, 7nm）
• Amazon Graviton 2（2020, ARM Neoverse N1, 64コア, 7nm）
• Huawei Kunpeng 920（2019, Hisilicon TSV110, 64コア, 7nm）
• Cavium Thunder X2（2018, Broadcom Vulkan, 32コア, 14nm）
• Amazon Graviton（2018, ARM Cortex-A72, 16コア, 16nm）
• Qualcomm Centriq（2017, Qualcomm Folker, 48コア, 10nm）
• Socionext SC2A11（2017, Cortex-A53, 24コア）
• Cavium Thunder X1（2014, Cavium 独自, 48コア）

こんな感じですかね？SC2A11 はホームページでサーバ向けと謳っていたので、リストに入れてます。でも CA53 コアなので、性能的には Thunder X2 辺りと並べるのはちょっと厳しい……かな？

ALSA ループバックデバイス

デスクトップ PC にはスピーカーを繋いでいませんが、たまに音声再生を確認したいことがあります。スピーカーを繋ぎ変えても良いですが、ALSA のループバックデバイスを使うと簡単に音声を転送したり、ファイルに記録したりできます。

ループバックデバイスとは再生した音声がそのまま戻ってきて（ループバック）録音できるデバイスのことです。ヘッドフォンの出力端子を、マイクロフォンの入力端子に繋いでループさせた状態を想像してもらうとわかりやすいと思います。

ALSA のループバックデバイス（aloop）は、ALSA の標準的な機能です。普通の環境だとロードされていないはずなので、modprobe でロードします。

# modprobe snd-aloop

$ cat /proc/asound/pcm

00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
00-08: HDMI 2 : HDMI 2 : playback 1
00-09: HDMI 3 : HDMI 3 : playback 1
00-10: HDMI 4 : HDMI 4 : playback 1
01-00: ALC1220 Analog : ALC1220 Analog : playback 1 : capture 1
01-01: ALC1220 Digital : ALC1220 Digital : playback 1
01-02: ALC1220 Alt Analog : ALC1220 Alt Analog : capture 1
02-00: Loopback PCM : Loopback PCM : playback 8 : capture 8    ★このデバイス hw:2 を使用する
02-01: Loopback PCM : Loopback PCM : playback 8 : capture 8

ロードし終わると PCM デバイスが 1つ増えます。上記の場合は 02-xx（02-00 と 02-01）が増えています。

ALSA ループバックデバイスの使い方

ループバックデバイスはサブデバイス 0 が再生用、サブデバイス 1 が録音用となっています。先ほどの例でいうと、再生時は hw:2,0 を使い、録音時は hw:2,1 を使います。

$ aplay test.wav -D hw:2,0

Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

#### ファイルに記録する場合

$ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 test2.wav

Recording WAVE 'test2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo


#### ネットワーク経由で送る場合

$ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 | nc 192.168.1.10 5555

Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

私の家のスピーカーは、今のところ ROCK64 に繋がっています。ROCK64 にネットワーク経由で送って、下記のように受け取れば「ほぼ」リアルタイムでデスクトップ PC の音声が確認できます。

$ nc -l 5555 | aplay -D hw:0

Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

受け取る方は先頭の WAV ヘッダでサンプリング周波数やチャネル数を知ることができるため、-r や -c を指定する必要はありません。指定しても構いませんが無視されるはずです。

「ほぼ」リアルタイムと書いた理由は、上記の方法だと人間が余裕でわかるくらいの遅延が発生してしまうからです。ちゃんと測っていませんが、0.5秒くらい遅れてるかも？これでも簡易的な音声確認としては十分ですし、気にしなくでも良いでしょう。