Окно мониторинга: 2026-11-05 08:00 ~ 2026-11-06 08:00 (пекинское время, 24 часа)

Источники: официальный новостной интерфейс RT-Thread и список новостей на официальном сайте, коммиты / PR / Issue / releases / tags основного репозитория на GitHub, список пушей репозиториев организации RT-Thread (в этом выпуске были пуши в репозитории env и sdk), четыре группы запросов Google News на китайском и английском (через прокси), официальная колонка RT-Thread в EE Times China, форум club.rt-thread.org (в этом выпуске по-прежнему ограничен WAF сайта)

Индекс выпуска

    1. Динамика ядра и версий
      • Конфигурация ARM вынесена из общего Kconfig: libcpu начинает разделяться по архитектурам (11-05)
      • MMU и пользовательские исключения RISC-V Smart: исправлены четыре первопричины (11-05)
      • Доставка сигналов больше не спит с удержанием блокировки, исправлен порядок защиты сегментов ELF (11-05)
      • Семь коммитов по драйверам и инструментам: SDIO, последовательный порт, virtio, NVMe, HID, mkdist (11-05)
    1. Сопровождение безопасности и очередь на слияние
      • ivshmem считает конфигурационное слово устройства доверенным вводом, узел /dev стал каналом произвольной физической памяти (11-06)
      • Исправление через два часа одиннадцать минут: новый параметр запирает откат JailHouse в клетку (11-06)
      • Проверка MSI-X из ожидания в слияние: вчерашняя находка сегодня реализована (11-05)
      • Одиннадцать исправлений выхода за границы и проверки параметров за один день (11-05)
      • Очередь: сорок восемь обновлений ожидают проверки, коммит по разделам блочных устройств всё ещё висит (11-05)
    1. Официальные и общественные мероприятия
      • Titan Board подключена к OpenMV: 170 примеров на Python, NPU через TFLM (11-05)
      • Маркетплейс плагинов Env стал бессерверным индексом: пакеты плагинов помещаются в GitHub Release (11-06)
      • Официальный новостной интерфейс всё ещё на июне, форум всё ещё 468 (11-06)
    1. Экосистема и адаптация производителей
      • Предварительно собранные образы ESP32-C3 отклоняют чипы v1.x: поле минимальной версии не согласовано (11-05)
      • Пять коммитов по BSP и тестовой инфраструктуре: D1s в QEMU, efm32 в menuconfig, тесты трёх фреймворков (11-05)
    1. Тренды выпуска и итоги
      • Тридцать один коммит за день: расчистка накопившихся задач вместо постепенного продвижения
      • Тренд: ввод со стороны устройств становится вторым основным фронтом
      • Ограничения и примечание о дедупликации

1. Динамика ядра и версий

1.1 Конфигурация ARM вынесена из общего Kconfig: libcpu начинает разделяться по архитектурам (11-05)

Дата: 2026-11-05 22:26 (время слияния)　Источник: предложение #11988, вопрос #9187

267 добавленных строк, 173 удалённых, три файла: добавлен libcpu/arm/Kconfig, связанные с ARM архитектурные идентификаторы, модели ядра, конфигурации ARM MMU/MPU и GIC из прежнего libcpu/Kconfig целиком перенесены в каталог архитектуры, на прежнем месте подключены через rsource; общие возможности и межархитектурный KERNEL_VADDR_START остались в исходном файле. Автор zijunteng238-dot создал предложение в 11:51 утра, слияние состоялось в 22:26 вечера, весь путь занял десять с половиной часов.

Такой подход заслуживает отдельного упоминания: он не добавляет меню, не меняет символы, не меняет значения по умолчанию, не меняет зависимости и отношения select, а только переносит. Способ проверки тоже не «скомпилировалось — значит, годится» — автор с помощью Kconfiglib 14.1.0 сравнил все разобранные символы до и после разделения: значения конфигурации, типы, видимость, допустимый диапазон значений, значения по умолчанию и отношения выбора совпали пункт за пунктом; после исключения изменений путей файлов и номеров строк новых предупреждений разбора не появилось; сравнение охватило пять BSP: frdm-k64f (Cortex-M4), qemu-vexpress-a9 (Cortex-A9), renesas/rzt2m_rsk (Cortex-R52), qemu-virt64-aarch64 и qemu-virt64-riscv, а на RISC-V был запущен scons –menuconfig для сравнения вывода меню. Кроме того, в памяти для A9, AArch64 и RISC-V включили SMART и IOREMAP_LATE и сравнили ещё раз, не записывая обратно в файлы конфигурации.

Значение для долгосрочного сопровождения — в структуре: libcpu/Kconfig ранее смешивал общие возможности CPU и конфигурации нескольких архитектур, любое добавление опции архитектурой требовало правки одного и того же файла, вероятность конфликтов и ошибочных изменений росла с числом архитектур. После разделения Kconfig RISC-V и ARM могут развиваться независимо, что лежит на той же линии управления, что и документированный процесс выпуска версий из прошлого выпуска — сначала упорядочить структуру, потом говорить о ритме версий. Дополнительно добавлен documentation/4.tool/scons/libcpu_kconfig_arm_split.md, где объём разделения, обработка зависимостей и результаты проверки записаны в репозиторий, чтобы последующий перенос других архитектур можно было выполнять по этому образцу.

1.2 MMU и пользовательские исключения RISC-V Smart: исправлены четыре первопричины (11-05)

Дата: 2026-11-05 11:15 (время слияния)　Источник: Предложение #11892

109 добавленных строк, 8 удалённых, четыре файла, предложено мейнтейнером BernardXiong, создано 18 октября, слито в текущем выпуске, в процессе прошло 11 построчных ревью. Это самая существенная правка текущего выпуска для RT-Smart на стороне RISC-V.

В изменениях перечислены четыре корневые причины — все они представляют разные стороны одной и той же проблемы. Во-первых, указатель ранней таблицы страниц не преобразовывался с учётом физического смещения ядра, из-за чего дескрипторы таблицы страниц указывали не туда при загрузке ядра по ненулевому физическому адресу. Во-вторых, таблица страниц ядра каждого hart наследовала пользовательские отображения, что фактически оставляло между hart недопустимое адресное пространство. В-третьих, ранняя таблица страниц не очищалась перед включением MMU. И в-четвёртых, самое критичное: необработанное исключение в пользовательском режиме приводило к завершению ядра целиком, а не только текущего процесса — один дикий указатель пользовательского процесса мог обрушить систему.

Соответствующие исправления: добавлен выбор архитектуры XuanTie и опция SVPBMT; указатель ранней таблицы страниц преобразуется с учётом физического смещения ядра; разрешено расширение диапазона MPR ниже базового адреса слинкованного ядра; перед включением MMU выполняется очистка ранней таблицы страниц; удалены элементы пользовательских адресов из таблицы страниц ядра каждого hart; пользовательское исключение завершает только текущий LWP; прерывания остаются включёнными на время отправки пользовательского контекста.

Условия проверки описаны откровенно: BSP использует qemu-virt64-riscv и bsp/k230, конфигурация RT_USING_SMART плюс ARCH_RISCV64, автор локально сборку не запускал по причине отсутствия в окружении инструментальной цепочки RISC-V musleabi, передан на проверку CI. Это та же откровенность, что и в описании проверки правки последовательного порта в прошлом выпуске; направление верное, но поведение во время выполнения на линии RISC-V Smart лучше всё же подстраховать повторным тестированием на реальном оборудовании.

1.3 Доставка сигналов больше не спит с удержанием блокировки, исправлен порядок защиты сегментов ELF (11-05)

Дата: 2026-11-05 11:16 (время слияния)　Источник: Предложение #11895, Предложение #11899

Обе правки относятся к подсистеме lwp, обе слиты BernardXiong. Первая #11895 изменяет пять файлов, 58 добавленных строк, 27 удалённых, включает ассемблерную точку входа lwp_gcc.S на стороне RISC-V, lwp_elf.c и lwp_signal.c, три коммита. Суть — проблема порядка: путь обработки сигналов захватывает спящую блокировку, поэтому должен сохранять возможность планирования; в коде с помощью OPEN_INTERRUPT и CLOSE_INTERRUPT явно включаются и выключаются прерывания на критических участках; одновременно исправлен порядок применения защиты сегментов ELF, чтобы избежать записи перед защитой.

Вторая #11899 меньше: 16 добавленных строк, два файла: sys_sigaction проверяет номер сигнала перед индексацией массива действий, отклоняя значения меньше или равные нулю и превышающие _LWP_NSIG, возвращая EINVAL. Подобные патчи «сначала проверить, потом индексировать» появлялись в последних нескольких выпусках уже не раз и являются продуктом одной и той же волны аудита.

1.4 Семь правок драйверов и инструментов: SDIO, последовательный порт, virtio, NVMe, HID, mkdist (11-05)

Дата: 2026-11-05 (время слияния)　Источник: Предложение #11886, Предложение #11931, Предложение #11726, Предложение #11920, Предложение #11968, Предложение #11873, Предложение #11874

Семь правок среднего масштаба, слитых в одном пакете, по одной строке на каждую:

  • Размер блока SDIO изменён на установку после завершения конфигурации блока, чтобы избежать временной несогласованности, возникающей при установке размера до конфигурации (#11886, 8 строк изменено на 8 строк, три файла).
  • При закрытии файлового дескриптора последовательного порта обратный вызов приёма удаляется только при обнулении счётчика ссылок; общий порт больше не теряет обратный вызов из-за первого закрывающего (#11931, 9 строк добавлено).
  • Сетевой карте virtio добавлено освобождение RX-буфера при неудачном выделении pbuf, что закрывает утечку на пути потери пакетов (#11726).
  • При сканировании устройств NVMe происходила утечка одного выделения на каждое неактивное пространство имён; изменено на парное повторное использование и освобождение (#11920, два файла).
  • На пути неудачного зондирования virtio RPMsg добавлено освобождение ресурсов NS и передача кода ошибки наверх (#11968).
  • Исправлен выбор bInterfaceProtocol в дескрипторе интерфейса USB HID: заполняется согласно протоколу, а не фиксированным значением (#11873).
  • В команде disk инструмента mkdist исправлены две проблемы: повторное внедрение RTT_ROOT в SConstruct и прямой сбой при пересборке dist при встрече с каталогом, который невозможно удалить из-за отсутствия прав (#11874).

Эти семь коммитов по отдельности выглядят небольшими, но охватывают шесть уровней: блочные устройства, символьные устройства, сеть, хранилище, USB и инструменты сборки, — и все они были внесены в один день, что составляет ту же волну, что и пакетное слияние ниже.

2. Сопровождение безопасности и очередь на слияние

2.1 ivshmem принимает конфигурационные слова устройства за доверенный ввод, узел /dev становится каналом произвольной физической памяти (11-06)

Дата: 2026-11-06 00:54 (время отчёта)　Источник: Дефект #11992

Автор отчёта XueDugu, продолжающий свою недавнюю линию по PCI и драйверам устройств. Проблема в функции зондирования драйвера ivshmem: когда BAR2 сообщает нулевой размер, код уходит в ветку отката JailHouse и напрямую читает из конфигурационного пространства PCI по адресам 0x40–0x4f четыре двойных слова — адрес и размер разделяемой памяти. Эти четыре сегмента определяются стороной устройства, драйвер их никак не проверяет, а затем передаёт их в rt_ioremap, который сам по себе не проверяет легальность физического адреса.

Цепочка последствий коротка: вредоносное или некорректно отформатированное устройство описывает «разделяемую память» как область памяти ядра, отображение всё равно succeeds, а окно затем регистрируется как /dev/ivshmemN. Последующие чтения и записи идут через два memcpy в официальном пути open/read/write: одно копирует содержимое ядра пользователю, другое записывает пользовательские данные обратно в ядро. Таким образом, любой непривилегированный процесс, открыв этот узел устройства, получает возможность чтения и записи произвольной физической памяти ядра с байтовой гранулярностью и полностью контролируемыми данными, не нуждаясь ни в каких специальных ioctl или дополнительных правах.

В отчёте указана и сопутствующая проблема: исходный код разбивал 64-битное поле на два 32-битных записи, что в 32-битной сборке приводило к записи в соседнее поле, то есть попутно повреждало структуру. Это тот же шаблон, что и в случае с MSI-X: значения, предоставленные прошивкой устройства, принимаются за доверенный ввод, а на стороне драйвера отсутствует обязательное действие «сначала проверить, потом использовать».

2.2 Исправление через два часа одиннадцать минут: новый параметр запирает откат JailHouse в клетку (11-06)

Дата: 2026-11-06 03:05 (время предложения)　Источник: Предложение #11993

99 строк добавлено, 7 строк удалено, два файла, автор — мейнтейнер BernardXiong, статус — ожидает проверки, есть одно обсуждение.

Исправление разделено на четыре уровня. Первый уровень — по умолчанию отключить опасный путь: добавлен параметр RT_IVSHMEM_JAILHOUSE, по умолчанию n, в тексте помощи указано, что устройство должно быть доверенным; если он не включён, при отсутствии BAR2 зондирование сразу отклоняется, конфигурационные слова больше не читаются. Второй уровень — проверка перед отображением: размер не нулевой, адрес плюс размер не переполняется, весь интервал выразим локальным указателем и типом размера. Третий уровень — исправление типов: четыре конфигурационных двойных слова сначала читаются в 64-битные локальные переменные, больше не записываются в поля структуры через 32-битные псевдонимы, попутно исправлена проблема затирания соседних полей. Четвёртый уровень — проверка возвращаемого значения чтения конфигурационного пространства: при неудачном чтении обработка не продолжается.

Проверка ограничена компиляцией и форматированием: обе комбинации параметров (JAILHOUSE выключен и включён) компилируются на qemu-virt64-aarch64, изменённые файлы проходят clang-format. От отчёта в 00:54 до предложения в 03:05 — два часа одиннадцать минут, что ещё быстрее, чем шесть часов для MSI-X в прошлом выпуске.

2.3 Проверка MSI-X: от ожидания проверки до слияния — вчерашний отчёт сегодня реализован (11-05)

Дата: 2026-11-05 10:47 (время слияния)　Источник: Предложение #11986, Дефект #11985

Та правка MSI-X, что в прошлом выпуске отчёта имела статус ожидания проверки, в этом выпуске слита в 10:47: 47 строк добавлено, 5 строк удалено, изменён только один файл msi.c. Пять проверок реализованы согласно исходному предложению: отклонение при выходе BIR за границы, отклонение при нераспределённом BAR или нулевом размере, сравнение смещения таблицы плюс числа записей с размером BAR, проверка возвращаемого значения чтения конфигурационного регистра, отклонение при превышении числом записей размера таблицы; в вычислениях физический базовый адрес и число байт переведены в 64 бита, чтобы избежать переполнения 32-битного сложения.

От отчёта 04.11 в 17:12 до предложения следующего дня в 02:47 и слияния 05.11 в 10:47 — вся цепочка замкнулась за два дня. В этом выпуске он вынесен отдельно по той причине, что вместе с двумя однотипными дефектами ниже он образует непрерывную выборку одного класса проблем — проверки входных данных на стороне устройства, а эта область до сих пор почти не покрывалась аудитом.

2.4 Одиннадцать исправлений выхода за границы и проверки параметров слиты за один день (11-05)

Дата: 2026-11-05 (время слияния)　Источники: предложение #11941, предложение #11935, предложение #11899, предложение #11895, предложение #11970, предложение #11971, предложение #11962, предложение #11918, предложение #11558, предложение #11901, предложение #11986

Из 31 слияния в этом выпуске 11 напрямую связаны с линией безопасности, непрерывно отслеживаемой в предыдущих выпусках, и все они реализованы в течение 24 часов. Помимо трёх уже вынесенных отдельно, ключевые моменты остальных восьми:

  • Усиление пользовательских указателей в ioctl терминала (#11941, 503 строки добавлено, 57 строк удалено, семь файлов): команды TIOCGWINSZ, TIOCSWINSZ, TIOCGPGRP, TIOCGSID, FIONREAD, TIOCGPTN и другие переведены на схему «сначала во внутренний стек-буфер, затем copyin/copyout», нераспознанные команды возвращают ENOTTY.
  • Добавление проверки границ и безопасного открепления из списка в пути закрытия signalfd (#11935, 526 строк добавлено, 228 строк удалено, 11 файлов): это самое крупное изменение в batch, затрагивает ссылки на слоты и жизненный цикл lwp, изменения охватывают две подсистемы — libc и lwp.
  • Отклонение недопустимых смещений при чтении и записи фреймбуфера (#11970): при отрицательном смещении или выходе за длину плоскости сразу возвращается ноль.
  • Проверка пользовательских указателей в ioctl pipe (#11971), та же идея, что и в #11941.
  • Проверка канала ADC у BlueLink AB32 (#11962): номер канала ограничен диапазоном от 0 до 15, при неудачном преобразовании возвращается EINVAL.
  • Сведение контролируемой сервером длины к фактически полученным байтам в клиенте 9PFS (#11918, 63 строки добавлено): исправляет переполнение чтения и утечку информации о каталоге из отчёта #11289, по пунктам проверяются длина записи, длина имени и оставшиеся байты.
  • Количество областей стирания CFI MTD и границы таблицы секторов (#11558): при превышении количества локальной таблицы зондирование завершается неудачей, при равенстве счётчика секторов длине массива он считается заполненным.
  • Добавление верхнего предела глубины при разворачивании дерева устройств (#11901, 72 строки добавлено): предварительная проверка обходом вычисляет максимальную глубину, при превышении 63 уровней разворачивание сразу отклоняется, запись за пределы фиксированного стека больше не происходит.

Заслуживающее внимания распределение: из этих 11 у usualtreee и мейнтейнера BernardXiong по 3, у adilalperenciftci 2, остальные 3 — от cms19859230182-lang, Old-Ding и liangzhan5. Если посмотреть на это вместе с полным распределением из 5.1, внешние контрибьюторы уже выработали стабильный ритм аудиторской работы, а фокус мейнтейнеров смещается от «поиска проблем» к «проверке патчей».

2.5 Очередь: сорок восемь ожидающих проверки обновлений, изменение разделов блочного устройства всё ещё висит (11-05)

Дата: 2026-11-05 (время обновления предложений)　Источники: предложение #11981, предложение #11990, предложение #11989, предложение #11987, предложение #11897

В окне мониторинга обновлено в общей сложности 48 ожидающих проверки предложений, из которых три заслуживают пристального внимания:

Исправление произвольной записи в ядро через структуру раздела блочного устройства (#11981) снова обновлено в 16:03 и по-прежнему не слито. Этот коммит висит уже три дня; сам дефект состоит в том, что переданный из пользовательского пространства указатель на структуру раздела напрямую разыменовывается ядром, что относится к категории высокой опасности — рекомендуется приоритет.

Две задачи по тестовой инфраструктуре продвигаются параллельно: #11990 подключает тесты фреймворков DAC и I2C к автоматическому запуску в QEMU (20 строк изменений, правки в utest_auto_run.yml и новый файл конфигурации), #11989 добавляет регрессионное покрытие QEMU для dlmodule. Эти два изменения вместе с тремя наборами тестов фреймворков, слитыми в этом выпуске (см. 4.2), образуют единый комплекс.

Со стороны функциональности: ulog поддерживает вывод вызывающей функции, файла и номера строки (#11987, создан в 14:22); поддержка K230D и улучшения Smart (#11897) созданы 10-18, обновлены в этом выпуске в 17:21, BSP — это RISC-V K230, относится к той же линии, что и исправление Smart из 1.2.

3. Официальные и общественные мероприятия

3.1 Titan Board подключает OpenMV: 170 примеров на Python, NPU работает через TFLM (11-05)

Дата: 2026-11-05 17:30 (время публикации в колонке)　Источники: EE Times China: Titan тоже умеет OpenMV, Инженерия: Titan_Openmv

Официальная колонка RT-Thread в этом выпуске публикует проект OpenMV для Titan Board, перенося RT-Thread 5.1, OpenMV 5.0.1 и MicroPython вместе на эту плату на базе Renesas RA8P1: 1 GHz Cortex-M85 запускает систему и приложения, 250 MHz Cortex-M33 сопроцессор, NPU Ethos-U55 на частоте 500 MHz, внешняя 32 MiB HyperRAM для хранения изображений и оперативной памяти, пиковая производительность AI заявлена на уровне 256 GOPS. По периферии: MIPI-камера OV5640, SD-карта FAT/FAT32, составное устройство CDC и MSC на USB HS, а также встроенные трёхцветный LED и кнопки.

Масштаб примеров — главное достоинство этого релиза: всего 170 независимых Python-скриптов, 124 по традиционному зрению, охватывающих управление камерой, фото- и видеосъёмку, рисование, фильтрацию, отслеживание цвета, штрихкоды, обнаружение признаков и AprilTag; 23 по машинному обучению с 20 файлами моделей для Ethos-U55-256 и одной моделью численной регрессии, исполняемой на CPU, задачи охватывают жесты (камень-ножницы-бумага, обнаружение ладони, 21 ключевая точка руки), лица и позы (обнаружение лица, 468 ключевых точек, поза человека), распознавание объектов (пешеходы, кошки и собаки, распространённые объекты COCO80) и классификацию/сегментацию изображений.

Организация проекта практически помогает при освоении: код находится в SDK в project/Titan_Openmv, поддерживается как RT-Thread Studio, так и SCons; сборка выдаёт два файла, которые необходимо использовать вместе — rtthread.hex прошивается через DAP-Link или J-Link, openmv-vision.bin передаётся через составное устройство USB, оба должны быть из одной сборки. Модели и метки размещаются в models/sdcard/, достаточно скопировать их в корень SD-карты согласно инструкции; /rom в скриптах — это read-only псевдоним корня SD-карты, отдельный каталог создавать не нужно; чтобы работа запускалась автоматически при включении, сохраните приложение как main.py в корне SD-карты. В статье также особо отмечается, что отображаемый в IDE AE3 — лишь идентификатор совместимости протокола, прошивать firmware Alif AE3 нельзя, плата использует firmware RA8P1 данного проекта.

Два технических вывода: во-первых, эта комбинация связывает «захват камерой, обработку изображений, инференс нейросети, управление периферией» в одном Python-скрипте, порог входа в периферийное зрение снижается с написания C-драйверов до изменения параметров; во-вторых, операторы распределяются между CPU и NPU в зависимости от поддержки, диспетчеризацией занимается TFLM, а значит, запустится ли модель, зависит от покрытия операторов; 20 моделей в примерах сами по себе являются рабочим перечнем покрытия.

3.2 Магазин плагинов Env переходит на бессерверный индекс: пакеты плагинов размещаются в GitHub Release (11-06)

Дата: 2026-11-06 07:05 (время слияния)　Источники: Предложение env #304, Предложение sdk #11, Каталог индекса env-plugins

Одна и та же партия изменений в двух репозиториях: в репозитории sdk добавлен каталог env-plugins, в котором размещён index.json в качестве каталога плагинов, каждый плагин имеет подкаталог со своим index.json; в репозитории env реализовано чтение этого «бессерверного индекса» и загрузка установочных пакетов .epack из GitHub Release. Со стороны env добавлено 1108 строк, удалено 48 строк, 18 файлов, включая логику магазина, фронтенд-страницы WebUI, подкоманды командной строки и пять групп тестов; со стороны sdk добавлено 125 строк, четыре файла.

Внешне видимое изменение — это способ использования: по умолчанию индекс читается из локального репозитория SDK, развёртывание сервера маркетплейса не требуется; пакеты плагинов публикуются в GitHub Release; при явной установке переменной окружения или выполнении rt-env plugin market set по-прежнему приоритетно используется HTTP-маркетплейс, а rt-env plugin market clear позволяет очистить HTTP-конфигурацию в файле и вернуться к источнику SDK, при этом переменная окружения всегда имеет наивысший приоритет. Первым опубликованным плагином стал конфигуратор RT-Kconfig 0.1.34; запись о загрузке в индексе указывает на реальный актив .epack в Release этого репозитория, а не на заглушку.

В части безопасности сделано тщательнее, чем ожидалось: размер загрузки имеет верхний предел, при превышении возвращается 413; перенаправление допускается только на тот же хост и с тем же протоколом, переход на неожиданный домен сразу отклоняется; путь индекса не может выходить за пределы каталога env-plugins; id плагина имеет ограничение регулярным выражением и проверку на дубликаты. Сопутствующий коммит подключает регрессионные тесты плагинов к GitHub Actions, а в CI перед упаковочными тестами сначала собирается поставляемый в пакете epack. Практическое значение для экосистемы состоит в том, что сторонним плагинам больше не нужно ждать проверки официального маркетплейса и сервера — достаточно выпустить Release и добавить одну запись в индекс, чтобы распространять плагин; цена этого — граница доверия смещается с «официального маркетплейса» на «сопровождающего репозиторий».

3.3 Официальный новостной интерфейс по-прежнему застыл на июне, форум по-прежнему 468 (11-06)

Дата: 2026-11-06 (проверка)　Источник: Список официальных новостей RT-Thread

Последняя запись, возвращаемая официальным новостным интерфейсом getList?type=rt_org, — это по-прежнему запись от 2026-06-17 «RT-Thread Ruiside Technology приглашена на инвестиционный форум Абу-Даби 2026»; в этом выпуске новых записей нет, новостной блок на главной странице официального сайта также застыл на июне. Это один и тот же вывод на протяжении нескольких выпусков подряд: центр официальных внешних публикаций уже стабильно сместился в медийную колонку и GitHub.

Форум club.rt-thread.org в этом выпуске по-прежнему возвращает 468 с предварительной страницей вызова WAF, список тем и тексты сообщений напрямую прочитать нельзя. Сторону обсуждений сообщества приходится дополнять только через issue и комментарии к PR в GitHub; три обсуждения #11992 и #11993 в этом выпуске были получены именно так.

4. Экосистема и адаптация производителей

4.1 Предварительно собранный образ ESP32-C3 отклоняет чипы v1.x: поле минимальной версии не согласовано (11-05)

Дата: 2026-11-05 23:24 (время отчёта)　Источник: Дефект #11991

Автор отчёта — anamarija-j, затронутые версии указаны как v5.3.0 и master cbadbdf, оборудование — ESP32-C3, ревизия чипа v1.1 (версия ROM esp32c3-eco7-20230720), BSP — bsp/ESP/ESP32_C3. Это единственный в данном выпуске регрессионный дефект RISC-V BSP.

Симптом делится на две части: esptool напрямую отказывается прошивать, сообщая, что предварительно собранный bootloader.bin требует ревизию чипа 3 и выше, а эта плата имеет ревизию 1; после принудительной прошивки с –force вторичный загрузчик запускается, но останавливается до чтения таблицы разделов, и в журнале указано, что чип — V101, а минимальная ревизия, заданная конфигурацией приложения, — 3.

Корневая причина — в семантике полей: в предварительно собранном bootloader заполнено только старое поле min_chip_rev (значение 3), а полное поле min_chip_rev_full равно 0; этот bootloader из ESP-IDF v5.0-dev как раз сравнивает старое поле с номером минорной версии, минорная версия v1.1 равна 1, поэтому проверка не проходит. SConstruct в BSP также задаёт только image.min_rev = 3, и сгенерированный rtthread.bin несёт ту же проблему. Иными словами, одна и та же «минимальная ревизия» выражается старым и новым набором полей, но и предварительно собранный артефакт, и сборочный скрипт заполняют только старый набор, и при встрече с чипом, интерпретируемым по новым правилам, всё застревает.

Практический охват этой проблемы немал: ESP32-C3 — один из самых распространённых беспроводных MCU RISC-V в экосистеме RT-Thread, и непригодность предварительно собранного образа означает провал первого запуска у нового пользователя на плате — остаётся только собирать всё с нуля самостоятельно. Исправление несложное: достаточно одновременно записывать min_chip_rev_full в SConstruct и в предварительно собранный артефакт, но вместе с этим потребуется заново выпустить пакет.

4.2 Пять коммитов по BSP и тестовой инфраструктуре: D1s в QEMU, efm32 в menuconfig, тесты трёх фреймворков (11-05)

Дата: 2026-11-05 (время слияния)　Источник: Предложение #11903, Предложение #11867, Предложение #11883, Предложение #11982, Предложение #11976

Два коммита на стороне BSP — оба в направлении «сделать плату удобнее». Для Allwinner D1s добавлен стартовый скрипт qemu-d1s.sh, позволяющий запускать этот BSP прямо на QEMU-машине d1s, избавляя от поиска образов и сборки параметров (#11903). Для EFM32 добавлены Kconfig и .config, официально поддерживается scons –menuconfig, ранее можно было только вручную править конфигурацию (#11867).

Три коммита по тестовой инфраструктуре — направление единое: добавить в сам фреймворк тесты с эмулируемыми устройствами. Для сторожевого таймера добавлен дымовой тест, допускающий погрешность квантования таймаута и неостанавливаемый путь завершения (#11883, соответствует дефекту #11446); для I2C фреймворковый уровень покрыт эмулированной шиной без зависимости от реального оборудования (#11982); для DAC тестирование ведётся с эмулированным устройством (#11976). Все три коммита представлены контрибьюторами сообщества; вместе с ожидающей рассмотрения в 2.5 переделкой автоматического запуска QEMU прослеживается чёткое действие: превратить проверку драйверных фреймворков из «ожидания оборудования» в «вход в CI».

5. Тренды и итоги выпуска

5.1 Тридцать один коммит за день: расчистка накопившегося вместо постепенного продвижения

За 24 часа мониторинга в основной репозиторий влито 31 предложение — крупнейшая за последнее время однодневная партия. Распределение по времени очень концентрированное: с 02:47 до 03:18 (пекинское время 10:47–11:18) за 31 минуту влито 17 коммитов, между 05:23 и 10:40 — ещё 13, последний коммит — разделение ARM Kconfig — landed отдельно в 22:26.

Состав партии показывает, что это не «написано сегодня — сегодня и влито»: многие — старые предложения, созданные в середине-конце октября — #11892 и #11897 созданы в один день (10-18), #11901 создан (10-19), #11918 создан (10-22), #11935 и #11941 созданы (10-28), #11947 создан (10-29), самый старый #11558 создан 5 июля. То есть накопление за четыре месяца единоразово закрыто после концентрированного ревью. Для нижестоящих это означает: при пулле master в эти два дня будет видна обширная масса изменений, стоимость регрессионного тестирования высвобождается концентрированно, а не размазывается по дням.

Другой сигнал — структура вливавших. Из 31 коммита: usualtreee — 7, BernardXiong — 5, cms19859230182-lang — 4, adilalperenciftci — 2, остальные 13 — от разных контрибьюторов. Разделение ревью и внесения уже достаточно чёткое: внешние контрибьюторы дают патчи, мейнтейнеры выполняют проверку и пакетное вливание.

5.2 Тренд: ввод со стороны устройств становится вторым основным фронтом

Если соединить последние четыре выпуска, видно, что поверхность атаки смещается. В конце октября — начале ноября в основном сообщалось об отсутствии проверки «значение → объект» на уровне системных вызовов: вложенные пользовательские указатели getaddrinfo, указатель ioctl pipe, timerfd, сырые указатели разделов блочных устройств. Два новых дефекта этого выпуска сменили предпосылку — MSI-X требует вставки вредоносного устройства, ivshmem требует, чтобы устройство заполнило слово конфигурации адресом ядра. Общее: регистры, предоставленные прошивкой устройства, ядро трактует как доверенный ввод, а rt_ioremap не проверяет легальность физического адреса, поэтому «что устройство скажет — то и отображается».

Скорость реагирования — другая линия: MSI-X от отчёта до предложения — 6 часов, до вливания — два дня; ivshmem от отчёта до предложения — 2 часа 11 минут. Отчётчик предоставляет полные материалы с PoC, логами и прослеживаемостью версий, и мейнтейнер, получив их, может сразу править — это сжимает время исправления сильнее, чем процедурные предписания. Цена — очередь продолжает утолщаться: 48 обновлений ожидают рассмотрения, коммит по разделам блочных устройств висит три дня и всё ещё не влит.

Третья линия — структура и инструменты продвигаются синхронно: libcpu/Kconfig начинает разделяться по архитектурам, нумерация версий и процесс релиза уже оформлены документально, распространение плагинов Env переведено с централизованного маркетплейса на «индекс репозитория плюс Release», тестирование — с ожидания оборудования на вход в CI. Эти четыре вещи не на одной линии, но все они заменяют «полагаться на память людей» на «полагаться на структурные ограничения».

5.3 Ограничения и пояснения по дедупликации

Форум по-прежнему возвращает 468 и предваряющую страницу вызова WAF; пробел в части обсуждений сообщества восполнен через GitHub; официальный новостной интерфейс и список новостей на официальном сайте застыли на 17 июня, несколько выпусков подряд без пополнений. Агрегационная страница колонки EE Times China в этот раз при прямом подключении не дала список; материал Titan получен через Google News по совпадению заголовка с последующей проверкой текста и времени публикации извлечением со страницы.

Сбор на стороне GitHub в этот раз на позднем этапе упёрся в лимит анонимного интерфейса (60 раз в час); вливания, дефекты, список ожидающих рассмотрения в основном репозитории и коммиты в двух вспомогательных репозиториях полностью проверены, но поиск по topic вне организации в этот раз не выполнялся, поэтому не исключено, что отдельные небольшие обновления репозиториев сообщества не попали в отчёт; это указано честно, без спекулятивных дополнений.

Дедупликация: #11986 в прошлом выпуске учтён как ожидающий рассмотрения, в этом — как влитый с указанием времени цепочки; #11981 был указан в прошлом выпуске, в этом фиксируется только статус; #11897 в прошлом выпуске появлялся в очереди, в этом фиксируется только время обновления и связь с RISC-V; инженерный код Titan уже вошёл в репозиторий 10-30, в этом выпуске учтён официальный релизный документ и инженерное описание от 11-05, не пересчитываемые как обновление кода.

Приложение: таблица проверки источников и перечень источников

Таблица проверки источников

Источник Результат проверки
Официальный новостной интерфейс (rt_org) За 24 часа новых записей нет, последняя запись датируется 2026-06-17
Список новостей на официальном сайте Новостной раздел главной страницы по-прежнему за июнь, новых записей нет
Фóрум сообщества Страница WAF-проверки (HTTP 468) на входе, список и содержимое недоступны для чтения
Коммиты основного репозитория Пуши в окне мониторинга сосредоточены 11-05 с 02:47 по 14:26 (UTC), три волны
PR основного репозитория Смержено 31; ожидают проверки 48 обновлений
Issue основного репозитория Создано 2 (#11992 ivshmem, #11991 ESP32-C3)
Releases и tags основного репозитория Новых нет, последний по-прежнему v5.3.0 (2026-09-10)
Репозитории организации RT-Thread Проверено 35 репозиториев, пуши есть в трёх: основной репозиторий, env, sdk
Репозитории env и sdk В env смержен проект каталога плагинов (18 файлов), в sdk выпущен первый индекс плагинов
Google News на китайском 4 записи за 3 дня, только материал о Titan OpenMV от 11-05 является новым в этом выпуске и включён
Google News на английском Ноль релевантных совпадений
HN Algolia 7 записей — все о протоколах сетей Thread, вакансии или нерелевантное, исключены
Официальная колонка EE Times China 11-05 одна статья о Titan OpenMV, включена
Поиск по репозиториям (topic:rt-thread) В этом выпуске не выполнялся из-за лимита анонимного интерфейса, см. 5.3

Полный список источников