コグノスケ

Zephyr OS で遊ぼう その 15 - SMP 対応の準備、コンテキストスイッチの実装、中編 2、既存実装調査

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

前回は、新しいコンテキストスイッチ関数に対応している AArch64 の実装のうち、共通部分からアーキテクチャ依存部分に至るまでを調べました。引き続きアーキテクチャ依存部分を調べます。

アーキ依存部分の処理（AArch64）

コンテキストスイッチのアーキテクチャ依存部分（AArch64 向け arch_switch()）の実装はほぼ全てアセンブラで実装されています。

コンテキストスイッチの本体は z_arm64_context_switch です。x0 が new_thread, x1 が old_thread だと思って動きます。コンテキストスイッチの仕事はレジスタの値を切り替え前のスレッド構造体（old_thread）に退避し、切り替え後のスレッド構造体（new_thread）からレジスタの値を復旧させることです。

// zephyr/arch/arm/core/aarch64/switch.S

GTEXT(z_arm64_svc)
SECTION_FUNC(TEXT, z_arm64_svc)
	z_arm64_enter_exc x2, x3, x4    /* ★レジスタをスタックに退避（切り替え前のスレッド）★ */

	switch_el x1, 3f, 2f, 1f
3:
	mrs	x0, esr_el3
	b	0f
2:
	mrs	x0, esr_el2
	b	0f
1:
	mrs	x0, esr_el1
0:
	lsr	x1, x0, #26

	cmp	x1, #0x15 /* 0x15 = SVC */
	bne	inv

	/* Demux the SVC call */
	and	x1, x0, #0xff
	cmp	x1, #_SVC_CALL_CONTEXT_SWITCH
	beq	context_switch    /* ★以下参照★ */

...

context_switch:
	/*
	 * Retrieve x0 and x1 from the stack:
	 *  - x0 = new_thread->switch_handle = switch_to thread
	 *  - x1 = x1 = &old_thread->switch_handle = current thread
	 */
	ldp	x0, x1, [sp, #(16 * 10)]    /* ★x1 = 切り替え前、x0 = 切り替え後のスレッド★ */

	/* Get old thread from x1 */
	sub	x1, x1, ___thread_t_switch_handle_OFFSET

	/* Switch thread */
	bl	z_arm64_context_switch    /* ★コンテキストスイッチ本体（スタックが切り替わる）★ */

exit:
	z_arm64_exit_exc x0, x1, x2    /* ★レジスタをスタックから復旧（切り替え後のスレッド）★ */

...

/**
 * @brief Routine to handle context switches
 *
 * This function is directly called either by _isr_wrapper() in case of
 * preemption, or z_arm64_svc() in case of cooperative switching.
 */

GTEXT(z_arm64_context_switch)
SECTION_FUNC(TEXT, z_arm64_context_switch)
	/* addr of callee-saved regs in thread in x2 */
	ldr	x2, =_thread_offset_to_callee_saved
	add	x2, x2, x1

	/* Store rest of process context including x30 */
	stp	x19, x20, [x2], #16
	stp	x21, x22, [x2], #16
	stp	x23, x24, [x2], #16
	stp	x25, x26, [x2], #16
	stp	x27, x28, [x2], #16
	stp	x29, x30, [x2], #16

	/* Save the current SP */
	mov	x1, sp
	str	x1, [x2]

	/* addr of callee-saved regs in thread in x2 */
	ldr	x2, =_thread_offset_to_callee_saved
	add	x2, x2, x0

	/* Restore x19-x29 plus x30 */
	ldp	x19, x20, [x2], #16
	ldp	x21, x22, [x2], #16
	ldp	x23, x24, [x2], #16
	ldp	x25, x26, [x2], #16
	ldp	x27, x28, [x2], #16
	ldp	x29, x30, [x2], #16

	ldr	x1, [x2]
	mov	sp, x1    /* ★ここで切り替え後のスレッドのスタックに変わる★ */

#ifdef CONFIG_TRACING
	stp	xzr, x30, [sp, #-16]!
	bl	sys_trace_thread_switched_in
	ldp	xzr, x30, [sp], #16
#endif

	/* We restored x30 from the process stack. There are three possible
	 * cases:
	 *
	 * - We return to z_arm64_svc() when swapping in a thread that was
	 *   swapped out by z_arm64_svc() before jumping into
	 *   z_arm64_exit_exc()
	 * - We return to _isr_wrapper() when swapping in a thread that was
	 *   swapped out by _isr_wrapper() before jumping into
	 *   z_arm64_exit_exc()
	 * - We return (jump) into z_thread_entry_wrapper() for new threads
	 *   (see thread.c)
	 */
	ret


// zephyr/include/arm/aarch64/thread.h

struct _callee_saved {
	uint64_t x19;
	uint64_t x20;
	uint64_t x21;
	uint64_t x22;
	uint64_t x23;
	uint64_t x24;
	uint64_t x25;
	uint64_t x26;
	uint64_t x27;
	uint64_t x28;
	uint64_t x29; /* FP */
	uint64_t x30; /* LR */
	uint64_t sp;
};

コードを見て一発で理解するのは厳しいので、処理の概要を書いておきます。

Zephyr AArch64 のコンテキストスイッチ概要

コンテキストスイッチの際にスタックが切り替わります。z_arm64_exit_exc x0, x1, x2 はシステムコールを呼んだスレッド（＝切り替え前のスレッド）ではなく、コンテキストスイッチ後のスレッドのスタックからレジスタを復旧します。

これも文章だと何だかわからないので、紙芝居を書いておきます。

Zephyr AArch64 のコンテキストスイッチ: 例外ハンドラ先頭

Zephyr AArch64 のコンテキストスイッチ: 例外ハンドラ入り口、スタックへレジスタ退避

Zephyr AArch64 のコンテキストスイッチ: コンテキストスイッチ前半、切り替え前スレッド構造体へレジスタ退避

Zephyr AArch64 のコンテキストスイッチ: コンテキストスイッチ前半、切り替え前スレッド構造体へスタックポインタ退避

Zephyr AArch64 のコンテキストスイッチ: コンテキストスイッチ後半、切り替え後スレッド構造体からレジスタ復旧

Zephyr AArch64 のコンテキストスイッチ: コンテキストスイッチ後半、切り替え後スレッド構造体からスタックポインタ復旧（＝スタック切り替え）

Zephyr AArch64 のコンテキストスイッチ: 例外ハンドラ入り口、切り替え後のスタックからレジスタ復旧

図には書きませんでしたが、例外からリターンする命令（eret 命令）が参照するレジスタ（SPSR, ELR レジスタ）もスタックに退避、復旧しています。従って eret が戻る先は切り替え後のスレッドのコードです。

Zephyr OS で遊ぼう その 16 - SMP 対応の準備、コンテキストスイッチの実装、後編 1、RISC-V のコンテキストスイッチ

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

前回は、AArch64 の実装を調べました。いよいよ新しい方式のコンテキストスイッチを実装したいところですが、その前にもう一つだけ RISC-V の既存実装を調べます。

RISC-V の 2つのコンテキストスイッチ経路

RISC-V 向け実装において、コンテキストスイッチが行われる条件は 2つあります。1つはスリープしたときなどに呼ばれる明示的なコンテキストスイッチです。do_swap() を経由します。もう 1つは割り込み発生時に行われるプリエンプションです。

明示的コンテキストスイッチ

do_swap() -> arch_switch() ラッパー関数 -> z_riscv_switch() -> ecall -> __irq_wrapper -> is_syscall -> reschedule -> no_reschedule -> mret

プリエンプション

（任意の場所） -> __irq_wrapper -> is_interrupt -> on_irq_stack -> 割り込みハンドラ（isr_timer() など） -> on_thread_stack -> reschedule -> no_reschedule -> mret

明示的コンテキストスイッチについては、以前（2020年 9月 29日の日記参照）実装したラッパー関数がスタート地点となります。コードを変更する前に、従来のコンテキストスイッチがどんな経路を通るか確認します。

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

static inline void arch_switch(void *switch_to, void **switched_from)
{
	z_riscv_switch(switch_to, switched_from);
}


// zephyr/arch/riscv/core/swap.S

/*
 * void z_riscv_switch(void *switch_to, void **switched_from)
 */
SECTION_FUNC(exception.other, z_riscv_switch)

	/* Make a system call to perform context switch */
	ecall    //★例外を発生させる★

	jalr x0, ra


// zephyr/arch/riscv/core/isr.S

/*
 * Handler called upon each exception/interrupt/fault
 * In this architecture, system call (ECALL) is used to perform context
 * switching or IRQ offloading (when enabled).
 */
SECTION_FUNC(exception.entry, __irq_wrapper)
	/* Allocate space on thread stack to save registers */
	addi sp, sp, -__z_arch_esf_t_SIZEOF

...

	/*
	 * Check if exception is the result of an interrupt or not.
	 * (SOC dependent). Following the RISC-V architecture spec, the MSB
	 * of the mcause register is used to indicate whether an exception
	 * is the result of an interrupt or an exception/fault. But for some
	 * SOCs (like pulpino or riscv-qemu), the MSB is never set to indicate
	 * interrupt. Hence, check for interrupt/exception via the __soc_is_irq
	 * function (that needs to be implemented by each SOC). The result is
	 * returned via register a0 (1: interrupt, 0 exception)
	 */
	jal ra, __soc_is_irq

	/* If a0 != 0, jump to is_interrupt */
	addi t1, x0, 0
	bnez a0, is_interrupt    //★割り込みの場合はこちらにジャンプする★

	/*
	 * If the exception is the result of an ECALL, check whether to
	 * perform a context-switch or an IRQ offload. Otherwise call _Fault
	 * to report the exception.
	 */
	csrr t0, mcause
	li t2, SOC_MCAUSE_EXP_MASK
	and t0, t0, t2
	li t1, SOC_MCAUSE_ECALL_EXP

	/*
	 * If mcause == SOC_MCAUSE_ECALL_EXP, handle system call,
	 * otherwise handle fault
	 */
	beq t0, t1, is_syscall    //★ecall の場合はこちらにジャンプする★

	/*
	 * Call _Fault to handle exception.
	 * Stack pointer is pointing to a z_arch_esf_t structure, pass it
	 * to _Fault (via register a0).
	 * If _Fault shall return, set return address to no_reschedule
	 * to restore stack.
	 */
	addi a0, sp, 0
	la ra, no_reschedule
	tail _Fault    //★いずれでもなければ停止させる★

...

Zephyr RISC-V 向け実装では、割り込み・例外ハンドラは 1つだけです。割り込みも例外も全て __irq_wrapper に飛んできますから、最初の方で要因をチェックして仕分けしています。RISC-V の規格としては割り込み要因ごとに別の割り込みハンドラに飛べる形式（ベクタ形式）もありますが、Zephyr は使っていません。

// zephyr/arch/riscv/core/isr.S

is_syscall:
	/*
	 * A syscall is the result of an ecall instruction, in which case the
	 * MEPC will contain the address of the ecall instruction.
	 * Increment saved MEPC by 4 to prevent triggering the same ecall
	 * again upon exiting the ISR.
	 *
	 * It's safe to always increment by 4, even with compressed
	 * instructions, because the ecall instruction is always 4 bytes.
	 */
	RV_OP_LOADREG t0, __z_arch_esf_t_mepc_OFFSET(sp)
	addi t0, t0, 4
	RV_OP_STOREREG t0, __z_arch_esf_t_mepc_OFFSET(sp)

...

	/*
	 * Go to reschedule to handle context-switch
	 */
	j reschedule  //★コンテキストスイッチ★

...

reschedule:

...

	/* Get reference to _kernel */
	la t0, _kernel

	/* Get pointer to _kernel.current */
	RV_OP_LOADREG t1, _kernel_offset_to_current(t0)

	/*
	 * Save callee-saved registers of current thread
	 * prior to handle context-switching
	 */
	RV_OP_STOREREG s0, _thread_offset_to_s0(t1)
	RV_OP_STOREREG s1, _thread_offset_to_s1(t1)
...
	RV_OP_STOREREG s10, _thread_offset_to_s10(t1)
	RV_OP_STOREREG s11, _thread_offset_to_s11(t1)

...

	/*
	 * Save stack pointer of current thread and set the default return value
	 * of z_swap to _k_neg_eagain for the thread.
	 */
	RV_OP_STOREREG sp, _thread_offset_to_sp(t1)
	la t2, _k_neg_eagain
	lw t3, 0x00(t2)
	sw t3, _thread_offset_to_swap_return_value(t1)

	/* Get next thread to schedule. */
	RV_OP_LOADREG t1, _kernel_offset_to_ready_q_cache(t0)

	/*
	 * Set _kernel.current to new thread loaded in t1
	 */
	RV_OP_STOREREG t1, _kernel_offset_to_current(t0)

	/* Switch to new thread stack */
	RV_OP_LOADREG sp, _thread_offset_to_sp(t1)

	/* Restore callee-saved registers of new thread */
	RV_OP_LOADREG s0, _thread_offset_to_s0(t1)
	RV_OP_LOADREG s1, _thread_offset_to_s1(t1)
...
	RV_OP_LOADREG s10, _thread_offset_to_s10(t1)
	RV_OP_LOADREG s11, _thread_offset_to_s11(t1)

...

no_reschedule:

...

	/* Restore MEPC register */
	RV_OP_LOADREG t0, __z_arch_esf_t_mepc_OFFSET(sp)
	csrw mepc, t0

	/* Restore SOC-specific MSTATUS register */
	RV_OP_LOADREG t0, __z_arch_esf_t_mstatus_OFFSET(sp)
	csrw mstatus, t0

...

	/* Restore caller-saved registers from thread stack */
	RV_OP_LOADREG ra, __z_arch_esf_t_ra_OFFSET(sp)
	RV_OP_LOADREG gp, __z_arch_esf_t_gp_OFFSET(sp)
	RV_OP_LOADREG tp, __z_arch_esf_t_tp_OFFSET(sp)
	RV_OP_LOADREG t0, __z_arch_esf_t_t0_OFFSET(sp)
...
	RV_OP_LOADREG a6, __z_arch_esf_t_a6_OFFSET(sp)
	RV_OP_LOADREG a7, __z_arch_esf_t_a7_OFFSET(sp)

	/* Release stack space */
	addi sp, sp, __z_arch_esf_t_SIZEOF

	/* Call SOC_ERET to exit ISR */
	SOC_ERET

コメントが丁寧に書いてあって素晴らしいですね。コンテキストスイッチの手順は AArch64 の実装とほぼ同じですが、AAarch64 は明示的なコンテキストスイッチとプリエンプションが独立して実装されており、RISC-V は reschedule で両者が合流する点が違います。コンテキストスイッチの説明は先日（2020年 10月 1日の日記参照）の紙芝居が参考になるかと思います。

明示的なコンテキストスイッチとプリエンプションの部分が大体仕分けできました。いよいよ実装に挑みます。続きはまた。

Zephyr OS で遊ぼう その 17 - SMP 対応の準備、コンテキストスイッチの実装、後編 2、明示的コンテキストスイッチ

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

前回は RISC-V の明示的なコンテキストスイッチの既存実装を調べました。今回は新しいコンテキストスイッチを実装します。

対応方針

従来と新形式のコンテキストスイッチで大きく異なるのは、下記の要素です。

（※）初めは切り替え元スレッドですが、z_get_next_switch_handle() を呼ぶと、切り替え先のスレッドに変わります。

割り込まれた処理の返り値

割り込まれた処理の返り値を -EINTR に設定するために必要な処理は、do_swap() がやるため実装は必要ありません。従来の処理が間違って発動しないように #ifdef で消しておきます。

// zephyr/arch/riscv/core/isr.S の差分

+	/* Save stack pointer of current thread. */
+	RV_OP_STOREREG sp, _thread_offset_to_sp(t1)    //★スタックポインタ保存は新しい形式でも必要★
+
+#ifndef CONFIG_USE_SWITCH
 	/*
-	 * Save stack pointer of current thread and set the default return value
-	 * of z_swap to _k_neg_eagain for the thread.
+	 * Set the default return value of z_swap to _k_neg_eagain for
+	 * the thread.
 	 */
-	RV_OP_STOREREG sp, _thread_offset_to_sp(t1)
 	la t2, _k_neg_eagain
 	lw t3, 0x00(t2)
 	sw t3, _thread_offset_to_swap_return_value(t1)    //★返り値設定は不要★
+#endif /* !CONFIG_USE_SWITCH */


// zephyr/arch/riscv/core/offsets/offsets.c

//★_thread_offset_to_swap_return_value() マクロを使えるようにする仕掛け★

#ifndef CONFIG_USE_SWITCH
GEN_OFFSET_SYM(_thread_arch_t, swap_return_value);    //★いらない★
#endif /* !CONFIG_USE_SWITCH */


// zephyr/include/arch/riscv/thread.h

struct _thread_arch {
#ifndef CONFIG_USE_SWITCH
	uint32_t swap_return_value; /* Return value of z_swap() */    //★いらない★
#endif /* !CONFIG_USE_SWITCH */
};

処理を消すだけでも動きますが、swap_return_value を間違って使うとバグの元なので、変数宣言ごと消します。

切り替え元/切り替え先スレッド

従来は常に _kernel 変数を見れば良かったので楽でした。新形式では明示的コンテキストスイッチとプリエンプションで切り替え元/切り替え先スレッドの取得方法が異なります。よって、明示的コンテキストスイッチとプリエンプションで、スレッドの扱いを揃える必要があります。

設計する人の自由で決めて構いませんが、今回は合流地点（reschedule）に辿り着く前に切り替え元（old_thread）、切り替え先スレッド（new_thread）を取得し _current に new_thread を設定し, t1 レジスタに old_thread を設定することとします。

明示的コンテキストスイッチの場合、切り替え元と切り替え先スレッドは引数で渡されます。引数はハンドラの先頭でスタックに保存されますので、スタックからロードできます。

// zephyr/arc/riscv/core/isr.S

#ifdef CONFIG_USE_SWITCH
	/*
	 * Get new_thread and old_thread from stack.
	 *   - a0 = new_thread->switch_handle  -> _current
	 *   - a1 = &old_thread->switch_handle -> t1
	 */

	/* Get reference to _kernel */
	la t2, _kernel

	/* Get new_thread from stack */
	RV_OP_LOADREG t1, __z_arch_esf_t_a0_OFFSET(sp)    //★スタックから切り替え先スレッド取得★

	/* Set new thread to _current */
	RV_OP_STOREREG t1, ___cpu_t_current_OFFSET(t2)    //★(2) この関数内で new_thread を _current に設定★

	/* Get old_thread from stack and set it to t1 */
	RV_OP_LOADREG t1, __z_arch_esf_t_a1_OFFSET(sp)    //★(1)スタックから切り替え元スレッド取得、t1 レジスタに old_thread を設定★
	addi t1, t1, -___thread_t_switch_handle_OFFSET    //★(A) old_thread->switch_handle の更新★
#endif

	/*
	 * Go to reschedule to handle context-switch
	 */
	j reschedule


// zephyr/arch/riscv/core/thread.c

void arch_new_thread(struct k_thread *thread, k_thread_stack_t *stack,
		     char *stack_ptr, k_thread_entry_t entry,
		     void *p1, void *p2, void *p3)
{
	struct __esf *stack_init;

...

#ifdef CONFIG_USE_SWITCH
	thread->switch_handle = thread;    //★(B) switch_handle の初期値設定★
#endif
}

処理 (1) で new_thread を _current に設定していて、処理 (2) で old_thread を t1 レジスタに設定してから、reschedule にジャンプします。

wait_for_switch() への対処

スレッドと直接関係ないものの old_thread->switch_handle を更新する処理も重要です。あとでハマりやすいポイントですので、補足しておきます。

以前、少し言及しましたが（2020年 9月 30日の日記参照）、switch_handle の更新を実装し忘れると CONFIG_SMP を有効にしたときに wait_for_switch() で無限ループに陥ってハマります。

Zephyr のドキュメントにて arch_switch() を見ると（Zephyr Project: arch_switch）、スレッドにレジスタを退避後、old_thread->switch_handle を NULL 以外の値で書き換える必要があります。これはコンテキストスイッチ処理内で行う (A) の処理に相当します。

実はこれだけではダメです。wait_for_switch() はコンテキストスイッチの「前」に呼ばれるからです。一番最初に発生するコンテキストスイッチの old_thread->switch_handle は誰も書き換えてくれないのでハングします。この問題の対処としてスレッド生成時に switch_handle を初期化する (B) の処理を実装しています。

次回はプリエンプションの実装をします。

Zephyr OS で遊ぼう その 18 - SMP 対応の準備、コンテキストスイッチの実装、後編 3、プリエンプション

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

前回は RISC-V の 2つあるコンテキストスイッチのうち、明示的なコンテキストスイッチを実装しました。今回はもう一方のプリエンプションを実装します。

対応方針（再掲）

従来と新形式のコンテキストスイッチで大きく異なるのは、下記の要素です。

（※）初めは切り替え元スレッドですが、z_get_next_switch_handle() を呼ぶと、切り替え先のスレッドに変わります。

割り込まれた処理の返り値

明示的プリエンプションと共通の部分のため、改めて直す必要はないです。

切り替え元/切り替え先スレッド

かなり処理が変わるため、#ifdef だとごちゃごちゃしてしまいます。スレッド取得の専用マクロを作ります。

// zephyr/arch/riscv/core/isr.S

/*
 * xcpu: pointer of _kernel.cpus[n]
 * xold: (result) old thread
 * xnew: (result) next thread to schedule
 *
 * after this function a0 is broken
 */
.macro z_riscv_get_next_switch_handle xcpu, xold, xnew
#ifdef CONFIG_USE_SWITCH
	addi sp, sp, -RV_REGSIZE*2               //★新たな処理★
	RV_OP_STOREREG ra, RV_REGSIZE(sp)
	addi a0, sp, 0                           //★スタックの先頭へのポインタを第一引数 old_thread とする★
	jal ra, z_arch_get_next_switch_handle    //★(2) この関数内で _current が new_thread に設定される★
	addi xnew, a0, 0                        //★a0 が返り値、切り替え先のスレッドが入っている★
	RV_OP_LOADREG xold, 0(sp)               //★スタック先頭に切り替え元のスレッドが入っている★
	RV_OP_LOADREG ra, RV_REGSIZE(sp)
	addi sp, sp, RV_REGSIZE*2
#else
	/* Get pointer to _kernel.current */                           //★従来処理★
	RV_OP_LOADREG xold, _kernel_offset_to_current(xcpu)          //★切り替え元スレッド★

	RV_OP_LOADREG xnew, _kernel_offset_to_ready_q_cache(xcpu)    //★切り替え先スレッド★
#endif
.endm


// zephyr/arch/riscv/core/thread.c

#ifdef CONFIG_USE_SWITCH
void *z_arch_get_next_switch_handle(struct k_thread **old_thread)
{
	*old_thread =  _current;    //★スタックの先頭に現在のスレッド（= 切り替え元のスレッド）を保存★

	return z_get_next_switch_handle(*old_thread);
}
#endif

わざわざスタックのポインタを経由して書き込むなんてややこしいことをせず、RV_OP_LOADREG xold, _kernel_offset_to_current(xcpu) で良いのでは？と思うかもしれませんが、z_arch_get_next_switch_handle() の呼び出しでどのレジスタが壊れるかわかりませんから、結局 xold をスタックに退避する必要があります。

明示的コンテキストスイッチと処理を共有しているため、ちょっとわかりにくいですが、プリエンプションの中心となる処理はこの辺りです。

// zephyr/arch/riscv/core/isr.S

 #ifdef CONFIG_PREEMPT_ENABLED
-	/*
-	 * Check if we need to perform a reschedule
-	 */
-
-	/* Get pointer to _kernel.current */
-	RV_OP_LOADREG t2, _kernel_offset_to_current(t1)
-
 	/*
 	 * Check if next thread to schedule is current thread.
 	 * If yes do not perform a reschedule
 	 */
-	RV_OP_LOADREG t3, _kernel_offset_to_ready_q_cache(t1)
+	z_riscv_get_next_switch_handle t1, t2, t3
 	beq t3, t2, no_reschedule
+
+#ifdef CONFIG_USE_SWITCH
+	/* Set old thread to t1 */
+	addi t1, t2, 0             //★(1) t1 レジスタに old_thread を設定する★
+#endif
+

前回決めたとおり、合流地点（reschedule）に辿り着く前に切り替え元（old_thread）、切り替え先スレッド（new_thread）を取得し _current に new_thread を設定し, t1 レジスタに old_thread を設定します。

処理 (1) で new_thread を _current に設定していて、処理 (2) で old_thread を t1 レジスタに設定してから、reschedule に到達します。プリエンプション処理のすぐ後に reschedule ラベルがあるので、ジャンプは不要です。

とても長くなってしまいましたが、新しい形式のコンテキストスイッチを実装できました。苦労の割に動作の見た目は何も変わりませんが、本命の SMP 対応に活用するためなので我慢です。

Zephyr OS で遊ぼう その 19 - SMP 対応 CPU コア数 1、ビルドエラーの対処 1

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

新しい形式のコンテキストスイッチを実装しました。以前書いたとおり、SMP 対応は下記の手順で進めています。再掲しておきましょう。

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

やっと最初の項目が終わったところです。いよいよ CONFIG_SMP を有効にします。大量のビルドエラーが発生しますので、1つずつやっつけます。

コンパイルエラー: arch_curr_cpu

環境や利用するバージョンによりますが、最初に目にするのは arch_curr_cpu() に関するコンパイルエラーだと思われます。

../include/sys/arch_interface.h:367:28: warning: 'arch_curr_cpu' declared 'static' but never defined [-Wunused-function]
 static inline struct _cpu *arch_curr_cpu(void);
                            ^~~~~~~~~~~~~

この関数は、現在の CPU（= 実行中の CPU）の情報を返します。RISC-V には mhartid という自身の HART ID を取得できる CSR（Control and Status Registers）が規格で定められており、この手の処理は楽に実装できます。

// zephyr/include/arch/riscv/arch_inlines.h

static inline uint32_t z_riscv_hart_id(void)
{
	uint32_t hartid;

	__asm__ volatile ("csrr %0, mhartid" : "=r"(hartid));

	return hartid;
}

static inline struct _cpu *arch_curr_cpu(void)
{
#ifdef CONFIG_SMP
	uint32_t hartid = z_riscv_hart_id();

	return &_kernel.cpus[hartid];
#else
	return &_kernel.cpus[0];
#endif
}

他のアーキテクチャを見る限り arch_inlines.h に定義するのが良さそうですが、RISC-V 向けには存在しません。新たに追加しましょう。ヘッダファイルを追加したら、親玉の arch_inlines.h に #include を追加します。

// zephyr/include/arch/arch_inlines.h

...

#if defined(CONFIG_X86) || defined(CONFIG_X86_64)
#include <arch/x86/arch_inlines.h>
#elif defined(CONFIG_ARC)
#include <arch/arc/arch_inlines.h>
#elif defined(CONFIG_XTENSA)
#include <arch/xtensa/arch_inlines.h>
#elif defined(CONFIG_RISCV)             //★この 2行を追加する
#include <arch/riscv/arch_inlines.h>    //★
#endif

このヘッダは明示的に #include しなくても常にインクルードされます。

リンクエラー: arch_start_cpu

メイン CPU 以外の CPU（2つ目以降の CPU）を起動するための関数です。SMP モードの他、非 SMP モード（※）でも使います。今は CPU 1つで動かすので、とりあえず空関数を定義します。

関数はどこに定義しても動きますが、他アーキテクチャの実装を見ると SMP 関連の関数は 1つの C ソースファイルにまとめた方が良さそうなので、新たに cpu_smp.c を作成します。

// zephyr/arch/riscv/core/CMakeLists.txt

zephyr_library_sources(
  cpu_idle.c
  cpu_smp.c    ★足す★
  fatal.c
  irq_manage.c
  isr.S
  prep_c.c
  reset.S
  swap.S
  thread.c
)


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

void arch_start_cpu(int cpu_num, k_thread_stack_t *stack, int sz,
		    arch_cpustart_t fn, void *arg)
{
}

Zephyr というか CMake のルールですけども、新たにソースコードを追加した場合、CMakeLists.txt にファイル名を追加しコンパイル対象に指定する必要があります。特定の CONFIG_* が定義されたときだけコンパイルすることも可能ですが、今回は不要です。

（※）Zephyr のマルチプロセッサモードには、SMP モードと非 SMP モードがあります。SMP モードは、互いのプロセッサ間で IPI（Inter-Processor Interrupt）を用いて制御します。非 SMP モードでは、互いのプロセッサのことは何も考慮せず動作します。

リンクエラー: smp_timer_init

これは SMP 用のタイマーの初期化関数です。タイマーのハードウェア構成はアーキテクチャによって様々で、一様に「こう実装すべき」という指針はありません。今は CPU 1つで動かすので、とりあえず空関数を定義します。

// zephyr/drivers/timer/riscv_machine_timer.c

...

void smp_timer_init(void)
{
}

今回は RISC-V の Privilege mode のタイマーが実装対象です。タイマードライバは riscv_machine_timer.c になります。

長くなってきたので、続きは次回。

Zephyr OS で遊ぼう その 20 - SMP 対応 CPU コア数 1、ビルドエラーの対処 2

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

SMP 対応の序盤、ビルドエラー対処の続きです。

オフセットマクロ

ビルドの難所です。CONFIG_SMP を有効にすると isr.S で大量にエラーが出ます。

zephyr/arch/riscv/core/isr.S:305: Error: illegal operands `lw sp,_kernel_offset_to_irq_stack(t2)'
zephyr/arch/riscv/core/isr.S:316: Error: illegal operands `lw t3,_kernel_offset_to_nested(t2)'
zephyr/arch/riscv/core/isr.S:376: Error: illegal operands `sw t2,_kernel_offset_to_nested(t1)'
zephyr/arch/riscv/core/isr.S:463: Error: illegal operands `lw t1,(0x78+___ready_q_t_cache_OFFSET)(t0)'
zephyr/arch/riscv/core/isr.S:468: Error: illegal operands `sw t1,_kernel_offset_to_current(t0)'

原因は _kernel_offset_* 系のオフセットマクロが未定義になるためです。

// zephyr/kernel/include/offsets_short.h

#ifndef CONFIG_SMP
/* Relies on _kernel.cpu being the first member of _kernel and having 1 element
 */
#define _kernel_offset_to_nested \r	(___cpu_t_nested_OFFSET)

#define _kernel_offset_to_irq_stack \r	(___cpu_t_irq_stack_OFFSET)

#define _kernel_offset_to_current \r	(___cpu_t_current_OFFSET)
#endif /* CONFIG_SMP */

#define _kernel_offset_to_idle \r	(___kernel_t_idle_OFFSET)

#define _kernel_offset_to_current_fp \r	(___kernel_t_current_fp_OFFSET)

#define _kernel_offset_to_ready_q_cache \r	(___kernel_t_ready_q_OFFSET + ___ready_q_t_cache_OFFSET)

...


// zephyr/include/kernel_offsets.h

...

#ifndef CONFIG_SMP
GEN_OFFSET_SYM(_ready_q_t, cache);
#endif

当たり前ですが、この #ifdef を外すだけでは SMP は動きません。対策方法を理解するには、Zephyr のカーネル構造体の内部に、少しだけ立ち入る必要があります。

カーネル構造体（CPU が 1つの場合）

カーネル構造体は _kernel という名前で何度か出ていましたが、見覚えありますか？なくても全然構わないです。下記のような定義の構造体です。細かい定義はさておき、大事なことは cpus が _kernel の先頭にある、という点です。

// zephyr/kernel/sched.c

/* the only struct z_kernel instance */
struct z_kernel _kernel;


// zephyr/include/kernel_structs.h

struct z_kernel {
	struct _cpu cpus[CONFIG_MP_NUM_CPUS];    //★_kernel の先頭に cpus がある★

#ifdef CONFIG_SYS_CLOCK_EXISTS
	/* queue of timeouts */
	sys_dlist_t timeout_q;
#endif

#ifdef CONFIG_SYS_POWER_MANAGEMENT
	int32_t idle; /* Number of ticks for kernel idling */
#endif

	/*
	 * ready queue: can be big, keep after small fields, since some
	 * assembly (e.g. ARC) are limited in the encoding of the offset
	 */
	struct _ready_q ready_q;

...


// zephyr/include/kernel_structs.h

struct _cpu {
	/* nested interrupt count */
	uint32_t nested;

	/* interrupt stack pointer base */
	char *irq_stack;

	/* currently scheduled thread */
	struct k_thread *current;

	/* one assigned idle thread per CPU */
	struct k_thread *idle_thread;

...

CPU が 1つしか存在しない場合、cpus の要素数は 1 であり、_kernel の先頭 = cpus[0] の先頭になります。そのため _kernel.cpus[0].current のオフセット = cpu 構造体の current へのオフセット、です。offsets_short.h の定義はこの性質を利用しています。

C 言語だと cpus[0] と cpus[i] の違いでしかなく、ありがたみがわかりませんが、アセンブラだと非常に単純かつ高速にオフセットを求めることができます。下記は isr.S から持ってきた例ですが、_kernel.cpus[0].current へのアクセスがわずか 2命令で実現できます。

	la t0, _kernel
	RV_OP_LOADREG t0, _kernel_offset_to_current(t0)

残念ながら SMP の場合は cpus が 1つではありませんから、上記の最適化は使えません。cpus[n] のオフセット、つまり HART ID * sizeof(struct _cpu) を計算する必要があります。

まずは struct _cpu のオフセットマクロが未定義なので、追加します。Zephyr では GEN_ABSOLUTE_SYM() というマクロが用意されており、アセンブラ用のマクロを生成してくれます。便利ですね。

// zephyr/arch/riscv/core/offsets/offsets.c

#ifdef CONFIG_SMP
GEN_ABSOLUTE_SYM(__cpu_t_SIZEOF, sizeof(_cpu_t));
#endif

次に isr.S のビルドエラーが出ている箇所を直します。

// zephyr/arch/riscv/core/isr.S

/*
 * xreg0: result &_kernel.cpu[mhartid]
 * xreg1: work area
 */
.macro z_riscv_get_cpu xreg0, xreg1
#ifdef CONFIG_SMP
	csrr xreg0, mhartid
	addi xreg1, x0, __cpu_t_SIZEOF
	mul  xreg1, xreg0, xreg1
	la   xreg0, _kernel
	add  xreg0, xreg0, xreg1
#else
	la   xreg0, _kernel
#endif
.endm


//（変更前）

/* Get reference to _kernel */
la t1, _kernel

/* Decrement _kernel.cpus[0].nested variable */
lw t2, _kernel_offset_to_nested(t1)
addi t2, t2, -1
sw t2, _kernel_offset_to_nested(t1)


//（変更後）

/* Get reference to _kernel.cpus[n] */
z_riscv_get_cpu t1, t2               //★z_riscv_get_cpu に置き換え★

/* Decrement _kernel.cpus[n].nested variable */
lw t2, ___cpu_t_nested_OFFSET(t1)    //★_kernel_offset_to_* から ___cpu_t_*_OFFSET に置き換え★
addi t2, t2, -1
sw t2, ___cpu_t_nested_OFFSET(t1)

修正方針は 2つあります。

• cpus[0] -> cpus[n]: _kernel.cpus[n] のアドレスを取得するマクロ z_riscv_get_cpu を作成。_kernel = cpus[0] のアドレスを取得しているところを z_riscv_get_cpu で置き換え。
• _kernel_offset_to_* は未定義なので、___cpu_t_*_OFFSET で置き換え。

ここまで直すとビルドが通るはずですが、実はビルドが通るだけでは動きません。次回は実行時のエラーを対策します。

Zephyr OS で遊ぼう その 21 - SMP 対応 CPU コア数 1、実行時エラーの対処

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

SMP 対応のうち、ビルドエラーの対処が終わったので、実行時エラーに対処します。

実行時エラー: k_spin_lock

CONFIG_SMP を有効にすると、k_spin_lock() 内で atomic_cas() を呼ぶようになります。すると k_spin_lock() -> atomic_cas() -> z_impl_atomic_cas() -> k_spin_lock() という循環呼び出しが発生し、スタックオーバーフローを起こしてクラッシュします。これは Zephyr のバグではなくコンフィグの設定間違いが原因です。

// zephyr/include/spinlock.h

static ALWAYS_INLINE k_spinlock_key_t k_spin_lock(struct k_spinlock *l)
{
	ARG_UNUSED(l);
	k_spinlock_key_t k;

	/* Note that we need to use the underlying arch-specific lock
	 * implementation.  The "irq_lock()" API in SMP context is
	 * actually a wrapper for a global spinlock!
	 */
	k.key = arch_irq_lock();

#ifdef CONFIG_SPIN_VALIDATE
	__ASSERT(z_spin_lock_valid(l), "Recursive spinlock %p", l);
#endif

#ifdef CONFIG_SMP
	while (!atomic_cas(&l->locked, 0, 1)) {    //★CONFIG_SMP が有効だと atomic_cas() を呼ぶ★
	}
#endif

...


// zephyr/include/sys/atomic.h

#ifdef CONFIG_ATOMIC_OPERATIONS_BUILTIN
static inline bool atomic_cas(atomic_t *target, atomic_val_t old_value,
			  atomic_val_t new_value)
{
	return __atomic_compare_exchange_n(target, &old_value, new_value,
					   0, __ATOMIC_SEQ_CST,
					   __ATOMIC_SEQ_CST);
}
#elif defined(CONFIG_ATOMIC_OPERATIONS_C)    //★既存の RISC-V ボードはこちらが有効になっている★
__syscall bool atomic_cas(atomic_t *target, atomic_val_t old_value,
			 atomic_val_t new_value);

#else
extern bool atomic_cas(atomic_t *target, atomic_val_t old_value,
		      atomic_val_t new_value);
#endif

...


// build/zephyr/include/generated/syscalls/atomic.h

static inline bool atomic_cas(atomic_t * target, atomic_val_t old_value, atomic_val_t new_value)
{
#ifdef CONFIG_USERSPACE
	if (z_syscall_trap()) {
		return (bool) arch_syscall_invoke3(*(uintptr_t *)&target, *(uintptr_t *)&old_value, *(uintptr_t *)&new_value, K_SYSCALL_ATOMIC_CAS);
	}
#endif
	compiler_barrier();
	return z_impl_atomic_cas(target, old_value, new_value);    //★ここにくる★
}

...


// zephyr/kernel/CMakeLists.txt

target_sources_ifdef(CONFIG_ATOMIC_OPERATIONS_C   kernel PRIVATE atomic_c.c)    //★CONFIG_ATOMIC_OPERATIONS_C 有効のとき実装は atomic_c.c★

...

// zephyr/kernel/atomic_c.c

bool z_impl_atomic_cas(atomic_t *target, atomic_val_t old_value,
		       atomic_val_t new_value)
{
	k_spinlock_key_t key;
	int ret = false;

	key = k_spin_lock(&lock);    //★循環呼び出し★

	if (*target == old_value) {
		*target = new_value;
		ret = true;
	}

	k_spin_unlock(&lock, key);

	return ret;
}

...

RISC-V の SoC のコンフィグでは大抵 CONFIG_ATOMIC_OPERATIONS_C が有効になっていて、atomic_cas() の実装としてスピンロックを使います。これは SMP と相性が悪く、CONFIG_ATOMIC_OPERATIONS_C と CONFIG_SMP を同時に有効にすると先ほど説明した循環呼び出しが発生してしまいます。

循環呼び出しを防ぐには独自に atomic_cas() を実装する必要がありますが、アトミック操作を自分で実装＆検証するのは大変ですから、RISC-V のアトミック命令（Atomic Extension）とコンパイラの機能を頼ります。

以前追加した QEMU RISC-V 32bit virtpc 用のコンフィグを SMP のテスト用に改造します。

# zephyr/soc/riscv/riscv-privilege/rv32-virt/Kconfig.soc

config SOC_QEMU_RV32_VIRT
	bool "QEMU RV32 virt SOC implementation"
	select ATOMIC_OPERATIONS_C if !SMP         # 非 SMP のときは従来通り
	select ATOMIC_OPERATIONS_BUILTIN if SMP    # SMP のときは Atomic Extension に頼る

コンフィグ CONFIG_ATOMIC_OPERATIONS_BUILTIN を有効にすると、Zephyr は atomic_cas() の実装として __atomic_compare_exchange_n() ビルトイン関数を使います。ビルトイン関数を使うにはコンパイラのサポートが必要で、今のところ、サポートしているのは GCC のみだと思います。LLVM でも使えるかもしれませんが、未調査です。

これで CONFIG_SMP を有効にしても、エラーやハングアップすることなく、今までどおりに動作するようになったはずです。

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 - 解決編

算数の問題

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 は質素が売りなんでしょうね。