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

link もっと前
   2020年 10月 25日 ---> 2020年 10月 16日
link もっと後

2020年 10月 25日

算数の問題

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


問題

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


解答例

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

編集者: すずき(更新: 2020年 10月 29日 23:51)

コメント一覧

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



2020年 10月 23日

ROCK64/ROCKPro64 - まとめリンク

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

一覧が欲しくなってきたので作りました。

ROCK64

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

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

ROCKPro64

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

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

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

編集者: すずき(更新: 2021年 6月 28日 15:40)

コメント一覧

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



2020年 10月 21日

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

【速報】テスラ「バッテリー・デー」のポイントを解説 - 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 から転記しておくことにした。加筆修正。

編集者: すずき(更新: 2020年 11月 1日 18:03)

コメント一覧

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



2020年 10月 18日

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

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

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

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

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

リグレッションテストのエラー、arch_is_in_isr()
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 のままらしく、怒られています。

リグレッションテストのエラー、sched_ipi_has_called
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 をカウントアップする処理は下記のとおりです。

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 のハンドラを実装した際にコメントアウトしてくれ、と言っていた部分がありました。あの部分が役に立ちます。

IPI ハンドラから z_sched_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 系のテストを通過しました。良かった良かった。

編集者: すずき(更新: 2021年 6月 17日 18:59)

コメント一覧

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



2020年 10月 17日

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

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

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

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

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

sanitycheck の実行
$ 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 の実行(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 の実行(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 を作らないと、ボードが認識されないようです。

sanitycheck の実行に必要なファイルを追加
# 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 の実行(SMP 系)、実行できた

$ 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 している、すなわちデグレードしていることを示していますが、ひとまずテストは実行できました。次回はデグレードした箇所を直します。

編集者: すずき(更新: 2020年 10月 18日 03:24)

コメント一覧

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



2020年 10月 16日

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 の実装を発生させる側と受け取る側に分けて説明します。

IPI 発生側の実装 (arch_sched_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 を発生させる処理も確認します。何箇所かありますが、短めのものを例として挙げます。

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 を有効にする必要があるようです。

IPI のサポートを追加する

// 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() を真面目に実装するときが来ました。

IPI 受信側の実装(割り込みハンドラ)
 
#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 のクリアを忘れると割り込みハンドラが終わった直後、またすぐソフトウェア割り込みが入って、ハンドラが呼ばれて、割り込みが入って、ハンドラが呼ばれて、、、を繰り返してしまい処理が先に進まなくなって、ハングします。

動作確認

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

IPI 受信側の実装(割り込みハンドラ)
$ 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 でも実行されている様子がわかります。

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

編集者: すずき(更新: 2020年 10月 18日 03:22)

コメント一覧

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



link もっと前
   2020年 10月 25日 ---> 2020年 10月 16日
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 9/24 14:00

カレンダー

<2020>
<<<10>>>
----123
45678910
11121314151617
18192021222324
25262728293031

最近のコメント 5件

  • link 21年03月03日
    すずき 「お役に立てたようで幸いです。」
    (更新:06/17 17:24)
  • link 21年03月03日
    Shige 「とても参考になりました。\nGood!!...」
    (更新:06/17 13:28)
  • link 20年12月19日
    すずき 「なるほど、地元愛 No.1 は福岡なんで...」
    (更新:05/02 00:08)
  • link 20年12月19日
    Twitterから 「> 大学時代に知り合った人たちを思...」
    (更新:04/28 13:38)
  • link 21年04月12日
    すずき 「コメントありがとうございます。ご参考にな...」
    (更新:04/18 22:39)

最近の記事 3件

link もっとみる
  • link 21年04月05日
    すずき 「[GCC を調べる - GCC 8.3 の folding バ] ...」
    (更新:09/24 14:00)
  • link 21年09月20日
    すずき 「[RISC-V の cmodel] 目次: RISC-V - まと...」
    (更新:09/21 23:04)
  • link 21年06月18日
    すずき 「[RISC-V まとめリンク] 目次: RISC-V - まとめリ...」
    (更新:09/21 23:01)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報