コグノスケ

ROCKPro64のHDMIから音を出すKconfig設定

目次: ROCK64/ROCKPro64

今更ですが、メモしていなかった気がするので、ROCKPro64（Rockchip RK3399搭載）でHDMI Audioを有効にする方法です。

方法は簡単でLinuxのCONFIG_DRM_DW_HDMI_I2S_AUDIOと、CONFIG_GPIO_SYSCONを有効にすれば良いです。8/7時点のlinux-nextのツリーでは、make defconfigすると、GPIO_SYSCONはnで、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。

  Device Drivers  --->
    -*- GPIO Support  --->
      Memory mapped GPIO drivers  --->
        [*] GPIO based on SYSCON
    Graphics support  --->
      Display Interface Bridges  --->
        [*] Synopsys Designware I2S Audio interface
    [*] Sound card support  --->
      [*]   Advanced Linux Sound Architecture  --->
        [*]   ALSA for SoC audio support  --->
          CODEC drivers  --->
            [*] Everest Semi ES8316 CODEC

CONFIG_SND_SOC_ES8316はアナログオーディオを使いたい場合に有効にしてください。

ROCKPro64と音声ビットストリームパススルー出力

目次: ROCK64/ROCKPro64

去年だったか、ROCKPro64のHDMI音声出力を有効化するパッチをlinux-nextに送ろうとしたことがあります。当時のレビューコメントでSPDIFとHDMIの音声ビットストリームパススルー出力（※1）は動くか？と聞かれたものの、テスト環境がなかったため、わからないまま挫折してしまいました。

今回、再チャレンジにあたり、テスト用にSPDIFとHDMIの音声ビットストリームをデコードできる機械を探しました。これがどうして、お手頃価格の良い商品が見当たらないです。

AmazonではSPDIFのみ対応の商品がありました。メーカーが怪しい、色んなバージョンが色んな店から売られている、そもそも動くの？？など不安は募りますが、ダメ元で購入しました。

大手メーカー製を探すと、ホームシアター用ヘッドホンシステム3〜4万円、もしくはAVプリアンプ10万円over！のような大げさな商品しかありません。

音声ビットストリームパススルー出力が、いかに高コスト＆需要がないか良くわかりました。普通の人は音声信号がLPCMかパススルーかなど細かいことは気にしませんから、当然の成り行きでしょうね。

（※1）音声信号としてLPCMではなく、Dolby Digital（AC-3）やDTSをデコードせず圧縮音声のままSPDIFやHDMIに出力する方式のことです。デコードは受信機器側で行います。

SPDIF用のテスト機材

SPDIFパススルーのテスト用に、中国製と思われる謎の機械（型番なし、筐体にはHD AUDIO RUSHと書いてある）を購入しました。Amazonで4,000円くらいです。安い！事前の不安をよそに音は正常に鳴っています。素晴らしいです。

しかし本体にコーデックのインジケータがなく、LPCMか音声ビットストリームか全く判別がつきません。テスト用の機材としてはイマイチでした。10分に1回くらいSPDIF信号のPLLロックが外れた（？）と思われる、数秒レベルの音切れが発生します。ROCKPro64の出す信号が悪いのか、HD AUDIO RUSHが悪いのか、切り分けできず真因は不明です。

SPDIFだけだとLPCM 96kHz 16bit 2ch（3.072Mbps）のような、SPDIF（Max 1.5Mbps）の帯域を超える音声信号はテストできません。無理やり流すと酔っ払いが演奏してるみたいな変な音になります。HD AUDIO RUSHくん以外にHDMI用のテスト機材が必要です。

HDMI用のテスト機材

HDMIのテストならテレビ（Panasonic TH-L37DT3）で確認できるだろ、と思っていたら、HDMI音声入力はLPCM 2chのみの対応でした。LPCMは2ch以外にも5.1ch出力（※2）がありますがテストできません。ダメだこれ。

覚悟を決めてサラウンドヘッドフォンシステムSONY MDR-HW700DSを注文しました。37,000円くらいします、高い！まだ家に届いていませんが、来週辺りかな、人生初のSPDIF/HDMI音声ビットストリームパススルー対応機器が手に入ります。

（※2）身近な例でいうとNintendo Switchのサラウンドモードが、LPCM 5.1ch出力を使います。試しにSwitchをサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。

またバッテリー死す

目次: 車

コロナ騒ぎが始まって、遠出することもなくなり、かれこれ4か月以上？車に乗らず放置していました。

骨折した奥さんを整形外科におくるため、JAFさんに車のバッテリー上がりを直してもらったんですけど、バッテリー電圧がなんと1Vしかありません。えー？？

車のバッテリー（鉛蓄電池）の端子電圧は12V程度が正常ですから、10Vの見間違い？と思いましたけど、何回見ても1.0Vでした。乾電池だってもうちょっと電圧あるでしょう。

今まで何度となくバッテリー上がりさせ、バッテリー破壊もこれで4度目（2007年、2013年、2016年、2020年）ですけど、1Vまで下がったのは初めてです。

割とお高いGS YUASA 80D23L大容量バッテリーを使っていたのですが、いかなるバッテリーであろうと、このレベルの過放電には無力ですね。エンジン掛かった後も全く充電される気配がありませんでした。

近所のイエローハットまでバッテリー交換しに行く道中が一番嫌でした。

• 4か月ぶりの運転
• バッテリー電圧が12V〜11Vくらいでグラグラ
• アイドリングが不調で止まりそう（バッテリー上がりでエンジンの調整データが消えた？）
• エンストしたら二度と掛からない

こんな状態で、産業道路〜環七〜第二京浜と走るのはかなり怖いです。無事に辿り着けて良かったけども。

また懲りずにPanasonic 85D23Lの大容量バッテリーに交換しておきました。3万円くらいしました。たっけぇ……。今年は車検もあるし、全然乗ってない割に金ばっかり掛かってます。不思議ですね。

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

ARM SBCリスト2

目次: ROCK64/ROCKPro64

最近はたくさんのARMのシングルボードコンピュータ（SBC）が市販されています。2019年以降のボードも追加してみました。値段は変動するので参考です。

Amlogic S905X3

ボードHardkernel ODROID-C4, A55/2.0GHz x 4, 4GB DDR4-2666, 12nm, $50, 2020/04

Amlogic A311D (S922X + NPU)

ボードKhadas KVIM3-P-002, A73/2.2GHz x 4, A53/1.8GHz x 2, 4GB LPDDR4-????, 12nm, $160, 2019/06

Amlogic S912

ボードKhadas KVIM2-M-002, A53/1.5GHz x 8, 3GB DDR4-????, 28nm, $170, 2017/08

Broadcom BCM2711

ボードRaspberry Pi 4 Model B, A72/1.5GHz x 4, 8GB LPDDR4, 28nm, $75, 2019/11

HiSilicon Kirin 970

ボード96boards HiKey 970, A73/2.36GHz x 4, A53/1.8GHz x 4, 6GB LPDDR4-1866, 10nm, $299, 2018/??

MediaTek Helio X20

ボード96boards MediaTek X20, A72/2.1GHz x 2, A53/1.85GHz x 4, A53/1.4GHz x 4, 2GB LPDDR3-????, 20nm, $199, 2017/??

NVIDIA Xavier AGX

ボードNVIDIA Jetson Xavier AGX, Carmel/2.26GHz x 8, 8MB L2, 4MB L3, 32GB LPDDR4-2133, 12nm, $700, 2020/??

NVIDIA Xavier NX

ボードNVIDIA Jetson Xavier NX, Carmel/1.4GHz x 6, 6MB L2, 4MB L3, 8GB LPDDR4-1600, 12nm, $400, 2020/??

Rockchip RK3399

ボードFriendlyARM NanoPC-T4, A72/2GHz x 2, A53/1.5GHz x 4, 4GB LPDDR3-1866, 28nm, $109, 2018/??

Samsung S5P6818

ボードFriendlyARM NanoPC-T3 Plus, A53/1.4GHz x 8, 2GB DDR3, $75, 2018/??

古い世代のSoCを採用したボード達です。

AllWinner H6

ボードPINE64 PINE H64, A53 x 4, 2GB LPDDR3-1600, 28nm, $36

AllWinner H5

ボードFriendlyARM NanoPi NEO2, A53/1.5GHz x 4, 1GB DDR3, 40nm, $20

Amlogic S905

ボードHardkernel ODROID-C2, A53/1.5GHz x 4, 2GB DDR3-1866? (912MHz), 28nm, $39

Broadcom BCM2837B

ボードRaspberry Pi 3 Model B, A53/1.2GHz x 4, 1GB LPDDR2, 28nm, $35

HiSilicon Kirin 960

ボードHiKey 960, A72 x 4, A53 x 4, 3GB LPDDR4, 16nm FinFET, $239

NVIDIA Tegra X2 (Parker)

ボードJetson TX2, Denver/2GHz x 2, A57/2GHz x 4, 8GB LPDDR4, 16nm, $600

NVIDIA Tegra X1

ボードJetson TX1, A57/1.9GHz x 4, 4GB LPDDR4, 20nm, $500

Rockchip RK3328

ボードPINE64 ROCK64, A53/1.4GHz x 4, 4GB LPDDR3-1866, 28nm, $24.95 (1GB) $34.95 (2GB) $44.95 (4GB)

以前（2019年5月15日の日記参照）載せた情報も含んでいます。

GCCを調べる - その18 - ベクトルNot演算の定義

目次: GCC

前回（2020年7月19日の日記参照）は四則演算と論理演算（and, or, xor）を定義しました。今回はNot演算を定義します。他の論理演算と異なり、Not演算は2オペランドしか取りませんから、define_insnを別に書く必要があります。

;; gcc/config/riscv/riscv.md

(define_insn "one_cmpl<mode>2"
  [(set (match_operand:ANYV           0 "register_operand" "=v")
	(not:ANYV (match_operand:ANYV 1 "register_operand" "%v")))]
  "TARGET_VECTOR"
  "vnot.vt%0,%1"
  [(set_attr "type" "logical")
   (set_attr "vecmode" "<MODE>")])

前回同様に、ベクトル拡張記法（Vector Extensions (Using the GNU Compiler Collection (GCC))）を使ってビット毎Notを使うプログラムを書きます。

typedef int __v64si __attribute__((__vector_size__(256)));

void test()
{
	__v64si v10, v11;
	static int b[1024 * 1024] = {0};

	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v10) : "A"(b[10]));
	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v11) : "A"(b[20]));

	v10 = ~v11;

	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[40]) : "v"(v10));
}

コンパイルするとエラーが発生します。何かお気に召さないようです。

$ riscv32-unknown-elf-gcc b.c -nostdlib -Og -march=rv32gcv -mabi=ilp32f

during RTL pass: reload
dump file: b.c.282r.reload
b.c: In function 'test':
b.c:14:1: internal compiler error: in setup_operand_alternative, at lra.c:814
   14 | }
      | ^
0xea5c36 setup_operand_alternative
        gcc/gcc/lra.c:814
0xea70c2 lra_set_insn_recog_data(rtx_insn*)
        gcc/gcc/lra.c:1073
0xea30f9 lra_get_insn_recog_data
        gcc/gcc/lra-int.h:488
0xeab0b9 remove_scratches_1
        gcc/gcc/lra.c:2058
0xeab4c4 remove_scratches
        gcc/gcc/lra.c:2094
0xeac629 lra(_IO_FILE*)
        gcc/gcc/lra.c:2396
0xe1a41f do_reload
        gcc/gcc/ira.c:5523
0xe1ae5c execute
        gcc/gcc/ira.c:5709

コードを見ると最後のオペランドに % を付けるべきではないそうです。確かにdefine_insnを見ると % が要らないのに付いています。

// gcc/lra.c

/* Setup info about operands in alternatives of LRA DATA of insn.  */
static void
setup_operand_alternative (lra_insn_recog_data_t data,
			   const operand_alternative *op_alt)
{
  int i, j, nop, nalt;
  int icode = data->icode;
  struct lra_static_insn_data *static_data = data->insn_static_data;

  static_data->commutative = -1;
  nop = static_data->n_operands;
  nalt = static_data->n_alternatives;
  static_data->operand_alternative = op_alt;
  for (i = 0; i < nop; i++)
    {
      static_data->operand[i].early_clobber_alts = 0;
      static_data->operand[i].is_address = false;
      if (static_data->operand[i].constraint[0] == '%')    //★★% が付いていればcommutative
	{
	  /* We currently only support one commutative pair of operands.  */
	  if (static_data->commutative < 0)
	    static_data->commutative = i;
	  else
	    lra_assert (icode < 0); /* Asm  */
	  /* The last operand should not be marked commutative.  */
	  lra_assert (i != nop - 1);    //★★このアサートに引っかかる
	}
    }

...

素直に応じるとエラーは消えます。

(define_insn "one_cmpl<mode>2"
  [(set (match_operand:ANYV           0 "register_operand" "=v")
	(not:ANYV (match_operand:ANYV 1 "register_operand" " v")))]    ★★% を消す
  "TARGET_VECTOR"
  "vnot.vt%0,%1"
  [(set_attr "type" "logical")
   (set_attr "vecmode" "<MODE>")])

四則演算、論理演算（3オペランド系）と、Not演算（2オペランド系）が揃いました。残りの頻出する演算はビットシフト系かな？

最後のオペランドをcommutativeにできない理由

最後のオペランドをcommutativeにしてはいけない理由は、GCCのConstraintsの説明を見るとわかります。

`%' Declares the instruction to be commutative for this operand and the following operand. This means that the compiler may interchange the two operands if that is the cheapest way to make all operands fit the constraints. GCC can only handle one commutative pair in an asm; if you use more, the compiler may fail. Note that you need not use the modifier if the two alternatives are strictly identical; this would only waste time in the reload pass. The modifier is not operational after register allocation, so the result of define_peephole2 and define_splits performed after reload cannot rely on `%' to make the intended insn match.

難しいことを言っていますが、commutativeは % を付けたオペランドと「次」のオペランドが可換だと宣言することだそうです。最後のオペランドには「次」のオペランドがありませんから、% を付けてはいけません。なるほど。

RISC-Vの場合は論理演算のdefine_insnの2番目のオペランドに % が使われています。

;; gcc/config/riscv/riscv.md

;; This code iterator allows the three bitwise instructions to be generated
;; from the same template.
(define_code_iterator any_bitwise [and ior xor])

...

(define_insn "<optab><mode>3"
  [(set (match_operand:X                0 "register_operand" "=r,r")
	(any_bitwise:X (match_operand:X 1 "register_operand" "%r,r")
		       (match_operand:X 2 "arith_operand"    " r,I")))]
  ""
  "<insn>%i2t%0,%1,%2"
  [(set_attr "type" "logical")
   (set_attr "mode" "<MODE>")])

例えばand r1, r2, r3とand r1, r3, r2は結果が同じですから、2番目と3番目のオペランドは入れ替え可能です。3つの論理演算（any_bitwiseはand, or, xorのこと）はいずれも同様に入れ替え可能ですので、このような定義になっています。