調査期間：2026-11-02 08:00 ~ 2026-11-03 08:00（北京時間、24時間）

情報源：RT-Thread 公式ニュースインターフェースと公式サイトのニュース一覧、GitHub メインリポジトリの commits / PR / Issue / releases / tags、RT-Thread org の全 35 リポジトリをプッシュ時間順に確認、GitHub リポジトリ検索（rt-thread キーワードと topic:rt-thread）、チップメーカー GitHub 組織（先楫 HPMicro の 64 リポジトリ）、Google News の中国語・英語 7 グループのクエリ（プロキシ経由）、HN Algolia、電子工程専輯 RT-Thread 公式コラム、上海市経済情報化委員会ウェブサイト、club.rt-thread.org フォーラム（今期もサイト WAF の制限あり）

今期インデックス

    1. カーネルとバージョン動向
      • USB device のホスト制御可能な長さ 2 件を同時マージ：文字列記述子インデックスと MS OS 互換 ID（11-02）
      • SDHCI ホスト初期化の 32 バイト名バッファ、RT_NAME_MAX を 64 にするとスタックを踏む（11-02）
      • klibc のバイトループが GCC に memset と認識され、libc なしターゲットでリンク失敗（11-02）
      • tiny vsnprintf が long long を long として扱い、INT64_MAX が -1 と表示される（11-02）
      • SCMI リセットコントローラが誤ったコンテナを取得、ドライバ登録順もサブシステム初期化に変更（11-02）
      • X/Y/Z バージョンルールがドキュメントレビューへ、Z バージョン対応の QEMU テストリストも同時公開（11-02 ~ 11-03）
    1. セキュリティフォローとマージ待ちキュー
      • グラフィックデバイスの負オフセット：pread と pwrite が位置検証を回避し、カーネルの任意読み書きに直結（11-02）
      • pipe のパッチは当日到着、ドライバ側でコマンドごとに自己防衛する形に変更（11-02）
      • メンテナ自ら旧提案 2 件を再作成：getaddrinfo と GPT パーティションテーブル（11-03）
      • キューにはまだ 5 件：cromfs ディレクトリ名、poll カウント、9pfs 長さ、DHCP プール枯渇、signalfd（10-21 ~ 11-03）
    1. 公式・コミュニティ活動
      • 上海オープンソースソフトウェア応用イノベーションコンテスト閉幕、睿赛德は 12 の産業課題提示者の一つ（10-29 ~ 10-30、11-02 公式発表）
      • RT-Thread と NXP のユーザーアンケート開始、NXP 対応範囲は MCX A366 と A156 まで列挙（11-02）
      • 公式ニュースインターフェースは依然 6 月 17 日で停止、発表の出口は引き続きメディアコラム（11-03）
    1. エコシステムとベンダー対応
      • 先楫半導体が一度に 12 の BSP リポジトリを v1.13.0 へ更新、HPM5100EVK も新規追加（11-02）
      • AWTK メインラインは通常通り反復、今期のコミットに RT-Thread との特段の関連なし（11-02）
    1. 業界応用
      • 産業ゲートウェイのオープンソース：FreeModbus マスタ、LVGL パネル、4G クラウド接続と HTTP OTA を 1 つのイメージに統合（11-02）
      • Sifli SF32LB52 スマートウォッチファームウェア、RT-Thread をウェアラブル基盤に搭載（11-02）
    1. 今期のトレンドと総括
      • トレンド：1 日 6 件のマージはすべて積み残し案件、セキュリティキューはメンテナが引き継ぎ開始
      • 限界と重複排除の説明

1. カーネルとバージョン動向

1.1 USB device のホスト制御可能な長さ 2 件を同時マージ：文字列記述子インデックスと MS OS 互換 ID（11-02）

日付：2026-11-02 11:47（マージ時間）　出典：提案 #11545、提案 #11546、欠陥 #4782、欠陥 #11287

同一作者による 2 件が同じ時間帯にマージされ、いずれも USB device プロトコルスタックにおける「長さとインデックスがホストから来る」という古くからの問題を修正した。

#11545 は文字列記述子インデックスを処理する（39 行追加、15 行削除）。元の実装では文字列を取得する前にホスト指定のインデックスを検証せず、インデックスに従って直接文字列テーブルを読みに行っていた。範囲外の場合は隣接するインターフェース文字列ポインタを読んでしまい、未登録の場合はヌルポインタを逆参照する可能性もあった。修正方法は 2 つ：テーブルを読む前にインデックスの境界を判定し、未知または未登録のインデックスは一律 EP0 で STALL を返す；Microsoft OS 互換 ID 記述子が登録されている場合にのみ OS 文字列を返す。対応する欠陥 #4782 は 2021 年 6 月 10 日に起票され、4 年以上放置されていた。

#11546 MS OS 互換 ID 応答の長さを処理する（4 行追加、1 行削除）。ホストはこの記述子を取得する際に任意の wLength を指定できる。元の実装は wLength に従って EP0 転送を構成するため、既に構築された記述子バッファの外側の内容を送信してしまう可能性がある。修正方法は、応答長を実際に構築された記述子サイズにクランプすることであり、割り当てとキャッシュの挙動は変更しない。対応する欠陥 #11287 は 2026 年 3 月 23 日に開かれた。

両方の提案は 2026 年 7 月 1 日に開かれ、同日にマージキューに入った。作者は提案の中で、検証は git diff --check と改行コードのチェックのみを行い、ビルドと USB device utest は実行していないと正直に明記している。その理由は、手元の Windows マシンに scons、C コンパイラ、組み込みクロスツールチェーンがないためである。この点は記録に値する。両方の変更は大きくないが、USB 記述子パスには自動テストのカバレッジがなく、マージ時の信頼は主にコードレビューに由来している。

1.2 SDHCI ホスト初期化の 32 バイト名バッファ、RT_NAME_MAX を 64 にするとスタックを踏む（11-02）

日付：2026-11-02 11:24（マージ時間）　情報源：提案 #11542

6 行追加、4 行削除、SDHCI ドライバの dev_sdhci.c に該当する。故障現象は、qemu-virt64-aarch64 上で SDHCI を有効にし、RT_NAME_MAX を 64 に設定すると、起動過程で直接 data abort し、fault addr 0x228 となることである。

根本原因はローカルバッファが 32 バイトに固定されていることである：char dev_name[32]。一方、sdio_host_set_name() はカーネルオブジェクトの命名規則に従って最大 RT_NAME_MAX 文字を書き込む。名前が 32 バイトを満たした後、続く 2 行 rt_sprintf(&dev_name[len], "-timer") と -data-timer がさらに後ろへ書き込み、スタック上にオーバーフローする。名前の長さが 32 を超えると、越境は「可能性」から「必然」に変わる。

修正方法は、バッファを char dev_name[RT_NAME_MAX] に変更し、sdio_host_set_name() の戻り値の後に dev_name[sizeof(dev_name) - 1] = '\0' を一度補ってから長さを再計算し、2 箇所のサフィックス連結を rt_sprintf から残り長さパラメータ付きの rt_snprintf に置き換える。これにより、RT_NAME_MAX が 64 や 128 に設定されても、名前とサフィックスの合計長はバッファ自身で吸収される。

同じ形状の問題は RT-Thread では珍しくない。カーネルは RT_NAME_MAX の設定を許可しているが、ドライバ内で小さなバッファを固定で持つ箇所は少なくない。この件は、コンテスト作品のボードが QEMU 上で SD カード初期化まで進んだ際に露見したものであり、RT_NAME_MAX がデフォルト以外の値となる組み合わせは普段テストされていないことを示している。

1.3 klibc のバイトループが GCC に memset と認識され、libc なしターゲットでリンク失敗（11-02）

日付：2026-11-02 18:08（マージ時間）　情報源：提案 #11965、欠陥 #6128

13 行追加、1 行削除、src/klibc/SConscript のみを変更し、C ソースコードには一切触れていない。

kstring.c 内の rt_memset()、rt_memcpy()、rt_memmove() はいずれもバイト単位のループで終わる。GCC は -O2 と -Os で -ftree-loop-distribute-patterns を有効にし、この種のループを標準ライブラリ呼び出しとして認識し、memset、memcpy への参照に書き換える。ターゲットプラットフォームに C ライブラリがなければ、これらのシンボルは存在せず、ファームウェアはリンク段階で失敗し、一連の undefined reference が報告されるが、文字列実装に関係するとは分からない。

作者は arm-none-eabi-gcc 10.3.1 を用い、QEMU の vexpress-a9 ボードプロジェクトで -Os により再現した。変更前の klibc の kstring.o 内に U memset が現れ、しかも 2 箇所の bl 0 <memset> が rt_memset() 自身の内部に位置していた——カーネル自身の memset が存在しない memset を呼び出していたのである。欠陥 #6128 は 2022 年 6 月 30 日に開かれ、最初の報告では aarch64-gcc で rt_memset をコンパイルすると問題があるとだけ述べられていた。

修正方法は、Libc グループに -fno-tree-loop-distribute-patterns を追加し、かつ CROSS_TOOL == 'gcc' の場合にのみ追加することであり、Keil と IAR のビルドには影響しない。代償としてこれらのループはベクトル化や折り畳みの対象外となるが、klibc のこれらの関数は元々ホットパス上にはない。この経験はベアメタル移植を行うチームに普遍性がある。自前実装の文字列関数とコンパイラ最適化オプションの間には暗黙の契約が存在し、ツールチェーンのアップグレード時に最も破られやすい。

1.4 tiny vsnprintf が long long を long として扱い、INT64_MAX が -1 と表示される（11-02）

日時：2026-11-02 16:25（マージ時間）　情報源：提案 #11600

20 行追加、3 行削除、rt_vsnprintf_tiny.c と対応するテストを変更。tiny バージョンはスペース節約のため %lld と %lli の ll 修飾子を long パスに統合して処理していた。その結果、64 ビット整数が 32 ビットで切り捨てられ、符号判定もずれてしまう――最も直感的な現象は INT64_MAX が -1 と表示されることである。

修正では内部の L（ll を表す）と l の 2 つの符号付き分岐を分離した。ll は long long として引数を取得し、64 ビット範囲で符号を判定し、l は long パスを維持する。同時に rt_sprintf の境界値回帰テストケースを追加し、INT32_MIN、UINT32_MAX、INT64_MIN、INT64_MAX の 4 値をカバーした。

検証構成は qemu-vexpress-a9 に tiny バージョンの long long サポートオプション（VSNPRINTF_LONGLONG、標準 vsnprintf は無効）を加えたもの。提案は 2026 年 7 月 9 日に作成され、キューに約 4 か月間置かれていた。tiny バージョンは多くのリソース制約プロジェクトのデフォルト選択であり、この種のサイレント切り捨てはログ出力やタイムスタンプのフォーマット時に発見しにくい。

1.5 SCMI リセットコントローラが誤ったコンテナを取得、ドライバ登録順もサブシステム初期化に変更（11-02）

日時：2026-11-02 18:20（マージ時間）　情報源：提案 #11946

22 行追加、7 行削除、reset-scmi.c と pm-domain-scmi.c の 2 ファイルを変更。本調査期間最後のプッシュである。

リセット側の問題は、コンテナ変換で誤ったオブジェクトを使用していたことである。scmi_reset_reset()、assert()、deassert() およびデバイスツリー解析関数はいずれも raw_to_scmi_reset(rstc) と記述し、rt_reset_control ポインタを SCMI リセットコントローラとして逆算していた。正しい方法は rstc->rstcer を経由し、まずリセットコントローラを取得してから変換することである。誤ったポインタを渡した結果はクラッシュではなく、ずれたフィールドを読み取ることになり、その挙動はメモリレイアウトに依存する。そのためこの種のエラーは、特定のボードで「リセットが効かない」という現象が出るまで発見されないことが多い。

登録側では、2 つのドライバが元々 RT_SCMI_DRIVER_EXPORT を使用していたが、明示的な登録関数と INIT_SUBSYS_EXPORT に変更された。2 つのエクスポートマクロの違いは登録タイミングである。ドライバはリセットおよび電源ドメイン基盤の準備完了後に登録する必要があり、そうでなければコンシューマが先に probe してプロバイダを取得できなくなる。提案の説明ではさらに、デバイスツリーから解析した reset domain ID で属性を検索すること、およびリセットコントローラインスタンス内に SCMI デバイス参照を保持してコントローラのライフサイクルがデバイスより短くなるのを防ぐことにも言及している。

1.6 X/Y/Z バージョンルールがドキュメントレビューに入り、Z バージョン向け QEMU テストリストも同時に公開（11-02 ~ 11-03）

日時：2026-11-02 15:24（リスト）/ 2026-11-03 07:23（ドキュメント更新）　情報源：提案 #11955、欠陥 #11972、提案 #11974、提案 #11976

前号で報じたバージョン管理提案 #11955 が調査期間末に再度更新され（11-03 07:23）、ドキュメント内容は具体化された。X/Y/Z の 3 段階バージョン番号の判定ルール、Y バージョン周期 3～6 か月、Z バージョン周期 1 か月、各レベルのリリース責任と互換性要件などである。まだレビュー中で、未マージである。

付随する実行リストは CYFS3 が 11-02 15:24 に欠陥 #11972 として公開した。タイトルは非常に率直で――Z バージョンのリリースに向けた CI 自動テストである。核心的な考え方は「QEMU のエミュレートデバイスで実ハードウェアを代替する」ことである。マイクを例にすると、仮想 ops を 1 組登録してエミュレートマイクを作るだけで、フレームワークインターフェースの入力を網羅的にテストでき、ボードを待つ必要はない。リストはフレームワークごとに utest と QEMU 両側の現状を項目別に列挙している。SPI にはループバックテスト、PWM には周波数とデューティ比のテスト、RTC にはアラームテスト、audio にはファームウェア内のエミュレートマイクとプレーヤーおよび DMA コールバックが既にあり、adc と dac のフレームワークテストは補充中（#11974 と #11976 に対応）であり、i2c、can、watchdog、touch、usb、sdio、flash、ethernet の QEMU 側はほぼ空白である。

このチェックリストの価値は、「Z バージョンをリリースできるかどうか」をメンテナの主観的判断からチェック可能な表へと変える点にある。これは #11955 と一組のものの両半であり、半分がルールを定め、半分が証拠を提供する。締め切り時点で #11972 には 6 件のコメントがあり、adc と dac の 2 つの utest 提案はすでに提示されているが未マージである。

2. セキュリティフォローアップとマージ待ちキュー

2.1 グラフィックデバイスの負オフセット：pread と pwrite が位置検証を迂回し、カーネルの任意読み書きに直結（11-02）

日付：2026-11-02 12:01（報告時間）　情報源：欠陥 #11969、提案 #11970

報告者は XueDugu で、照合ベースラインは当日の master 08cad4ee。影響範囲は明確に書かれている：v5.3.0 から現在の master まで、欠陥は 2025-12-12 のコミット 5abecc1fd0c3 によって導入され、現在の graphic.c の blob は 14de5a6c である。

_graphic_read() と _graphic_write() は符号付きのデバイスオフセットを受け取るが、pos >= 0 を検査せず、pos < framebuffer_len も検査しない。残り長は rt_min_t(rt_ssize_t, plane->framebuffer_len - pos, size) で計算される：pos が負の場合 framebuffer_len - pos は大きな正数になり、res はそのまま size を取る。その後 rt_memcpy(plane->framebuffer + pos, buffer, res) がフレームバッファの前または後ろで読み書きする。

入口は RT-Smart の pread64() と pwrite64() にある。現在の rw_verify_area() は count >= -pos のときのみ負の位置を拒否するため、count=8、pos=-210456 のような組み合わせが検証を通過し、そのままドライバに到達する。報告は二層の検証を示している：qemu-virt64-aarch64 に QEMU 付属の ramfb デバイスを組み合わせ、ユーザー空間からカーネルへの越境パスを証明；Raspberry Pi Pico 2 W（RP2350）は USB CDC 経由で、ボードレベルのカーネル API プリミティブ自体を検証。

修正提案 #11970 は 31 分後に提示された（12:32）。作者は usualtreee で、10 行追加、graphic.c の 1 ファイルのみ変更：2 つの関数は残り長を計算する前にまず pos を判定し、負の値と framebuffer_len 以上の位置は直接 0 を返し、正当な読み書きのフロントトリム動作は変わらない。これは本調査期間で最も速い対応である——報告からパッチまで半時間だが、パッチはまだマージされていない。

2.2 pipe のパッチは当日到着、ドライバ側でコマンドごとに自衛する形に変更（11-02）

日付：2026-11-02 15:23（提案時間）　情報源：提案 #11971、欠陥 #11958

前号で報じた pipe の FIONREAD 欠陥にパッチが到着した。22 行追加、4 行削除、pipe_fops_ioctl があるファイルのみ変更。

変更方法は、リングバッファのデータ長または残り空間をまずスタック上の int に計算し、MMU ビルドでは lwp_put_to_user() でユーザーアドレスにコピーして戻し、非 MMU ビルドでは直接書き込みを維持する——単一アドレス空間では分離などあり得ず、この層を増やすとむしろ互換性を壊す。併せて pipe と pipe->fifo の NULL チェックを補い、lwp_user_mm.h の include を ARCH_MM_MMU で囲んだ。

提案には、なぜ sys_ioctl() で一括して阻止しないかの説明がある：ioctl の意味はドライバによって異なり、スカラー引数のものもあれば構造体ポインタのものもあり、グローバル検証は誤爆しやすい。コマンドごとにドライバ側で自衛する方が適切である。この取捨は記録に値する：前号では pipe、ブロックデバイス、端末の 3 箇所を同一成因に帰したが、統一入口が唯一解ではなく、代償は各ドライバが自分でやることを覚えておく必要があることだ。

2.3 メンテナ自身が 2 件の旧提案を再作成：getaddrinfo と GPT パーティションテーブル（11-03）

日付：2026-11-03 00:08 / 07:18（提案時間）　情報源：提案 #11977、提案 #11978

2 件とも BernardXiong がコミットし、提案本文の最初の文にはいずれも「これは #xxxx の再作成である（元 PR はコンフリクトし古くなっている）」と書かれている。

#11977 は #11454 をやり直し、sys_getaddrinfo() のユーザーポインタ処理を堅牢化（57 行追加、17 行削除）。元の実装は最上位の res バッファのみを検証し、その後 res->ai_addr というユーザーが制御可能なネストポインタ経由で解析結果を書き込んでいたため、Smart/MMU ビルドでは任意のカーネル書き込みに等しかった。hints のフィールドも最上位検証後は引き続きユーザーメモリから読み取られ、TOCTOU ウィンドウが存在した。新しい実装では lwp_get_from_user() で res と hints を一度にカーネルの一時構造体へコピーし、以降のすべてのネストポインタはこのスナップショットに由来する。ネストした sockaddr と外側の構造体は統一的に lwp_put_to_user() で書き戻す。ついでに servname コピーの戻り値判定も修正した——元のコードは size_t と 0 を比較しており、常に偽であった。

#11978 は #11275 をやり直し、GPT パーティションテーブルの先頭と末尾の逆転を修正（11 行追加、5 行削除、efi.c のみ変更）。is_pte_valid() は starting_lba と ending_lba がともにディスク範囲内にあることのみを要求し、ending_lba >= starting_lba を検査していなかった。CRC が正当な GPT イメージを構築すれば、size = ending_lba - starting_lba + 1ULL に符号なしアンダーフローが発生し、巨大なパーティションサイズを得て論理パーティションとして登録できてしまう。修正方法は検証関数に end < start の判定を追加し、start と size の計算を合法性チェックの後に移動して、検証済みの start で size を計算する。対応する欠陥は #11271、元の提案 #11275 は 11-03 07:20 にクローズ済み。

この 2 件を合わせて見ると、修正方法そのものよりもシグナルの方が重要である。外部報告者が提出したパッチが古くコンフリクトすると、メンテナは作者の rebase を待たずに自分でやり直し始める。これは 2.1、2.2 の迅速なパッチと同じ事象の両面である——キューが動いている。

2.4 キューにはまだ 5 件が滞留：cromfs ディレクトリ名、poll カウント、9pfs 長さ、DHCP プール枯渇、signalfd（10-21 ~ 11-03）

日付：2026-10-21 ~ 2026-11-03（提案時間と最終更新）　情報源：提案 #11911、提案 #11954、提案 #11918、提案 #11947、提案 #11935

#11911 は cromfs のディレクトリ名読み取り（421 行追加、116 行削除、7 ファイル、11-03 07:50 時点でも更新中）。dfs_cromfs_getdents() はイメージ内の uint16 name_size をそのまま memcpy の長さとして d_name へコピーし、DIRENT_NAME_MAX（256）との比較も、名前が直前にロードしたディレクトリ blob 内に収まるかの検証も行わない。さらに直後の行で NUL を name_size の位置に書き込むため、name_size が 256 に達すると元のコード自体が 1 バイト余分に越境する。呼び出し側も同様に切り詰めない——msh の ls() は struct dirent をシェルスレッドのスタックに置き、getdents には 1 エントリだけを要求するため、超長いディレクトリ名が上書きするのはシェルスレッドのスタックである。

#11954 は poll と epoll のカウント乗算ラップアラウンド（166 行追加、11-03 07:24 更新、規模は前回記録時から約 6 倍に拡大）。sys_poll() はユーザー指定の数を基にカーネルバッファサイズを計算するが、32 ビットでは積がラップアラウンドしてもその後も元の数で走査する。nfds が 0x20000001、pollfd が 8 バイトの場合、積は 8 に切り詰められ、検証と割り当ては 8 バイトで通過するが、poll() は 5.3 億項目を走査する。

#11918 は 9pfs クライアントがサーバー指定の長さを信頼する問題（66 行追加、6 行削除）。p9_transaction() の返却バイト数は破棄され、解析時には報文中の count、stat_size、name_len を直接使用する。「count は巨大だが実際は非常に短い」レスポンスを構築すれば、受信バッファを突き抜けて読み取り続け、実測で 8.3 MB を越え、ASAN は use-after-poison を報告し、同時にディレクトリ情報も漏洩する。

#11947 は DHCP アドレスプール枯渇後の無制限探索（19 行追加、5 行削除）。dhcp_client_alloc() は候補アドレスが使用中の場合に goto で探索を続け、回数を制限しない。プールが満杯になると、新しい MAC の DISCOVER によって lwIP 受信パス内で永久ループし、後続の報文がすべて詰まる。修正方法はそのラウンドの最初の候補を記録し、起点に戻ったら停止し、プール満杯時は NULL を返す。

#11935 は signalfd_close のリスナー摘除（91 行追加、35 行削除）。元の実装はグローバルインデックスカウントで通知を登録し、クローズ時にチェーンから摘除せず、解放もしないため、ダングリングノードが残っていた。改修では登録スロットの数量上限による境界探索に変更し、クローズ時に登録済み lwp を走査して対応ノードを通知チェーンから摘除して解放し、同時にファイルコンテキストポインタをクリアする。

五筆の共通点は依然として古い問題である。長さ、カウント、インデックスがユーザー空間または対向側から来ており、カーネルロジックに入る前に検証層がない。違いは、現在は各筆に対応する提案があり、その大半に QEMU 上での再現手順が付いていることだ。

3. 公式・コミュニティ活動

3.1 上海オープンソースソフトウェア応用イノベーションコンテスト閉幕、睿赛德は 12 の産業課題の出題者の一つ（10-29 ~ 10-30、11-02 公式発表）

日付：2026-11-02（公式発表）/ 2026-10-29 ~ 10-30（イベント）　情報源：上海市経信委：コンテスト閉幕、人民網：より多くのオープンソース成果を競技場から市場へ

2026 上海オープンソースソフトウェア応用イノベーションコンテスト決勝戦兼イノベーション成長大会は 10 月 29 日から 30 日まで上海張江人工知能イノベーションタウンで開催され、オープンソース中国が主催した。8 月 5 日の応募開始以来 766 の応募プロジェクトを受け付け、40 社余りの協力企業とオープンソースコミュニティが参加した。12 の実際の産業課題には 269 のプロジェクトが応募し、30 チームが決勝戦に進出して総額 100 万元の賞金プールを争った。

12 の課題の出題者の中で、睿赛德（RT-Thread）は中国商飛、中船海舟、道客、云轴科技、魔珐科技とともに上海地元企業側に並び、もう一方には百度地図、openKylin コミュニティ、open-supOS コミュニティなどの全国的な技術企業・コミュニティが名を連ねる。RT-Thread にとってこの位置の意味は「産業・組込みシーンが実際の産業問題の源泉として扱われている」ことであり、スポンサー枠ではない。

10 月 30 日の授賞式で、オープンソース中国は正式に上海に拠点を置くことを発表し、コンテストブランドは上海のオープンソース・人工知能分野の年間イベントにアップグレードされ、今年から毎年開催される。30 の決勝チームのプロジェクトは産業シミュレーション、計算力スケジューリングと推論加速、エージェントセキュリティガバナンス、エンボディドインテリジェンスのデータ品質検査、ライフサイエンス計算をカバーし、うち上海の大学、企業、オープンソースコミュニティのチームが約 3 分の 1 を占めた。

3.2 RT-Thread と NXP のユーザーアンケート開始、NXP 適配面はすでに MCX A366 と A156 まで列挙（11-02）

日付：2026-11-02 17:30（発表）　情報源：電子工程専輯：RT-Thread と NXP のアンケート活動

RT-Thread 公式コラムが NXP との共同ユーザー調査を発表した。活動期間は 11 月 2 日から 11 月 23 日まで、11 月 24 日に抽選が行われる。記事冒頭では協力範囲が具体的に記されており、MCX N947、MCX A366、MCX A156 など複数のチップにすでに対応済みである。アンケートでは端末機器、応用シーン、開発上の課題の記入を求め、チップ性能、ペリフェラル、エコシステム適配に関する改善提案も歓迎している。

この記事自体はコミュニティ運営の動きだが、開示された適配リストには価値がある。MCX A シリーズは NXP がここ 2 年主推する汎用 MCU ラインであり、A366 と A156 が適配リストに現れたことは、RT-Thread の NXP 製品ラインにおけるカバレッジが N947 のような NPU 搭載モデルから汎用モデルへと広がっていることを示す。前号で報じた NXP i.MX RT1180 産業イーサネットリンカスクリプト提案（#11959）は依然としてキューにあり、二つのラインを対照的に見ることができる。一つは MCU 側の広さ、もう一つはクロスオーバープロセッサ側の深さである。

3.3 公式ニュースインターフェースは依然 6 月 17 日で停止、発表の出口は引き続きメディアコラムに（11-03）

日付：2026-11-03（確認）　情報源：RT-Thread 公式ニュースリスト

公式ニュースインターフェース getList?type=rt_org が返す最新エントリは依然として 2026-06-17 の「睿赛德科技、2026 アブダビ投資フォーラムへの招待出席」であり、公式サイトトップのニュース欄も同様に 6 月で停止しており、今号は新規追加なし。これでこのインターフェースは 6 か月連続で更新なしとなった。

発表側の実際の出口はメディアコラムにある。今号の調査期間内に電子工程専輯の RT-Thread 公式コラムが 1 本更新され（11-02 の NXP アンケート）、もう 1 本の 11-01 のダブルイレブン販促稿は収録されていない。フォーラム側の club.rt-thread.org は依然として 468 を返し、前置された WAF チャレンジページにより、リストと本文を直接読み取ることができず、コミュニティ動向は GitHub とメディアコラムのクロスチェックに頼るしかない。

4. エコシステムとベンダー適配

4.1 先楫半導体が一度に 12 の BSP リポジトリを v1.13.0 へ更新、さらに HPM5100EVK を新規開設（11-02）

日付：2026-11-02 11:43 〜 11:56（プッシュ時刻）　情報源：リポジトリ：rtt-bsp-hpm5100evk、リポジトリ：rtt-bsp-hpm6800evk、リポジトリ：rtt-bsp-hpm6e00evk

先楫半導体（HPMicro）の GitHub 組織下にある 64 のリポジトリのうち、12 の RT-Thread BSP リポジトリが 11 月 2 日 11:43 から 11:56 までの 13 分間に集中プッシュされた：HPM6750EVK、HPM6750EVK2、HPM6750EVKMINI、HPM6E00EVK、HPM6P00EVK、HPM6800EVK、HPM6300EVK、HPM6200EVK、HPM5E00EVK、HPM5300EVK、HPM5301EVKLITE、そして新規開設の HPM5100EVK。

リポジトリごとに確認したコミット情報は一致している：HPM5100EVK、HPM6800EVK、HPM6E00EVK の三箇所はいずれも「RT-Thread BSP v1.13.0 for <ボード名>」で、タイムスタンプは同一の秒単位区間に収まっており、個別開発ではなくスクリプト化されたバッチリリースと判断される。HPM6800EVK と HPM6E00EVK の直前のコミットはそれぞれ 2026-02-03 の v1.11.0 で、今回のコミットまで約 9 ヶ月の間隔があり、その間に v1.12.0 のコミット記録はない。

HPM5100EVK は新規リポジトリ（11-02 10:59 作成）で、最初のコミットがすなわち v1.13.0 であり、README には RT-Thread Studio BSP と明記され、付属サンプルには adc、blink_led、flashdb、mcan、pwm、spi_nor_flash_fs、timer、uart_dma、usb_device_generic_hid、usb_host_msc_udisk が含まれる。サンプル一覧からこのボードの位置づけが読み取れる：CAN と USB のデュアルロール、ファイルシステムと FlashDB がいずれもデフォルトの対象範囲にあり、産業用途やデータ記録シーンに寄っている。

チップ原廠が BSP を独立リポジトリに分割し、Studio プロジェクト単位で保守するのは RT-Thread エコシステムにおけるここ 2 年の常態である（兆易、意法、ルネサスも同様に行っている）。特筆すべきはリリースのリズムで、12 のリポジトリが同日同バージョンであることは、先楫の内部に SDK から各ボード BSP までの同期スクリプトが存在することを示しており、リポジトリごとに手動でマージするよりもボード間の一貫性を保証しやすい。

4.2 AWTK メインラインは平常通りイテレーション、今回のコミットは RT-Thread との特段の関連なし（11-02）

日付：2026-11-02 17:42（プッシュ時刻）　情報源：リポジトリ：zlgopen/awtk

志遠電子の AWTK（3325 スター）に期間内のプッシュが 1 回あり、直近 3 コミットのタイトルはいずれも「improve edit」で、汎用 GUI フレームワークの日常的なイテレーションに属し、RT-Thread 専用の変更は見られない。当該リポジトリは topic:rt-thread タグを持ち、長期的に RT-Thread BSP をサポートしているためエコシステム観察の対象として挙げるが、今回は項目として展開しない。

5. 業界アプリケーション

5.1 産業ゲートウェイのオープンソース：FreeModbus マスター、LVGL パネル、4G クラウド接続、HTTP OTA を 1 つのイメージに統合（11-02）

日付：2026-11-02 13:59（リポジトリ作成）　情報源：リポジトリ：rtthread-industrial-gateway

新規作成された個人プロジェクトで、産業データゲートウェイの 4 つの経路を同一の STM32F407VGT6 上に実装している：下り方向は FreeModbus を RTU マスターとして用い、現場スレーブの保持レジスタを周期的にポーリングする；ローカルは LVGL 8.3 で HMI を構成し、ボタン制御と読み戻しが 1 つの保持レジスタミラーテーブルを共有する；上り方向は ML307 4G モジュールを介して MQTT QoS1 で ThingsBoard に接続し、RPC による逆方向制御をサポートする；リモートアップグレードは HTTP のチャンクダウンロードと CRC32 検証を用い、download パーティションに書き込んだ後、rtboot が app パーティションへ移動させてからジャンプする。

ハードウェア構成は同種のリポジトリの多くより詳細に書かれている：FSMC 8080 パラレル 16 ビット TFT、xpt2046 抵抗膜タッチパネルは SPI 接続、W25Q128（16 MB）は SPI1 に接続しチップセレクトは PG15 のソフトウェア制御、ML307 は uart6 で AT コマンドを使用、Modbus スレーブは uart3 の 9600 8N1 に接続。プロジェクトは 9 つの段階を踏んで段階的に進み、最終段階で 4 つの経路を同一のイメージに統合する。

この組み合わせの意義は「全経路がボード側にある」ことにある：多くのゲートウェイプロジェクトはクラウド接続を外付けモジュールや 2 つ目の MCU に任せるが、このプロジェクトは 4G、プロトコル変換、HMI、OTA を 1 つの M4F に押し込んでおり、その代償として 192 KB の SRAM に LVGL バッファ、Modbus フレーム、MQTT セッションを同時に収めなければならない。産業ゲートウェイの選定を行うチームにとって、このリポジトリのディレクトリ構造とパーティション分割は完成品以上に参考価値がある。

5.2 Sifli SF32LB52 スマートウォッチファームウェア、RT-Thread をウェアラブル基盤に載せる（11-02）

日付：2026-11-02 18:03（プッシュ時間）　情報源：リポジトリ：helios-sf32

OpenSifli SDK をベースにしたスマートウォッチファームウェアで、ターゲットボードは思澈（Sifli）SF32LB52 開発ボードの LCD 画面、UI は LVGL、基盤は RT-Thread。リポジトリは 9 月 4 日に作成され、調査期間内に 1 回のプッシュがあり、現在 5 スター 1 フォーク。

ウェアラブルは RT-Thread にとって比較的珍しい用途である。この種の製品の制約は産業用ボードとは逆で、画面リフレッシュは滑らかに、待機消費電力は低く、UI リソースはホットアップデート可能であることが求められる。RT-Thread のこの分野での強みは、コンポーネントの取捨選択が可能なことと、LVGL との成熟したバインディングである。OpenSifli SDK が RT-Thread をデフォルト RTOS としていることは、思澈のこの製品ラインが SDK 層で基盤を選定済みであることを示し、サードパーティのファームウェアプロジェクトはそれをそのまま継承できる。

6. 今期のトレンドと総括

6.1 トレンド：1 日 6 件のマージはすべて積み残し、セキュリティキューはメンテナが引き継ぎ始める

今期の 24 時間でメインリポジトリには 6 件がマージされ、すべて 11 月 2 日 11:24 から 18:20 に集中している。数は多くないが、構成は非常に偏っている。4 件の提案はすべて 2026 年 7 月 1 日に起票され（#11542、#11545、#11546 は当日コミット、#11600 は 7 月 9 日）、1 件は 2022 年 6 月の不具合 #6128 に、1 件は 2021 年 6 月の不具合 #4782 に対応する。つまり、この日に片付けたのは滞留分であり、新規作業ではない。

第一の線は「設定の組み合わせで現れる隠れた不具合」である。#11542 の SDHCI スタックオーバーフローは RT_NAME_MAX を 64 に設定しないと発生せず、#11600 の long long 切り捨ては tiny vsnprintf を有効にしないと現れず、#11965 のリンク失敗はターゲットプラットフォームに C ライブラリがない場合にのみ露呈する。三者に共通するのは、デフォルト設定では検出できないという点であり、まさにこうした非デフォルトの組み合わせが実プロジェクトでは最もよくある——チップを変える、ツールチェーンを変える、Flash を少し節約する、といっただけで踏んでしまう。

第二の線は RT-Smart とデバイス境界の清算が第二段階に入ったことである。前回の判断は「報告が多く、パッチが少ない」だったが、今期の変化はパッチが追いつき始め、対応も速くなったことである：グラフィックスデバイスの負のオフセットは報告から提案まで 31 分（#11969 から #11970）、pipe のパッチは当日に到着（#11971 は前回の #11958 に対応）、メンテナ本人が getaddrinfo と GPT の 2 件の古い提案を作り直した（#11977、#11978）。キューにはまだ 5 件が審査中だが、いずれも再現手順があり、レビューコストはすでに低下している。

第三の線はバージョンガバナンスが「計画」から「証拠」へ進んだことである。#11955 は X/Y/Z の周期と責務をドキュメント化し、#11972 は Z バージョンをリリースできるかどうかを QEMU 仮想デバイスと utest のフレームワーク別リストに分解し、adc と dac の模擬デバイステストにまで提案を付けている。この 2 件はいずれもカーネルを変更しないが、今後の各 Z バージョンリリース時の判断根拠を決めるものである——前回述べた「手作業で整理する工程を検査可能なフローに変える」が、今期はリストとして具体化した形だ。

エコシステム側の動きはより直接的である。先楫半導体は 13 分以内に 12 の BSP リポジトリを v1.13.0 にプッシュし、新たに HPM5100EVK を開設した。これは原廠側の BSP メンテナンスがすでにスクリプト化されていることを示す。コミュニティ側では Modbus、LVGL、4G、OTA をすべて 1 颗の M4F に載せた産業用ゲートウェイプロジェクトが現れた。一方はメーカーがボード間の一貫性を保証し、他方は開発者がコンポーネントを極限まで組み合わせる。この両端こそ、RT-Thread の現在最も現実的なエコシステムの姿である。

6.2 限界と重複排除の説明

フォーラム club.rt-thread.org は今期も 468 を返し WAF チャレンジページを前置しており、スレッド一覧と本文を直接読むことができない。コミュニティ討論側の情報欠落は GitHub とメディアコラムで補完し、スレッド単位の照合は行っていない。公式ニュース API と公式サイトのニュース一覧はいずれも 6 月 17 日で止まっており、リリース側の情報はメディアコラムに依拠するほかない。

Google News の英語側 2 組のクエリはゼロヒット、中国語側 3 組は結果あり：上海オープンソースコンテスト（収録）、恩智浦アンケート（収録）、智东西による安謀科技極術コミュニティのロボット犬に関する記事（本文に RT-Thread の具体的な技術内容がなく、未収録）。他に 11-01 のダブルイレブン販促記事があるが、期間外かつプロモーション内容のため未収録。HN Algolia では調査期間内に RT-Thread 関連のヒットはなかった。

GitHub 側は今期、匿名 API のレート制限（毎時 60 回）の影響を受けた。メインリポジトリのコミット、提案、不具合の明細はすべて取得済み。先楫の 12 リポジトリのバージョン番号は HTML と Atom のコミットフィードで交叉確認し、うち 3 箇所はコミット情報が v1.13.0 であることを確認、残り 9 箇所は同一タイムスタンプ区間から同一バッチのリリースと判定し、リポジトリごとのコミット本文取得は行っていない。前回審査待ちキューに入れた #11897（K230D）、#11892（RISC-V Smart MMU）、#11944（RTL8125）、#11943（RK3588 ディスプレイオーディオ）、#11959（NXP RT1180 リンクスクリプト）は今期もキューに残り、マージされていないため重複計上せず、#11954 と #11958 は前回既報のため、今期は更新とパッチの進展のみを記す。

付録：情報源チェック表と情報源リスト

情報源チェック表

情報源 調査結果
公式ニュースインターフェース（rt_org） 24時間新規なし、最新項目は2026-06-17で停止
公式サイトニュース一覧 トップページのニュース欄は依然6月のまま、新規記事なし
コミュニティ記事インターフェース サイト前面のWAFチャレンジページ（HTTP 468）、一覧と本文が読み取り不能
メインリポジトリ commits 調査期間内に6件、11-02 11:24 ~ 18:20に集中
メインリポジトリ PR マージ6件（#11542、#11545、#11546、#11600、#11965、#11946）；新規作成と審査中が十数件、#11970、#11971、#11974、#11976、#11977、#11978を含む
メインリポジトリ Issue 新規1件（#11969 グラフィックス負オフセット）；#11972 リストが同日公開され更新
メインリポジトリ releases と tags 新規なし、最新は依然 v5.3.0（2026-09-10）
RT-Thread org（35リポジトリ） メインリポジトリのみ調査期間内にプッシュ、その他のリポジトリは静か
先楫半導体 org（64リポジトリ） 12個のRT-Thread BSPリポジトリが同日 v1.13.0 をプッシュ、HPM5100EVKを新規開設
GitHub リポジトリ検索（rt-thread） 調査期間内に新規2件（産業ゲートウェイ、HPM5100EVK BSP）、topicプッシュ4件
Google News 中国語 3件ヒット、2件収録（上海オープンソースコンテスト、NXPアンケート）
Google News 英語 ヒットゼロ
HN Algolia RT-Thread関連のヒットなし
電子工程専輯公式コラム 調査期間内に1件（11-02 NXPアンケート）、収録済み
上海市経信委ウェブサイト 11-02にコンテスト総括を発表、収録済み

完全な情報源リスト