コグノスケ

Zephyrのコンテキストスイッチ

目次: Zephyr

RISC-V向けZephyrの新しいコンテキストスイッチ（CONFIG_USE_SWITCH=y）を実装しているのですが、浮動小数点演算つまりFPUを使うスレッドを生成するとハングします。調べてみると、私が実装している場所の外にある、新しいコンテキストスイッチ（zephyr/kernel/include/kswap.hのdo_swap() 関数）の実装が今まで（CONFIG_USE_SWITCH=n）と違うように見えます。まだ確証はないですけど。

従来の処理arch_swap() では、現在のスレッド（_kernel.current）がコンテキストスイッチ（arch_swap() 内のシステムコール）の内部で旧 → 新に置き換えます。つまりcurrentは切替「前」のスレッドを指している状態でコンテキストスイッチが始まります。

ところがdo_swap() の場合、現在のスレッド（_kernel.current）がコンテキストスイッチ（arch_switch() 関数）を呼ぶ「前」に旧 → 新スレッドに置き換えます。つまりcurrentは切替「後」のスレッドを指している状態でコンテキストスイッチが始まります。

ハングに至るメカニズム

RISC-V Zephyr（他のアーキテクチャも同じかな？）ではFPU使えるスレッドと使えないスレッドを使い分けることができます。コンテキストスイッチ処理では、currentスレッドがFPUを使うか使わないかにより処理を変えています。

• FPUを使う: currentの浮動小数点レジスタをスタックに退避する処理を実行
• FPUを使わない: 退避する処理はスキップされる

私が実装したコンテキストスイッチも当然同じように実装したのですが……。先ほど説明したようにdo_swap() はcurrentを切替「後」のスレッドに設定するため、こんな悲劇が起きます。

• 旧スレッド（FPU使用不可）→ 新スレッド（FPU使用可）の明示的コンテキストスイッチを行う
• do_swap() がcurrentを新スレッド（FPU使用可）に変える
• コンテキストスイッチ
• 旧スレッド（FPU使用不可）で実行しているのに、currentは新スレッド（FPU使用可）になっている
• 浮動小数点レジスタを退避しようとして「不正命令例外」で死ぬ

原因の一端は掴めたものの、どうして他のアーキテクチャは困っていないのか？do_swap() の実装は意図的なのか？良くわかりません……。

C言語の標準的な標準ではない機能

目次: C言語とlibc

C言語のmath.hヘッダには、円周率πを表すマクロM_PIが定義されています。しかしこのマクロ、コンパイラに -std=c99やc11を指定すると使えなくなるんですね。C言語通には常識かもしれませんが、個人的にハマったのでメモしておきます。

#include <math.h>

int main(void)
{
	return M_PI;
}

$ gcc -Wall -std=c99 a.c

a.c: In function ‘main’:
a.c:5:9: error: ‘M_PI’ undeclared (first use in this function)
    5 |  return M_PI;
      |         ^~~~
a.c:5:9: note: each undeclared identifier is reported only once for each function it appears in

もしc99やc11でもM_PIを使いたい場合は、math.hをインクルードする前に_DEFAULT_SOURCE（_GNU_SOURCEでも良いです）をdefineすると使えるようになります。

#define _DEFAULT_SOURCE

#include <math.h>

int main(void)
{
	return M_PI;
}

使えるようになりました。

ゲーム用のPCを作りたいが、高い

目次: ゲーム

普段PCで何か作業する場合WindowsのノートPCを使っていて、マイコンボードでの実験や開発はLinuxのデスクトップPCにリモートアクセスして行っています。通常の作業には申し分ない性能と使い勝手が実現できています。

が、ゲームとなると話がやや違ってきます。ゲームは大抵Windowsを要求してくるので、我が家の唯一のWindows PCであるノートPCで遊ぶしかないんですけども、最近の3Dを多用したゲームは重すぎて、そのうちGPUが燃える（物理的に）んじゃないかと心配になってきます。

GPUが高すぎる

しばらく前に在宅勤務環境を整えた（2021年2月12日の日記参照）こともあり、机近辺に新たなPCを置けそうな場所ができました。Windowsをインストールしたゲーム用PCを新たに作りたいところですが、最近はあまりにもGPUが高すぎて購入に踏み切れません……。

いわゆるミドルエンドと呼ばれるTDP 200W以下（※）クラスは、今だとRadeon RX 6600 XTもしくはGeForce RTX 3060辺りだと思うんですが、Radeonはそもそも売り切れていて手に入りませんし、RTX 3060はお値段が6万円オーバーとあまりにも高すぎます。

GPUの値段はまだまだ下がらないようですし、諦めて買うしかないんですかねえ？

（※）補助電源8pin x 1くらいのカードをイメージしてます。GPUに供給可能な電力はPCIeカードエッジ（75W）+ 補助電源8pin x 1（150W）= Max 225Wです。

Zephyr on HiFive Unmatched/HiFive Unleashed

目次: Zephyr

ZephyrのHiFive UnmatchedとHiFive Unleashedへのポーティングが本家のmainにマージ（※）されました。2.7.0のマージウインドウが終わるまで、メンテナーチームは忙しそうだったので、もうしばらく放置かな？と思っていましたが、昨日突然マージされました。

これは以前トライしていたZephyrのHiFive Unleashedへの移植（2021年6月6日の日記参照）に加え、HiFive Unmatchedへの移植（2021年8月20日の日記参照）も追加したものです。RISC-Vはメンテナーが少ないこともあって割と放置気味になりがちなんですよね……。

ポーティングといっても、最低限の設定＋とりあえず起動するだけで、ほぼ何にも使えない（UARTとSPIくらいしか動きません）から、まだまだこれからだな。うん。

（※）最近はmasterという単語はダメだねってことで、既存のリポジトリもmaster → mainに置き換えられたプロジェクトが増えてます。

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

開発環境としてのHiFive Unmatched

目次: RISC-V

最近はHiFive Unmatched（HiFive Unleashedも使い勝手はほぼ同じ）を使っていることが多いのですが、このボードは開発環境としてはなかなか魅力的です。素敵なところをいくつか挙げると、

• USBケーブル1本でJTAGとUARTが同時に使える（JTAGの箱が要らない）
• 元々Linux用のボードなので、1GHzクラスのRV64IMAC 1コア＋RV64GC 4コア、USB、PCIe、GPIO、SPIなど重厚なハードが揃っている
• SoCの仕様書が公開されていて、誰でもアクセスできる

他社のボードもいくつか使いましたけど、USB-JTAGチップ搭載のボードはあまり見かけません。通常はJTAGを使いたいと思ったら、JTAGの箱（私はSEGGER J-LINK EDUを使っています）が必要です。が、HiFive系のボードはJTAGの箱が不要です。これは地味に嬉しいです。

製品では切り捨てられがちなJTAG

JTAGはベアメタルやブートローダのようなローレベル開発で重宝しますが、製品のボードにはまず搭載されることはないです。理由は単純。JTAGはデバッグ用の機能で、正常動作しているときには全く使わないからです。ボードのコストアップにしかならず、製品用の設計では真っ先に切られる機能です。以前、メーカーに居た時もデバッグ機能はソフトハード関わらず真っ先に切られていました。

利用者目線から見ると、デバッグ機能を切って安くあげるのは大正義です。利用者はまずデバッグ機能なんて使いませんし、デバッグ機能を悪用して機器に侵入するなどの被害を防ぐ効果もあります。

とはいえ開発者目線から見るとデバッグ機能のないボードやSoCは、トラブったとき解析しづらくて困ります……。なので、SoCレベルではデバッグ機能ON、ボードレベルではOFFにしておいて、不具合解析の際は特殊な治具を繋いでボードレベルのデバッグ機能をONにする設計を良く見かけます。