コグノスケ

Zephyr OSで遊ぼう その22 - SMP対応CPUコア数1、HART 0以外で動かす、動作確認環境

目次: Zephyr

前回はCONFIG_SMPのビルドエラーと実行時エラーに対応しました。以前書いたとおり、SMP対応は下記の手順で進めていますので、再掲します。

• SMPの前提条件、新しいコンテキストスイッチ方式に対応する（CONFIG_USE_SWITCH, CONFIG_USE_SWITCH_SUPPORTED）
• SMPに対応する（CONFIG_SMP）、ただしCPUコア数は1
• （今ここ）先頭ではないコア（mhartid != 0）で動作させる、ただしCPUコア数は1
• CPUコア数を1以上にする（CONFIG_SMP）

前回までで2番目の項目が終わったところです。今回はコア数を増やして先頭以外のコアで実行します。

動作確認の環境

Zephyrを書き換える前に、変更した効果が確認できる環境を作りましょう。サンプルのsynchronizationを少し改造してHART IDを表示します。

// zephyr/samples/synchronization/src/main.c

void helloLoop(const char *my_name,
	       struct k_sem *my_sem, struct k_sem *other_sem)
{
	const char *tname;

	while (1) {
		int id = z_riscv_hart_id();    //★HART IDを取得★

		/* take my semaphore */
		k_sem_take(my_sem, K_FOREVER);

		/* say "hello" */
		tname = k_thread_name_get(k_current_get());
		if (tname != NULL && tname[0] != '\0') {
			printk("%d: %s: Hello World from %s!\n",
				id, tname, CONFIG_BOARD);    //★HART IDを一緒に表示する★
		} else {
			printk("%d: %s: Hello World from %s!\n",
				id, my_name, CONFIG_BOARD);    //★HART IDを一緒に表示する★
		}

今回は変更してもしなくても構わないですが、カーネルコンフィグを変えるとk_thread_name_get() でスレッド名が取得できるようになります。スレッドを多数作成したときに便利です。

$ ninja menuconfig

General Kernel Options  --->
  Kernel Debugging and Metrics  --->
    [*] Thread name [EXPERIMENTAL]

動作させると下記のような表示になるはずです。

$ mkdir build
$ cd build
$ cmake -G Ninja -DBOARD=qemu_rv32_virt ../samples/synchronization/

...

$ ninja

...

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

** Booting Zephyr OS build zephyr-v2.4.0-546-g720718653f92  ***
0: thread_a: Hello World from QEMU RV32 virt board!
0: thread_b: Hello World from QEMU RV32 virt board!
0: thread_a: Hello World from QEMU RV32 virt board!
0: thread_b: Hello World from QEMU RV32 virt board!

...

HART ID = 0で実行されていることがわかります。

続きは次回です。

Zephyr OSで遊ぼう その23 - SMP対応CPUコア数1、HART 0以外で動かす

目次: Zephyr

前回はHART 0以外で動かす際に、動作確認が必要なので準備を行いました。今回はHART 0以外で動かします。

実行するHARTを一時的にずらす

一番簡単なやり方は、ブート時の判定条件を変えることだと思います。通常はHART IDが0だったら起動しますが、0じゃないHARTのときに起動するように変更します。この変更は最終的には不要なので、あとで元に戻すのを忘れないようにしてください。

// zephyr/arch/riscv/core/reset.S

...

SECTION_FUNC(TEXT, __initialize)
	/*
	 * This will boot master core, just halt other cores.
	 * Note: need to be updated for complete SMP support
	 */
	csrr a0, mhartid
	addi a0, a0, -3    //★HART ID - 3 = 0なら実行する、つまりHART ID 3で実行する★
	beqz a0, boot_master_core

...

ZephyrのCPUコア数はmenuconfigから変更可能です。なぜかは知りませんが、最大4コアらしいです。

$ ninja menuconfig

General Kernel Options  --->
  SMP Options  --->
    (4) Number of CPUs/cores

実行してみます。QEMUの -smp cpus=1オプションをcpus=4に変更して4コアで実行します。

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

** Booting Zephyr OS build zephyr-v2.4.0-546-g720718653f92  ***
3: thread_a: Hello World from QEMU RV32 virt board!

HART IDは変わりました。しかしスレッドAからスレッドBに切り替わらず、ハングアップしてしまいます。原因はタイマー割り込みがHART ID 0以外に入らないからです。Zephyrはタイマー割り込みによってカーネルの内部時間（Tick）を更新する他、割り込みを契機にコンテキストスイッチを行っています。

タイマーのSMP対応

Zephyrでは通常の定期的なタイマー割り込みと、Tickless Timerという不定期なタイマー割り込みの仕組みがあります。通常のタイマーの場合、一定時間ごとにタイマー割り込みを発生（例えば10msごとなど）させ、1Tickずつ時間を進めます。実装は単純ですが、用もなくタイマー割り込みが発生するため、消費電力や処理性能に悪影響を及ぼします。

Tickless Timerの場合、各CPUが「最後に割り込みが発生した時刻」を記録しておいて、タイマー、タイマー以外の割り込みが発生した際に、前回の割り込みからどれだけ時間が経過したか、つまり、何Tick経過したか？を計算して、一気に時間を進めます。また「次のタイマー割り込みの設定」は、できるだけ遠く（現在時刻 ＋1 Tick）に設定して、無用なタイマー割り込みが発生しないように工夫されています。

「最後に割り込みが発生した時刻」と「次のタイマー割り込みの設定」はCPUが割り込みを受けたタイミングによって値が変わり、全CPUで共有する値ではありませんから、CPUごとに専用の場所を用意する必要があります。

// zephyr/drivers/timer/riscv_machine_timer.c（変更前）

static struct k_spinlock lock;
static uint64_t last_count;

static void set_mtimecmp(uint64_t time)
{
#ifdef CONFIG_64BIT
	*(volatile uint64_t *)RISCV_MTIMECMP_BASE = time;
#else
	volatile uint32_t *r = (uint32_t *)RISCV_MTIMECMP_BASE;


// zephyr/drivers/timer/riscv_machine_timer.c（変更後）

#define RISCV_MTIMECMP (RISCV_MTIMECMP_BASE + (uintptr_t)z_riscv_hart_id() * 8)    //★「次のタイマー割り込みの設定」★
#define last_count last_count_mp[z_riscv_hart_id()]    //★「最後に割り込みが発生した時刻」★

static struct k_spinlock lock;
static uint64_t last_count_mp[CONFIG_MP_NUM_CPUS];     //★CPUの数だけ配列を確保★

static void set_mtimecmp(uint64_t time)
{
#ifdef CONFIG_64BIT
	*(volatile uint64_t *)RISCV_MTIMECMP = time;
#else
	volatile uint32_t *r = (uint32_t *)RISCV_MTIMECMP;

今回のSMP対応ではMTIMECMPレジスタの幅が64bitであることがわかれば、動作の詳細を知らなくても読み進められると思います。

仕様が気になる場合は、SiFive Core Local Interruptor（CLINT）の仕様を参照ください。CLINTはFE310もしくはFU540のマニュアルに載っています。FE310はシングルコア、FU540はマルチコアです（FE310-G002 Manual, FU540-C000 Manual）。

効果の確認

以上の対応でHART ID 0以外もタイマー割り込みが入るようになり、スケジューラが動作するようになったはずです。

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

** Booting Zephyr OS build zephyr-v2.4.0-546-g720718653f92  ***
3: thread_a: Hello World from QEMU RV32 virt board!
3: thread_b: Hello World from QEMU RV32 virt board!
3: thread_a: Hello World from QEMU RV32 virt board!
3: thread_b: Hello World from QEMU RV32 virt board!

...

HART ID = 3で実行されています。やったね。以降、実行するHARTを一時的にずらす変更は不要なので、元に戻すことを忘れないようにしてください。

Zephyr OSで遊ぼう その24 - SMP対応CPUコア数4、マルチコアブート

目次: Zephyr

CONFIG_SMP有効、1コア、HART ID != 0の動作確認をしました。以前書いたとおり、SMP対応は下記の手順で進めていますので、再掲します。

• SMPの前提条件、新しいコンテキストスイッチ方式に対応する（CONFIG_USE_SWITCH, CONFIG_USE_SWITCH_SUPPORTED）
• SMPに対応する（CONFIG_SMP）、ただしCPUコア数は1
• 先頭ではないコア（mhartid != 0）で動作させる、ただしCPUコア数は1
• （今ここ）CPUコア数を1以上にする（CONFIG_SMP）

現在3番目の項目が終わったところです。いよいよ最後です。SMP対応の本丸である、マルチコアブート、IPIの対応を進めます。

マルチコアブート（マスター側）

前回（2020年10月10日の日記参照）、空関数で実装したarch_start_cpu() を真面目に実装するときが来ました。HART 0をマスターコア、それ以外をスレーブコアとします。マスターコアはarch_start_cpu() を呼びスレーブコアを1つずつ起床します。

// zephyr/kernel/smp.c

void z_smp_init(void)
{
	(void)atomic_clear(&start_flag);

#if defined(CONFIG_SMP) && (CONFIG_MP_NUM_CPUS > 1)
	for (int i = 1; i < CONFIG_MP_NUM_CPUS; i++) {
		arch_start_cpu(i, z_interrupt_stacks[i], CONFIG_ISR_STACK_SIZE,
			       smp_init_top, &start_flag);    //★スレーブコアの数だけarch_start_cpu() を呼ぶ★
	}
#endif

	(void)atomic_set(&start_flag, 1);
}


// zephyr/arch/riscv/core/cpu_smp.c

static volatile struct {
	arch_cpustart_t fn;
	void *arg;
} riscv_cpu_cfg[CONFIG_MP_NUM_CPUS];

volatile uintptr_t riscv_init_flag;
volatile void *riscv_init_sp;

//★マスターコアが実行★
void arch_start_cpu(int cpu_num, k_thread_stack_t *stack, int sz,
		    arch_cpustart_t fn, void *arg)
{
	riscv_cpu_cfg[cpu_num].fn = fn;
	riscv_cpu_cfg[cpu_num].arg = arg;

	/* Signal to slave core with initial sp. */
	riscv_init_sp = Z_THREAD_STACK_BUFFER(stack) + sz;    //★スタックポインタの初期値★
	riscv_init_flag = cpu_num;                            //★スレーブコアを起床★

	/* Wait for slave core */
	while (riscv_init_flag == cpu_num) {    //★スレーブコアが起床するまでビジーウェイト★
		;
	}
}

引数の意味はCPU番号cpu_num、スタックの先頭アドレスstack、スタックのサイズsz、スレーブコアが実行する関数のポインタfn、関数の引数argです。fnとargは後でスレーブコアが使うので配列riscv_cpu_cfg[] に保存します。

スタックポインタとCPU番号はスレーブコアのブート部分で参照するので、グローバル変数に保存します。riscv_init_flag, riscv_init_spは配列にしなくても上書きされる心配はありません。マスターコアはスレーブコアを一度に1コアずつ起こすように実装するので、複数のスレーブコアが同時に同じスタックを使って異常動作する事態は発生し得ないからです。スレーブコア側の実装も見ていただければわかるはず、です。

マルチコアブート（スレーブ側）

リセット後、スレーブコアは一度に全コアが起動します。ブートコードの途中で、マスターコアから設定されるフラグを待つように実装します。下記コードでいえばboot_slave_coreのところです

SECTION_FUNC(TEXT, __initialize)
	/*
	 * This will boot master core, just halt other cores.
	 * Note: need to be updated for complete SMP support
	 */
	csrr a0, mhartid
	beqz a0, boot_master_core    //★HART 0はマスターコア★

	li a1, CONFIG_MP_NUM_CPUS    //★CONFIG_MP_NUM_CPUSより小さいHART IDならスレーブコア★
	blt a0, a1, boot_slave_core

loop_slave_core:    //★CONFIG_MP_NUM_CPUS以上のHART IDがあったら、wfiでスリープ状態にさせる★
	wfi
	j loop_slave_core
 
boot_slave_core:
	/* Wait for signal from master core */
	la t0, riscv_init_flag
	RV_OP_LOADREG t1, (t0)
	bne a0, t1, boot_slave_core    //★riscv_init_flagに自分のHART IDが設定されるまで待つ★

	/* Setup stack */
	la t1, riscv_init_sp
	RV_OP_LOADREG sp, (t1)     //★スタックポインタ初期化★

	/* Notify to master core */
	RV_OP_STOREREG x0, (t0)    //★マスターコアにブート完了を知らせる★

	j z_riscv_slave_start

...


// zephyr/arch/riscv/core/cpu_smp.c

//★スレーブコアが実行★
void z_riscv_slave_start(int cpu_num)
{
#if defined(CONFIG_RISCV_SOC_INTERRUPT_INIT)
	soc_interrupt_init();
#endif

	riscv_cpu_cfg[cpu_num].fn(riscv_cpu_cfg[cpu_num].arg);    //★arch_start_cpu() で指定された関数と引数★
}

スレーブコアは全てが同時にriscv_init_flagをチェックしますが、riscv_init_flag == 自身のHART IDと一致しない限り永久に待つため、flagチェック以降の処理に進むことはありません。この機構により同じスタックを2つ以上のスレーブコアが同時に使ってしまうことを避けています。

以上で、マルチコアが動き始めました。続きは次回。

Zephyr OSで遊ぼう その25 - SMP対応CPUコア数4、IPIの実装

目次: Zephyr

前回はマルチコアのブート処理を実装しました。今回はIPI (Inter-Processor Interrupt、プロセッサ間割り込み) を実装します。長きに渡ったSMP対応もようやく終盤です。

IPIとは

IPIとはInter-Processor Interrupt、プロセッサ間割り込みのことで、SMPの核となる機能です。プロセッサ間で何かイベントを伝えたい（今回の場合はスレッドスケジューラを動かしてほしい）ときにIPIを発生させます。

RISC-V Privilegeの場合、IPIを発生させるにはCLINTを使います。CLINTのmsipレジスタの最下位ビットは、それぞれのHARTのmipレジスタのMSIPビットに繋がっています。平たく言えばmsipレジスタに1を書き込むと他のHARTにソフトウェア割り込みが発生する仕組みです。

CLINTはタイマードライバの実装のときに出てきました（2020年10月14日の日記参照）。IPIの実装は、他アーキテクチャだとzephyr/arch/*/coreの下に実装していることが多いですが、RISC-Vの場合はタイマードライバzephyr/drivers/timer/riscv_machine_timer.cに実装すると早いです。このやり方で合っているのかはちょっとわかりません。割り込みコントローラとして新たに実装した方が筋が良さそうではあります。

IPI発生側の実装

IPIの実装を発生させる側と受け取る側に分けて説明します。

// zephyr/drivers/timer/riscv_machine_timer.c

#define RISCV_MSIP_OTHER(id) (RISCV_MSIP_BASE + (uintptr_t)(id) * 4)
#define RISCV_MSIP     RISCV_MSIP_OTHER(z_riscv_hart_id())

...

#ifdef CONFIG_SMP
void arch_sched_ipi(void)
{
	uint32_t id = z_riscv_hart_id();

	for (int i = 0; i < CONFIG_MP_NUM_CPUS; i++) {
		volatile uint32_t *r = (uint32_t *)RISCV_MSIP_OTHER(i);

		if (i == id)
			continue;    //★自分自身には割り込みを発生させない★

		*r = 1;
	}
}

...

発生させる側の実装はarch_sched_ipi() 関数を定義して、自分以外のHARTに割り込みを発生させます。シンプルで良いですね。

IPIを発生させる処理も確認します。何箇所かありますが、短めのものを例として挙げます。

// zephyr/kernel/sched.c

static void ready_thread(struct k_thread *thread)
{
	if (z_is_thread_ready(thread)) {
		sys_trace_thread_ready(thread);
		_priq_run_add(&_kernel.ready_q.runq, thread);
		z_mark_thread_as_queued(thread);
		update_cache(0);
#if defined(CONFIG_SMP) &&  defined(CONFIG_SCHED_IPI_SUPPORTED)
		arch_sched_ipi();    //★ここで呼ばれている★
#endif
	}
}

コンフィグCONFIG_SMPは既に有効にしていますが、それ以外にもCONFIG_SCHED_IPI_SUPPORTEDを有効にする必要があるようです。

// zephyr/drivers/timer/Kconfig

config RISCV_MACHINE_TIMER
	bool "RISCV Machine Timer"
	depends on SOC_FAMILY_RISCV_PRIVILEGE
	select TICKLESS_CAPABLE
	select SCHED_IPI_SUPPORTED    #★この行を足す★
	help
	  This module implements a kernel device driver for the generic RISCV machine
	  timer driver. It provides the standard "system clock driver" interfaces.

今回IPIの機構を実装したのはタイマードライバですので、タイマーのKconfigに追加しています。

IPI受信側の実装

IPIを受け取る側の実装です。マスターコアとスレーブコアで呼ばれる関数が違う点は少しややこしいですが、基本的にやることは一緒です。前回（2020年10月10日の日記参照）、空関数で実装したsmp_timer_init() を真面目に実装するときが来ました。

 
#ifdef CONFIG_SMP
void z_riscv_sched_ipi(void);

static void soft_isr(const void *arg)
{
	volatile uint32_t *r = (uint32_t *)RISCV_MSIP;

	ARG_UNUSED(arg);

	*r = 0;                 //★ソフトウェア割り込みをクリア★
	z_riscv_sched_ipi();    //★IPIテスト用の関数（後日に説明予定）今はリンクエラーになるはずなので、コメントアウトしてOK★
}
#endif

//★マスターコア用のタイマー初期化関数★
int z_clock_driver_init(const struct device *device)
{
	ARG_UNUSED(device);

	IRQ_CONNECT(RISCV_MACHINE_TIMER_IRQ, 0, timer_isr, NULL, 0);
	last_count = mtime();
	set_mtimecmp(last_count + CYC_PER_TICK);
	irq_enable(RISCV_MACHINE_TIMER_IRQ);

#ifdef CONFIG_SMP
	IRQ_CONNECT(RISCV_MACHINE_SOFT_IRQ, 0, soft_isr, NULL, 0);    //★ソフトウェア割り込みの割り込みハンドラを設定する★
	irq_enable(RISCV_MACHINE_SOFT_IRQ);    //★ソフトウェア割り込み有効★
#endif

	return 0;
}

...

//★スレーブコア用のタイマー初期化関数★
//★マスターコアが割り込みハンドラの設定をするので、割り込みを有効にするだけに留める★
void smp_timer_init(void)
{
	last_count = mtime();
	set_mtimecmp(last_count + CYC_PER_TICK);
	irq_enable(RISCV_MACHINE_TIMER_IRQ);
	irq_enable(RISCV_MACHINE_SOFT_IRQ);
}
#endif /* CONFIG_SMP */

割り込みを有効にして、ソフトウェア割り込みハンドラでCLINTのmsipレジスタをクリアします。msipのクリアを忘れると割り込みハンドラが終わった直後、またすぐソフトウェア割り込みが入って、ハンドラが呼ばれて、割り込みが入って、ハンドラが呼ばれて、、、を繰り返してしまい処理が先に進まなくなって、ハングします。

動作確認

前回作成した環境を流用して動作確認します。

$ ninja run 

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv32
*** Booting Zephyr OS build zephyr-v2.4.0-546-g720718653f92  ***
1: thread_a: Hello World from QEMU RV32 virt board!
2: thread_b: Hello World from QEMU RV32 virt board!
0: thread_a: Hello World from QEMU RV32 virt board!
2: thread_b: Hello World from QEMU RV32 virt board!
1: thread_a: Hello World from QEMU RV32 virt board!
3: thread_b: Hello World from QEMU RV32 virt board!
1: thread_a: Hello World from QEMU RV32 virt board!

...

やった！動きました。スレッドがHART 0だけでなく、別のHARTでも実行されている様子がわかります。

リグレッションテストについては、また次回。

Zephyr OSで遊ぼう その26 - SMP対応、リグレッションテストの準備

目次: Zephyr

前回はSMPに対応しました。今回はリグレッションテストを行う準備をします。

リグレッションテストの方法

Zephyrにはsanitycheckというツールが用意されています。テストレポートやテスト用バイナリが生成されるので、Zephyrのトップディレクトリではなく、空ディレクトリを作ってから実行すると良いです。オプション -pでテストしたいプラットフォームを指定します。

$ mkdir __tmp
$ cd __tmp

$ sanitycheck -p qemu_riscv32

INFO    - JOBS: 16
INFO    - Building initial testcase list...
INFO    - 928 test configurations selected, 752 configurations discarded due to filters.
INFO    - Adding tasks to the queue...

...

いちいちsanitycheckを全部実行するとかなり時間が掛かります。テストにはタグが付いていて、sanitycheckはオプション -tで特定のタグが付いたテストのみを実行できます。便利ですね。

タグはどこから来ているかというとtestsディレクトリの下に存在するtestcase.yamlというファイルに書いてあります。

// zephyr/kernel/smp/testcase.yaml

tests:
  kernel.multiprocessing.smp:
    tags: smp    //★これがタグ★
    filter: (CONFIG_MP_NUM_CPUS > 1)    //★フィルタ、この条件が真でないとテストがスキップされる★

SMP系のテストにはsmpというタグが付いているので、-t smpと指定します。

$ sanitycheck -p qemu_riscv32 -t smp

INFO    - JOBS: 16
INFO    - Building initial testcase list...
INFO    - 928 test configurations selected, 925 configurations discarded due to filters.
INFO    - Adding tasks to the queue...
INFO    - Total complete:    3/   3  100%  skipped:    3, failed:    0
INFO    - 0 of 0 tests passed (0.00%), 0 failed, 928 skipped with 0 warnings in 1.95 seconds
INFO    - In total 0 test cases were executed on 1 out of total 292 platforms (0.34%)
INFO    - 0 tests executed on platforms, 0 tests were only built.

残念ながらテストは全てスキップされてしまいます。原因はqemu_riscv32ボードはSMPに対応していない（CONFIG_SMPをselectしない）ため、testcase.yamlに書かれたフィルタに引っかかって除外されるからです。

俺の作ったボードはどこ行った？

先日作成したqemu_rv32_virtボードならばCONFIG_SMPが有効なので、テストが実行されるはずです。

$ sanitycheck -p qemu_rv32_virt -t smp

INFO    - JOBS: 16
INFO    - Building initial testcase list...
INFO    - 0 test configurations selected, 0 configurations discarded due to filters.
INFO    - Adding tasks to the queue...

INFO    - 0 of 0 tests passed (0.00%), 0 failed, 0 skipped with 0 warnings in 0.65 seconds
INFO    - In total 0 test cases were executed on 0 out of total 291 platforms (0.00%)
INFO    - 0 tests executed on platforms, 0 tests were only built.

ダメですね。こういうときは既存のボードと見比べて差分を見るとわかりやすいです。どうやらboard.cmake, qemu_rv32_virt.yamlを作らないと、ボードが認識されないようです。

# zephyr/boards/riscv/qemu_rv32_virt/board.cmake

# SPDX-License-Identifier: Apache-2.0

set(EMU_PLATFORM qemu)

set(QEMU_binary_suffix riscv32)ARCH riscv32)
ARCH
  -nographic
  -machine virt
  -cpu rv32
  -bios none
  )
board_set_debugger_ifnset(qemu)


// zephyr/boards/riscv/qemu_rv32_virt/qemu_rv32_virt.yaml

identifier: qemu_rv32_virt
name: QEMU RISCV32 virt target
type: qemu
simulation: qemu
arch: riscv32
ram: 256
toolchain:
  - zephyr
  - xtools
testing:
  default: true
  ignore_tags:
    - net
    - bluetooth

もう一度実行します。

$ sanitycheck -p qemu_rv32_virt -t smp

INFO    - JOBS: 16
INFO    - Building initial testcase list...
INFO    - 928 test configurations selected, 925 configurations discarded due to filters.
INFO    - Adding tasks to the queue...

ERROR   - qemu_rv32_virt            tests/kernel/smp/kernel.multiprocessing.smp        FAILED: Timeout
ERROR   - see: zephyr/__tmp/sanity-out/qemu_rv32_virt/tests/kernel/smp/kernel.multiprocessing.smp/handler.log
INFO    - Total complete:    1/   3  33%  skipped:    0, failed:    1
ERROR   - qemu_rv32_virt            tests/kernel/spinlock/kernel.multiprocessing.spinlock FAILED: Failed
ERROR   - see: zephyr/__tmp/sanity-out/qemu_rv32_virt/tests/kernel/spinlock/kernel.multiprocessing.spinlock/handler.log
INFO    - Total complete:    3/   3  100%  skipped:    0, failed:    2
INFO    - 1 of 3 tests passed (33.33%), 2 failed, 925 skipped with 0 warnings in 72.61 seconds
INFO    - In total 13 test cases were executed on 1 out of total 292 platforms (0.34%)
INFO    - 2 tests executed on platforms, 1 tests were only built.

いくつかのテストがFAILEDしている、すなわちデグレードしていることを示していますが、ひとまずテストは実行できました。次回はデグレードした箇所を直します。

Zephyr OSで遊ぼう その27 - SMP対応、デグレードの修正

目次: Zephyr

前回はリグレッションテストの実行環境を整備しました。今回はリグレッションテストで見つけたバグを修正します。

バグその1、割り込みハンドラ判定関数

テストtests/kernel/smp/kernel.multiprocessing.smpが失敗しています。

ASSERTION FAIL [!arch_is_in_isr()] @ ZEPHYR_BASE/kernel/sched.c:1209

テスト対象のarch_is_in_isr() の実装を見ると、シングルコアを前提とした実装になっています。

// zephyr/arch/riscv/include/kernel_arch_func.h

static inline bool arch_is_in_isr(void)
{
	return _kernel.cpus[0].nested != 0U;    //★シングルコア前提になっている★
}


// (修正後)

static inline bool arch_is_in_isr(void)
{
	return arch_curr_cpu()->nested != 0U;
}

直し方はarch_curr_cpu() に置き換えるだけで良さそうです。

バグその2、IPIのテスト用コンフィグへの対応

他のテストではsched_ipi_has_calledが0のままらしく、怒られています。

Assertion failed at ZEPHYR_BASE/tests/kernel/smp/src/main.c:602: test_smp_ipi: (sched_ipi_has_called != 0 is false)

テスト対象のsched_ipi_has_calledをカウントアップする処理は下記のとおりです。

// zephyr/kernel/sched.c

#ifdef CONFIG_SMP
void z_sched_ipi(void)
{
	/* NOTE: When adding code to this, make sure this is called
	 * at appropriate location when !CONFIG_SCHED_IPI_SUPPORTED.
	 */
#ifdef CONFIG_TRACE_SCHED_IPI
	z_trace_sched_ipi();
#endif
}


// zephyr/tests/kernel/smp/src/main.c

#ifdef CONFIG_TRACE_SCHED_IPI
/* global variable for testing send IPI */
static volatile int sched_ipi_has_called;

void z_trace_sched_ipi(void)
{
	sched_ipi_has_called++;
}

コンフィグCONFIG_TRACE_SCHED_IPIが有効になっているときは、カーネルがz_trace_sched_ipi() を呼び出します。テストではCONFIG_TRACE_SCHED_IPIを有効にするとともに、この関数を定義して、カーネルから正常にコールバックされるかどうかを見ているようです。

以前（2020年10月16日の日記参照）、IPIのハンドラを実装した際にコメントアウトしてくれ、と言っていた部分がありました。あの部分が役に立ちます。

// zephyr/drivers/timer/riscv_machine_timer.c

#ifdef CONFIG_SMP
void z_riscv_sched_ipi(void);

static void soft_isr(const void *arg)
{
	volatile uint32_t *r = (uint32_t *)RISCV_MSIP;

	ARG_UNUSED(arg);

	*r = 0;
	z_riscv_sched_ipi();    //★この行を足す★
}
#endif


// zephyr/arch/riscv/core/cpu_smp.c

#ifdef CONFIG_SMP
void z_riscv_sched_ipi(void)
{
	z_sched_ipi();
}
#endif

本当は直接z_sched_ipi() を呼べば良いんですが、drivers以下のソースコードからはz_sched_ipi() を呼ばない方が良さそう（関数プロトタイプが見えない）だったので、arch/riscvを経由させる変な実装になっています。どう実装するのが正しいんでしょうねえ？

これでSMP系のテストを通過しました。良かった良かった。

テスラはバッテリーも作ります

【速報】テスラ「バッテリー・デー」のポイントを解説 - EVsmartブログ を読んで。

約1か月前のニュースですが「電池は自分で作るんで！さよなら！！」と鮮やかにポイ捨てされたパナソニックさん。

一緒に5000億の工場（ギガファクトリー1）を作り始めた（※1）かと思いきや、投資回収どころか、工場完成してないのに縁切り宣言を始める辺り、テスラは気が短すぎます。この決断スピードには、パナソニックはとても付いていけないでしょう。

今だから思いますが、ギガファクトリー1はうまく（？）できていて、セル：パナソニック、アセンブリ：テスラの分担となっていますので、テスラは離脱してもほぼ損害がありません。テスラは最初からバッテリー自社生産を狙っていたのでは？とすら感じます。

いずれにせよ困るのはパナソニックで、テスラに離脱されると、大量の2170セル生産能力が余ります（※2）。18650に転換してもテスラ並みの需要を持つ顧客はいるでしょうか？

（※1）ギガファクトリー1は合弁で建てているので、パナソニックとテスラの負担割合はわかりません。さすがにゼロってことはないでしょう。

（※2）ギガファクトリー1は、テスラ専用の2170（直径21mm x高さ70mm）という微妙にでかいバッテリーセルを作っており、標準的な18650（18mm x 65.0mm）セル使う機器には使いまわし効かないように見えます。

三洋に続くパナソニック爆死案件なのか？

5年位前にギガファクトリー1のニュースを見たときは「テスラと組むなんて、パナソニックも変わったなあ〜」なんて感動しました。パナソニックの社運を賭けた投資、なんてニュースも目にしたものです。

ぼーっとしているとテスラに置いて行かれ、数年後にはギガファクトリー1が、パナソニックの大型失敗案件、砺波CCD（1000億）、尼崎プラズマ（4000億？）、三洋合併（6000億円？）にランクインしてしまいそうです。

完全にテスラに寄りかかって、何も考えてないパナソニックが悪い、ダシにされて当然だろ？っていわれたら、何も言い返せないですが、さすがに合弁作ってハイさようならは、ご無体すぎて可哀想ですね……。

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

ROCK64/ROCKPro64 - まとめリンク

目次: ROCK64/ROCKPro64

ROCK64

ROCK64ブート周りの話のまとめ。

• ROCK64購入
• ROCK64とU-Bootのdistro boot
• ROCK64のU-Bootスクリプトを読む
• ROCK64のカーネルだけ元に戻したい
• Welcome back ROCK64
• ROCK64とTinker BoardのU-Boot設定メモ
• ROCK64をRaspberry Pi 3のケースに無理やり格納

ROCK64オーディオ周りの話のまとめ。

• ROCK64のアナログオーディオ - その1 - I2Sとクロックレジスタ
• ROCK64のアナログオーディオ - その2 - I2SのDMA問題
• ROCK64のアナログオーディオ - その3 - I2S2を認識しない問題解決（DMAチャネル数の問題だった）
• ROCK64のアナログオーディオ - その4 - I2S1が動かない問題解決（クロックゲート定義のバグを直した）
• ROCK64のアナログオーディオ - その5 - アナログオーディオが動かない問題解決（ACODECドライバがなかったから移植）
• ROCK64のアナログオーディオ - 手ごわい44.1kHz系
• ROCK64のアナログオーディオ - RK3328のACODEC
• ROCK64のアナログオーディオ - その6 - 44.1kHzのPCMを再生できない問題解決（GPLLクロック定義のバグを直した）
• ROCK64のアナログオーディオ - その7 - 32kHz → 44.1kHzの順でPCMを再生できない問題解決（fractional dividerの実装を変えた）
• デグレ確認のためASUS Tinker Board購入
• Tinker Boardでは不具合再現せず
• ROCK64でHDMIオーディオを使う
• ROCK64のUSBをデグレさせた
• ROCK64の音がlinux-nextで鳴らなくなった

ROCKPro64

ROCKPro64シリアル文字化けの話のまとめ。

• ROCKPro64のシリアル文字化け - オシロスコープで解析
• ROCKPro64のシリアル文字化け - 回路図を見る
• ROCKPro64のシリアル文字化け - パッチ投稿
• ROCKPro64のシリアル文字化け - LKMLでの議論
• ROCKPro64のシリアル文字化け - 結論
• ROCKPro64のシリアル文字化け - U-Bootとの比較
• ROCKPro64のシリアル文字化け - 真因発見か？

ROCKPro64オーディオの話のまとめ。

• ROCKPro64のHDMI Audioを有効にする
• ROCKPro64とアナログオーディオ - その1 - linux-nextのドライバ
• ROCKPro64とアナログオーディオ - その2 - Headphone Mixerボリュームのバグ
• ROCKPro64とアナログオーディオ - その3 - DACボリュームの仕様？
• ROCKPro64とオーディオDAC - その1 - I2Cスレーブアドレスの謎
• ROCKPro64とオーディオDAC - その2 - V2.0ボードとV2.1ボード
• ROCKPro64とオーディオDAC - その3 - Linuxのパッチ
• ROCKPro64対ONKYOでSin波の美しさ勝負
• ROCKPro64と音声ビットストリームパススルー出力
• ROCKPro64とSPDIF/HDMIビットストリームパススルー
• ROCKPro64のHDMIから音を出すKconfig設定
• ROCKPro64のI2Sクロックとピン制御

ROCKPro64のその他の話のまとめ。

• ROCKPro64とPCI Express - 動作せず
• ROCKPro64とPCI Express - 解決編

ARM関連の話。

• ARM SBCリスト
• TinkerBoardが起動しなくなった
• ARM SBCリスト2
• サーバ向けプロセッサでは最強のIntel

算数の問題

Twitterでこんな問題（リンク）を見かけたので、やってみました。緑色の図形の面積を求めよ、という問題です。

問題

算数で解く＝方程式やルートを使わない、という意味だと理解し、図形の合同性だけで解いてみます。

解答例

こんな感じで答えは4です。小学生にも解ける問題といえばそうなんでしょうけど、自分が小学生だったころに解けただろうか、と考えるとどうだろうね？

ROCKPro64のI2Sクロックとピン制御

目次: ROCK64/ROCKPro64

ROCKPro64でI2S0を無効にすると、なぜか無関係なはずのアナログオーディオ（I2S1）が鳴らなくなる、謎の挙動を示します。原因を調べてみると搭載SoCであるRockchip RK3399の不思議な設計が原因でした。

I2Sは大まかにいうと4種類の信号を使います。

MCLK

マスタークロック。DACなどを駆動させるためのクロックです。LRCKの2のべき乗倍を要求されることが多いです。典型的な倍率は128, 256, 384, 512など。

SCLK

システムクロック。I2Sデータの1ビットを表すクロックで、LRCKの64倍です。

LRCK

LRクロック。I2Sデータフレームのビットが、LチャネルまたはRチャネルのどちらに属するかを示すクロックです。クロック周波数＝サンプリング周波数です。

DATA

データ。I2S, Left Justify, Right Justifyなどエンコーディングの方法は何通りかあります。

SoC（RK3399）の仕様

RK3399の仕様をみるとMCLKの出力（RK3399のピン名だとI2S_CLK）をI2S0とI2S1で共用しています。普通、MCLKはI2Sに流す信号によって周波数が変わりますから、共用はしません。できる場合もありますが限定的です。

I2Sのハードとしては性能は等価に見えます。ただしSoCのピン設定の仕様を見る限りでは、I2S0は8ch出力まで可能、I2S1は2ch出力のみ可能です。

ボード（ROCKPro64）の仕様

I2S0はRaspberryPi互換ピンヘッダに出力されていますが、MCLKは出力されていない不思議な構成です。MCLKがなくても動くDACはあるのでしょうか……？

I2S1はEverest ES8316というDACに接続され、アナログオーディオIn/Outを実現しています。I2S_CLKはI2S1用、つまりES8316のMCLKに接続されています。

ROCKPro64の仕様としては、I2S0は遊ばせていて、I2S1はアナログオーディオ用に接続している、と考えれば、特に違和感はない構成です。

OS（linux-next）の仕様

Device Treeを見ると、I2S_CLKはI2S0の有効、無効の設定に連動して、出力ピンが制御されるように実装されています。

しかし先ほども言った通りROCKPro64の場合は、I2S_CLKはI2S1のために使われているので、この設定はボードの配線と合っていません。

直し方としては、I2S_CLKをI2S0に連動させる設定（既に存在する）に加えて、I2S_CLKをI2S1に連動させる設定を加えて、ボード側でピン設定を選ぶようにすると直せそうです。Device Tree内のピン設定がやたら増えるのは難点ですが、RK3399の仕様に由来するので仕方ないですね。

FreeRTOSで遊ぼう その5 - FreeRTOSのパッチ投稿の経過

目次: FreeRTOS

FreeRTOSへ送ったPull Requestにレビューコメントが来ました。確かPull Requestは9/14に送ったので1か月半くらい経ってます。FreeRTOSはのんびり屋さんですね。

あまりにも昔なので、送ったことを忘れかけていましたが、せっかくレビューしていただきましたし、内容を思い出しつつ、指摘事項を全て修正して再送しました。

ただ残念ながらFreeRTOSはSMPに対応していないのがわかったときから、あんまり興味がなくなっちゃったんですよね……。

世の中にはSMP対応の派生コード（Xtensa用 by Cadence, Tensilica）、SMPではないマルチコア対応の派生コード（Kendryte用 by Canaan Inc.）もありますが、本家がマルチコア化に全く手を出していないところを見ると、FreeRTOSは質素が売りなんでしょうね。

Kindle 10,000冊突破（99.9％はマンガ）

目次: Kindle

ついにKindleの本が10,000冊を超えました。間違って買った10冊以外は全部マンガですから、ほぼマンガのみで10,000冊です。

Kindle 10,000冊突破

読むものがなくなる心配は全くないです。これでも「Kindleで扱っているマンガ（83,243冊）」の1/8にもならず、「日本で商流に乗っているマンガ」となれば、1/10にも満たないでしょう。いかに日本がマンガ大国かが窺い知れると思います。

実際、これだけ買っても、私が子供の頃の名作すらほとんど入っていません。昔の作品まで買い始めると、10,000冊では済まないと思います。

今後

2013年4月にKindleを買って、およそ7年半くらいです。今後も増加のペースはさほど変わらないでしょう（読む時間がないので）から、残りの人生の全てを掛けても10万冊に届くことはありません。全てのマンガが突然全て消えたりしない限り、生きている間にマンガが枯渇して読めなくなることは、絶対にありません。安心ですね。

自分には合わない作品も多々あるでしょうし、総数が10万冊では足りなくなるのでは？と思われるかもしれませんが、マンガの新作は毎月たくさん出ていますから、自分が楽しいなと思う作品に限っても枯渇することはまずないでしょう。

つまり一生続けられる趣味です。素晴らしい。

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

Kindle Fire先生ご乱心

目次: Kindle

最近Kindleストアで表示される本のタイトルとカバー絵が違っていることがあります。

本のタイトルとカバー絵が違う例

例えばこの画面の場合は、下記のように食い違っています。

• Q.E.D. iff 12巻 → 最後のレストラン16巻
• C.M.B. 16巻 → 海王ダンテ11巻

以前は見かけませんでしたが、今は週1くらいで見かけます。

毎回チェックしていませんが、今まで確かめた限りでは文字のタイトルが間違っていて、カバー絵が正しいです。つまり、タップするとカバー絵（最後のレストランや海王ダンテ）に合った本が表示されます。

何が起きるとこうなるんでしょうね？Amazon側がおかしいとは中々考えにくいので、単純に私のKindle Fireがおかしい可能性が高そうですかねえ？？

まあ、最初からKindle Fireは動きがおかしいので、今さら何が起きても不思議では無いのですが……本が探しにくくて困っちゃいます。

いまいちなデザインのKindleマンガストア

目次: Kindle

Kindle Fireで「本」→「ストア」→「マンガストア」と辿ると、ストアアプリとは微妙に違う変なストア画面（下記のような、いかにもWebページらしき画面）が出ます。

縦表示のKindleのマンガストア（左側にスクロールした状態、5位の本が見えない）

縦表示のKindleのマンガストア（右側にスクロールした状態、1位の本が見えない）

一見すると普通なのですが、Kindle Fireだと最強に使いづらいです。なぜかというと、Kindleを縦にした状態だと横幅が収まらず、ストアの右側が見えないのです。

横表示のKindleのマンガストア

ちなみに横にした状態だとすべて表示されますが、他社デバイスならまだしも、自社デバイスでこの体たらくはひどいですね。

Kindle Fireで表示の確認してないんでしょうか？Kindle Fireはもう二度と買わねえポイントがまた1ポイント増えましたよ……。

Kindleで買った本の一覧を見る方法（決定版）

目次: Kindle

Kindleで購入した書籍のタイトル一覧を取得したいなあと思って、Kindle for PCが生成するファイルを眺めていたら、
C:\Users\username\AppData\Local\Amazon\Kindle\Cache\KindleSyncMetadataCache.xml
にメタデータ（タイトル、読みがな、出版日など）が書かれたXMLファイルが置かれていました。これは良さそうです。

ただしこのメタデータキャッシュには改行が全く入っていないためmeta_dataタグの終わりに改行を入れたり、不要なタグを消すと見通しが良くなります。メタデータに読みやすいように改行を入れると、下記のようになります。

<meta_data>
  <ASIN>B084JT7PXW</ASIN>
  <title pronunciation="コノヒーラーメンドクサイ001 (エムエフシー)">このヒーラー、めんどくさい　１ (MFC)</title>
  <authors>
    <author pronunciation="タンネンニハッコウ">丹念に発酵</author>
  </authors>
  <publishers>
    <publisher>KADOKAWA</publisher>
  </publishers>
  <publication_date>2020-02-21T00:00:00+0000</publication_date>
  <purchase_date>2020-10-19T00:06:12+0000</purchase_date>
  <textbook_type></textbook_type>
  <cde_contenttype>EBOK</cde_contenttype>
  <content_type>application/x-mobipocket-ebook</content_type>
</meta_data>

私の場合はタイトル一覧が欲しいだけなので、titleタグに挟まれたテキストだけ引っこ抜けば良さそうです。この程度であればXMLをパースするまでもないですね。

不思議なメタデータ

メタデータキャッシュには不思議なデータもあります。まず目に付いたのが、メタデータは残っていて、Kindle fire HDで検索すると出てきますが、Kindle for PCやAmazonで検索しても「存在しない」と言われる本です。たしかKindle fire HDにオマケで付いていた辞書だったと思います。

<title>Duden Dictionary test</title><ASIN>B003YL4LVQ</ASIN><authors><author>Robert Wolfe</author></authors><publishers><publisher>Kongc Test Pub</publisher></publishers><publication_date>2011-02-04T00:00:00+0000</publication_date>
<title>Oxford Dictionary of English</title><ASIN>B003WUYRGI</ASIN><authors><author>Stevenson, Angus</author></authors><publishers><publisher>Oxford University Press</publisher></publishers><publication_date>2010-08-16T00:00:00+0000</publication_date>
<title>The New Oxford American Dictionary (English Edition)</title><ASIN>B003ODIZL6</ASIN><authors><author>McKean, Erin</author></authors><publishers><publisher>Oxford University Press</publisher></publishers><publication_date>2010-04-01T00:00:00+0000</publication_date>

他に目に付いたものとしては、メタデータがほぼ空っぽでKindleで検索しても、Amazonで検索しても出てこない、廃盤と思われるASINの本が12冊ほどありました。

<title>---------------</title><ASIN>B005EOCESI</ASIN><authors><author>----</author></authors><publishers><publisher>-------</publisher></publishers><publication_date>2010-08-16T00:00:00+0000</publication_date>
<title>---------------</title><ASIN>B005F12G6U</ASIN><authors><author>----</author></authors><publishers><publisher>-------</publisher></publishers><publication_date>2010-08-16T00:00:00+0000</publication_date>
<title>---------------</title><ASIN>B005F12G7O</ASIN><authors><author>----</author></authors><publishers><publisher>-------</publisher></publishers><publication_date>2010-08-16T00:00:00+0000</publication_date>

とりあえず3つほど載せましたが、ASIN以外は全て同じ情報です。何かミスったのか、理由があってシリーズごと廃盤になったんですかね……？