目次: 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 (エムエフシー)">このヒーラー、めんどくさい 1 (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以外は全て同じ情報です。何かミスったのか、理由があってシリーズごと廃盤になったんですかね……?
目次: Kindle
Kindle Fireで「本」→「ストア」→「マンガストア」と辿ると、ストアアプリとは微妙に違う変なストア画面(下記のような、いかにもWebページらしき画面)が出ます。
縦表示のKindleのマンガストア(左側にスクロールした状態、5位の本が見えない)
縦表示のKindleのマンガストア(右側にスクロールした状態、1位の本が見えない)
一見すると普通なのですが、Kindle Fireだと最強に使いづらいです。なぜかというと、Kindleを縦にした状態だと横幅が収まらず、ストアの右側が見えないのです。
ちなみに横にした状態だとすべて表示されますが、他社デバイスならまだしも、自社デバイスでこの体たらくはひどいですね。
Kindle Fireで表示の確認してないんでしょうか?Kindle Fireはもう二度と買わねえポイントがまた1ポイント増えましたよ……。
目次: Kindle
最近Kindleストアで表示される本のタイトルとカバー絵が違っていることがあります。
例えばこの画面の場合は、下記のように食い違っています。
以前は見かけませんでしたが、今は週1くらいで見かけます。
毎回チェックしていませんが、今まで確かめた限りでは文字のタイトルが間違っていて、カバー絵が正しいです。つまり、タップするとカバー絵(最後のレストランや海王ダンテ)に合った本が表示されます。
何が起きるとこうなるんでしょうね?Amazon側がおかしいとは中々考えにくいので、単純に私のKindle Fireがおかしい可能性が高そうですかねえ??
まあ、最初からKindle Fireは動きがおかしいので、今さら何が起きても不思議では無いのですが……本が探しにくくて困っちゃいます。
目次: Kindle
ついにKindleの本が10,000冊を超えました。間違って買った10冊以外は全部マンガですから、ほぼマンガのみで10,000冊です。
読むものがなくなる心配は全くないです。これでも「Kindleで扱っているマンガ(83,243冊)」の1/8にもならず、「日本で商流に乗っているマンガ」となれば、1/10にも満たないでしょう。いかに日本がマンガ大国かが窺い知れると思います。
実際、これだけ買っても、私が子供の頃の名作すらほとんど入っていません。昔の作品まで買い始めると、10,000冊では済まないと思います。
2013年4月にKindleを買って、およそ7年半くらいです。今後も増加のペースはさほど変わらないでしょう(読む時間がないので)から、残りの人生の全てを掛けても10万冊に届くことはありません。全てのマンガが突然全て消えたりしない限り、生きている間にマンガが枯渇して読めなくなることは、絶対にありません。安心ですね。
自分には合わない作品も多々あるでしょうし、総数が10万冊では足りなくなるのでは?と思われるかもしれませんが、マンガの新作は毎月たくさん出ていますから、自分が楽しいなと思う作品に限っても枯渇することはまずないでしょう。
つまり一生続けられる趣味です。素晴らしい。
メモ: 技術系の話はFacebookから転記しておくことにした。大幅に加筆修正。
目次: FreeRTOS
FreeRTOSへ送ったPull Requestにレビューコメントが来ました。確かPull Requestは9/14に送ったので1か月半くらい経ってます。FreeRTOSはのんびり屋さんですね。
あまりにも昔なので、送ったことを忘れかけていましたが、せっかくレビューしていただきましたし、内容を思い出しつつ、指摘事項を全て修正して再送しました。
ただ残念ながらFreeRTOSはSMPに対応していないのがわかったときから、あんまり興味がなくなっちゃったんですよね……。
世の中にはSMP対応の派生コード(Xtensa用 by Cadence, Tensilica)、SMPではないマルチコア対応の派生コード(Kendryte用 by Canaan Inc.)もありますが、本家がマルチコア化に全く手を出していないところを見ると、FreeRTOSは質素が売りなんでしょうね。
目次: ROCK64/ROCKPro64
ROCKPro64でI2S0を無効にすると、なぜか無関係なはずのアナログオーディオ(I2S1)が鳴らなくなる、謎の挙動を示します。原因を調べてみると搭載SoCであるRockchip RK3399の不思議な設計が原因でした。
I2Sは大まかにいうと4種類の信号を使います。
RK3399の仕様をみるとMCLKの出力(RK3399のピン名だとI2S_CLK)をI2S0とI2S1で共用しています。普通、MCLKはI2Sに流す信号によって周波数が変わりますから、共用はしません。できる場合もありますが限定的です。
I2Sのハードとしては性能は等価に見えます。ただしSoCのピン設定の仕様を見る限りでは、I2S0は8ch出力まで可能、I2S1は2ch出力のみ可能です。
I2S0はRaspberryPi互換ピンヘッダに出力されていますが、MCLKは出力されていない不思議な構成です。MCLKがなくても動くDACはあるのでしょうか……?
I2S1はEverest ES8316というDACに接続され、アナログオーディオIn/Outを実現しています。I2S_CLKはI2S1用、つまりES8316のMCLKに接続されています。
ROCKPro64の仕様としては、I2S0は遊ばせていて、I2S1はアナログオーディオ用に接続している、と考えれば、特に違和感はない構成です。
Device Treeを見ると、I2S_CLKはI2S0の有効、無効の設定に連動して、出力ピンが制御されるように実装されています。
しかし先ほども言った通りROCKPro64の場合は、I2S_CLKはI2S1のために使われているので、この設定はボードの配線と合っていません。
直し方としては、I2S_CLKをI2S0に連動させる設定(既に存在する)に加えて、I2S_CLKをI2S1に連動させる設定を加えて、ボード側でピン設定を選ぶようにすると直せそうです。Device Tree内のピン設定がやたら増えるのは難点ですが、RK3399の仕様に由来するので仕方ないですね。
Twitterでこんな問題(リンク)を見かけたので、やってみました。緑色の図形の面積を求めよ、という問題です。
算数で解く=方程式やルートを使わない、という意味だと理解し、図形の合同性だけで解いてみます。
こんな感じで答えは4です。小学生にも解ける問題といえばそうなんでしょうけど、自分が小学生だったころに解けただろうか、と考えるとどうだろうね?
目次: ROCK64/ROCKPro64
ROCK64ブート周りの話のまとめ。
ROCK64オーディオ周りの話のまとめ。
ROCKPro64シリアル文字化けの話のまとめ。
ROCKPro64オーディオの話のまとめ。
ROCKPro64のその他の話のまとめ。
ARM関連の話。
【速報】テスラ「バッテリー・デー」のポイントを解説 - 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から転記しておくことにした。加筆修正。
目次: Zephyr
前回はリグレッションテストの実行環境を整備しました。今回はリグレッションテストで見つけたバグを修正します。
テスト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() に置き換えるだけで良さそうです。
他のテストでは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系のテストを通過しました。良かった良かった。
目次: 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
前回はマルチコアのブート処理を実装しました。今回はIPI (Inter-Processor Interrupt、プロセッサ間割り込み) を実装します。長きに渡ったSMP対応もようやく終盤です。
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の実装を発生させる側と受け取る側に分けて説明します。
// 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を受け取る側の実装です。マスターコアとスレーブコアで呼ばれる関数が違う点は少しややこしいですが、基本的にやることは一緒です。前回(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
CONFIG_SMP有効、1コア、HART ID != 0の動作確認をしました。以前書いたとおり、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
前回はHART 0以外で動かす際に、動作確認が必要なので準備を行いました。今回はHART 0以外で動かします。
一番簡単なやり方は、ブート時の判定条件を変えることだと思います。通常は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)を更新する他、割り込みを契機にコンテキストスイッチを行っています。
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
前回はCONFIG_SMPのビルドエラーと実行時エラーに対応しました。以前書いたとおり、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
SMP対応のうち、ビルドエラーの対処が終わったので、実行時エラーに対処します。
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を有効にしても、エラーやハングアップすることなく、今までどおりに動作するようになったはずです。
< | 2020 | > | ||||
<< | < | 11 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | - | - | - | - | - |
合計:
本日: