コグノスケ

未来から過去へ表示

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

もっと前

2020年10月18日 >>> 2020年11月14日

もっと後

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系のテストを通過しました。良かった良かった。

編集者:すずき(2023/09/24 12:11)

コメント一覧

コメントはありません。

この記事にコメントする

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

【速報】テスラ「バッテリー・デー」のポイントを解説 - 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/01 18:03)

コメント一覧

コメントはありません。

この記事にコメントする

ROCK64/ROCKPro64 - まとめリンク

目次: ROCK64/ROCKPro64

ROCK64

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

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

ROCK64のアナログオーディオ - RK3328のACODEC

ROCKPro64

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

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

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

ARM関連の話。

編集者:すずき(2024/01/13 17:20)

コメント一覧

コメントはありません。

この記事にコメントする

算数の問題

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

問題

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

解答例

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

編集者:すずき(2020/10/29 23:51)

コメント一覧

コメントはありません。

この記事にコメントする

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の仕様に由来するので仕方ないですね。

編集者:すずき(2020/11/04 08:58)

コメント一覧

コメントはありません。

この記事にコメントする

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

編集者:すずき(2023/09/24 08:52)

コメント一覧

コメントはありません。

この記事にコメントする

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から転記しておくことにした。大幅に加筆修正。

編集者:すずき(2021/12/08 04:02)

コメント一覧

コメントはありません。

この記事にコメントする

Kindle Fire先生ご乱心

目次: Kindle

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

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

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

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

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

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

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

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

編集者:すずき(2021/12/08 04:03)

コメント一覧

コメントはありません。

この記事にコメントする

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

目次: Kindle

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

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

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

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

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

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

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

編集者:すずき(2021/12/08 03:52)

コメント一覧

コメントはありません。

この記事にコメントする

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

目次: Kindle

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

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

本1冊分のメタデータ構造


<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にオマケで付いていた辞書だったと思います。

タイトルあり、Kindle fireで検索できるが、Amazonで検索できない本


<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冊ほどありました。

タイトルなし、Amazonで検索できない本


<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以外は全て同じ情報です。何かミスったのか、理由があってシリーズごと廃盤になったんですかね……？

編集者:すずき(2021/12/08 04:05)