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

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

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

    1. Ядро и динамика версий
      • Усиление защиты вложенных пользовательских указателей в getaddrinfo вошло в основную ветку: единый снимок заменяет послойную проверку (11-03)
      • Деление на ноль в делителе частоты SPI на DM365: срабатывает при передаче max_hz = 0 (11-03)
      • Тест mailbox гарантированно падает при втором запуске: четыре флага завершения никогда не сбрасываются (11-03)
      • Комментарий к макросу в конце строки или над ней: в правила кодирования добавлен раздел с критерием (11-03)
    1. Сопровождение безопасности и очередь на слияние
      • timerfd принимает произвольный fd: два системных вызова дают управление PC ядра (11-04)
      • id POSIX timer не проверяется: на RT-Smart можно перезаписать консольное устройство (11-03)
      • Произвольная запись в ядро через ioctl разделов блочного устройства дождалась предложения (11-03)
      • Очередь: патч pipe всё ещё дорабатывается, пять старых задач продолжают висеть (11-03)
    1. Официальные и общественные мероприятия
      • Учжэнь «Новый свет»: AIOS-основа вошла в число отобранных, речь о виртуализированном смешанном развёртывании (11-02 ~ 11-03)
      • Альянс открытого AIOS обсуждает малую встроенную робототехнику, RT-Thread представляет три класса решений для Agent (11-03)
      • Официальный новостной интерфейс по-прежнему заморожен на июне, выход релизов продолжается в медиаколонке (11-04)
    1. Экосистема и адаптация производителей
      • Studio BSP для платы Wildfire HPM6750 BTB выложен на GitHub, процесс установки описан в пять шагов (11-04)
      • Общественный BSP для N9H30 от Nuvoton: ветеран ARM926EJ-S на платформе HMI (11-03)
      • Двух-MCU устройство дезинфекции: M7 управляет движением, M3 — распылением, обе стороны работают на RT-Thread (11-03)
    1. Отраслевые применения
      • Двухвыпускной FPGA CPU RV32IM подключает RT-Thread Nano к цепочке верификации CoreMark (11-03)
    1. Тенденции выпуска и итоги
      • Тенденция: сторона безопасности перешла от отчётов к предложениям, сторона тестирования — от списков к коду
      • Ограничения и пояснения по дедупликации

1. Ядро и динамика версий

1.1 Усиление защиты вложенных пользовательских указателей в getaddrinfo вошло в основную ветку: единый снимок заменяет послойную проверку (11-03)

Дата: 2026-11-03 09:04 (время слияния)　Источник: предложение #11977

Переработка от сопровождающего, о которой сообщалось в прошлом выпуске, слита в начале окна: 57 добавленных строк, 17 удалённых, изменён только один файл syscall_netdb.c в каталоге сетевых системных вызовов.

Уязвимость исходной реализации заключалась в послойной проверке: проверялся только верхний буфер res, переданный пользователем, а затем через управляемый пользователем вложенный указатель res->ai_addr записывался разобранный адрес сокета, что в сборках Smart/MMU равносильно превращению одного getaddrinfo() в произвольную запись в ядро. Поля hints после прохождения верхней проверки по-прежнему читались напрямую из пользовательской памяти, оставляя окно TOCTOU. Проверка возвращаемого значения копирования servname также была написана неверно — сравнение size_t с 0 всегда ложно.

Исправление состоит в том, чтобы с помощью lwp_get_from_user() разом скопировать res и hints во временную структуру ядра, после чего все вложенные указатели происходят из этого проверенного снимка; вложенные sockaddr и внешний addrinfo единообразно записываются обратно через lwp_put_to_user(), диапазон целевого адреса проверяется существующим helper, и ядро больше не разыменовывает непроверенные пользовательские указатели. Попутно выделяется адресное пространство ядра addrinfo по sizeof(*k_hints) и освобождается k_res на новых путях ошибок.

Ценность этого изменения не в количестве строк, а в том, что оно демонстрирует подход: для вложенных пользовательских указателей послойная проверка изначально имеет разрыв TOCTOU, и только единый снимок является доказуемо безопасным путём. Автор отмечает в предложении, что проверка ограничилась успешной компиляцией syscall_netdb.o в конфигурации RT-Smart на K230, полная сборка передана CI, воспроизведения эскалации привилегий из пользовательского режима нет.

1.2 Деление на ноль в делителе частоты SPI на DM365: срабатывает при передаче max_hz = 0 (11-03)

Дата: 2026-11-03 13:11 (время слияния)　Источник: предложение #11957, дефект #11950

Добавлено 6 строк, изменён только bsp/dm365/drivers/spi-davinci.c — это самая маленькая правка в данном окне мониторинга.

davinci_spi_setup_transfer() передаёт cfg->max_hz без изменений в davinci_spi_get_prescale(), который выполняет DIV_ROUND_UP(clk_get_rate(dspi->clk), max_speed_hz). Как только в конфигурации max_hz равен 0 и ширина данных корректна, это деление приходится на ноль, что приводит к непосредственному исключению. Исправление заключается в проверке max_hz == 0 перед вычислением предделителя и возврате -RT_EINVAL; путь с ненулевой скоростью не затрагивается.

Условия проверки описаны честно: аппаратуры DM365 под рукой нет, сделано только две вещи — компиляция bsp/dm365/drivers/spi-davinci.c через arm-none-eabi-gcc без новых предупреждений; воспроизведение на стороне хоста двух фрагментов логики — проверки ширины и предделителя: при data_width = 9, max_hz = 0 до исправления получался SIGFPE, после исправления возвращается -RT_EINVAL, а результат предделителя для 1 MHz совпадает с исходным. DM365 — старая платформа ARM9 от TI, подобные BSP обычно почти не покрыты тестами, и добавление критерия защиты от деления на ноль уже является чистым выигрышем.

1.3 Тест mailbox при втором запуске обязательно падает: четыре флага завершения никогда не сбрасываются (11-03)

Дата: 2026-11-03 10:53 (время слияния)　Источник: предложение #11963, дефект #6565

Добавлено 11 строк, изменён только src/utest/mailbox_tc.c.

Симптом: при втором запуске core.ipc_mailbox в рамках одной и той же загрузки тест неизбежно падает: первый раз проходит, второй раз в потоке приёма срабатывает утверждение rt_object_get_type(...) == RT_Object_Class_MailBox, в строке 2884 _rt_mb_recv(). Корневая причина — четыре флага *_thread_finish устанавливаются в 1 только рабочими потоками и никогда не сбрасываются; при втором запуске цикл ожидания тестового тела while (static_mb_recv_thread_finish != 1 || ...) немедленно проходит, и тогда rt_mb_detach() вызывается, когда рабочий поток текущей загрузки, всё ещё заблокированный в rt_mb_recv(), ещё не завершился; поток затем восстанавливается с ошибкой и продолжает использовать уже отсоединённый mailbox. Половина с динамическим mailbox имеет ту же форму, просто не была отдельно воспроизведена.

Исправление — обнуление в utest_tc_init(), этот хук вызывается фреймворком utest перед каждым запуском тестового примера. Дефект #6565 — старый долг, открытый в 2021 году; этой правкой закрыта его оставшаяся половина.

1.4 Комментарий к макросу — в конце строки или выше: в стандарт кодирования добавлен раздел с критерием (11-03)

Дата: 2026-11-03 09:48 (время слияния)　Источник: предложение #11973, дефект #10097

Добавлено 72 строки, всё в документации: coding_style_cn.md — плюс 32 строки, coding_style_en.md — плюс 40 строк, в раздел 8 каждого добавлен подраздел «Комментарии к макросам», ни одна строка кода не изменена.

Прежний стандарт лишь говорил, что «комментарий к оператору можно писать только над кодом или справа от него», но не уточнял, какой вариант выбирать для макросов и на каком основании, поэтому в одном репозитории сосуществовали оба стиля. Автор сначала собрал статистику текущего состояния, а затем определил правило: в include/ 135 комментариев к макросам используют концевой /**<, из них 87 (64,4%) превышают 80 колонок, строка 24 в kerrno.h — 95 колонок; сгруппированные константные макросы намеренно выровнены по колонкам и допускают превышение длины. Поэтому критерий — не длина строки, а «сколько пояснений требуется»: если хватает одного комментария, он ставится в конец строки; если нужен целый абзац (макросы с параметрами, где требуется описать входные параметры, результат раскрытия и ограничения использования) — он ставится выше с @def.

Документация также дополнена одним практическим различием: при включённом MACRO_EXPANSION концевой /**< привязывается к точке раскрытия макроса, и при нескольких раскрытиях одного макроса позиция комментария может оказаться неожиданной; блочный комментарий выше всегда привязан к месту определения. Поэтому для часто раскрываемых макросов предпочтителен блочный комментарий выше. Все примеры взяты из реального кода репозитория (группа кодов ошибок в kerrno.h, RT_ALIGN в rtdef.h), а не выдуманы.

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

2.1 timerfd принимает произвольный fd: два системных вызова дают управление PC в ядре (11-04)

Дата: 2026-11-04 01:08 (время отчёта)　Источник: дефект #11984

Докладчик XueDugu, базовая версия — master 5d1fb66d13 (v5.4.0-dev). Область влияния указана явно: затронуто начиная с v5.0.2, дефект внесён коммитом 7c2f807a от 2023-09-23 (то есть тем самым включением системного вызова timerfd из #8067).

Сама проблема очень короткая: timerfd_do_settime() и timerfd_do_gettime() берут произвольный дескриптор из таблицы fd процесса, а затем напрямую приводят df->vnode->data к struct rt_timerfd *, не проверяя, является ли этот файл вообще timerfd. В Linux в том же месте есть строка file->f_op != &timerfd_fops, которая возвращает -EINVAL, а в RT-Thread соответствующей проверки нет. Поэтому vnode->data любого доступного пользователю объекта fd будет воспринято как timerfd: ядро возьмёт и освободит поддельный мьютекс внутри чужого объекта, запишет туда предоставленный атакующим itimerspec, а затем разыменует tfd->timer (выполнив удаление из связного списка и rt_free на произвольном qword).

По-настоящему фатальным является отрицательный it_value.tv_sec: он заставляет timerfd_timeout(tfd) выполняться синхронно, и первый оператор rt_wqueue_wakeup(&tfd->timerfd_queue, POLLIN) обходит голову очереди ожидания, прочитанную из запутанного объекта, и вызывает entry->wakeup(entry, key) — косвенный вызов через указатель на функцию, причём и указатель, и r0 полностью берутся из выбранной атакующим памяти.

В отчёте приведена полная цепочка: на 32-битном RT-Thread signalfd является идеальным запутывающим объектом, первые 128 байт его контекста — это sigset_t sigmask, скопированный функцией signalfd() из пользовательского указателя как есть (допускаются NUL-байты), чего достаточно для перекрытия поддельного заголовка timerfd, включая установку байта type у rt_mutex в тип мьютекса, оставление owner равным 0, чтобы take немедленно завершился успехом, и установку timerfd_queue.waiting_list.next. Поскольку ядро RT-Smart разделяет таблицы страниц с пользователем и напрямую разыменовывает пользовательские отображения, поддельный узел очереди ожидания размещается в собственной пользовательской памяти атакующего.

Среда воспроизведения — qemu-vexpress-a9 со сборкой по умолчанию RT_USING_SMART (timerfd и signalfd в Smart включены по умолчанию), запускается пользовательский ELF без libc в качестве /sbin/init. В контрольной группе вызов настоящего timerfd возвращает 0, ядро остаётся живо; в атакующей группе signalfd(-1, mask, 0) плюс timerfd_settime(sfd, 0, {it_value.tv_sec = -1}) приводят к kernel prefetch abort, PC полностью контролируется, три запуска совпадают побайтно, в регистрах видно r00:0x10000. Вывод: два непривилегированных системных вызова, оба официальных POSIX-подобных интерфейса, позволяют полностью перехватить управление ядром.

2.2 id POSIX timer не проверяется, на RT-Smart можно перезаписать консольное устройство (11-03)

Дата: 2026-11-03 12:35 (время доклада)　Источник: дефект #11980

Тот же докладчик, ранее в тот же день. timer_gettime() и timer_settime() используют предоставленный пользователем timer_t напрямую как индекс: timer = _g_timerid[(rt_ubase_t)timerid], без проверки timerid < TIMER_ID_MAX. В родственной функции timer_delete() такая проверка есть, так что это не проектное решение, а пропущенная строка.

В обычной сборке для MCU это чтение за границей массива; на RT-Smart дело не только в этом — атакующий может выбрать указатель, расположенный по адресу рядом с _g_timerid, и переинтерпретировать целевой объект ядра как struct timer_obj. В отчёте конкретный алиас, найденный в образе QEMU, — индекс 0x35a5 (13733), указывающий на _console_device: timer_settime() затем перезаписывает поля живого устройства UART управляемым атакующим itimerspec, включая rx_indicate и ops; достаточно одного принятого UART байта, и управление переходит на указанный атакующим адрес, выполняемый на EL1.

Аппаратная сторона также проверена: на Pico 2 W (RP2350) со сборкой из исходных ctime.c и resource_id.c дизассемблирование подтверждает, что вход timer_settime() — это ldr.w r6, [r5, r0, lsl #2]; после выполнения timer_oob с передачей 0x20000000 адрес вычисляется как 0xa000202c, что не отображено, после сбоя соединение USB CDC исчезает или shell зависает. Программная база та же — v5.4.0-dev, вносящий коммит — 077e9841, первая затронутая версия — v5.0.2.

2.3 Предложение по произвольной записи в ядро через ioctl разделов блочных устройств (11-03)

Дата: 2026-11-03 15:51 (время подачи предложения)　Источники: Предложение #11981, Дефект #11952

Добавлено 19 строк, удалено 5 строк, изменён только один файл, автор liangzhan5, статус предложения — черновик (по собственной пометке автора).

Проблема в RT_DEVICE_CTRL_BLK_PARTITION: команда принимает переданный из пространства пользователя «голый» указатель непосредственно как адрес назначения для rt_memcpy, что позволяет непривилегированному процессу осуществить произвольную запись в ядро. Есть и сопутствующий изъян — после выполнения rt_memcpy не обновляется err, поэтому даже если ioctl в итоге возвращает -1, содержимое по целевому адресу уже изменено, и код ошибки не соответствует фактическому положению. Автор также указывает, что команды вроде RT_DEVICE_CTRL_BLK_GETGEOME могут иметь аналогичную проблему.

Исправление идёт двумя путями: под RT_USING_LWP с помощью lwp_self() определяется, находится ли текущий контекст в пространстве пользователя; если да, данные раздела сначала копируются во временную переменную на стеке ядра, затем безопасно копируются обратно через lwp_put_to_user(), при недопустимом указателе возвращается -EFAULT и никакая запись не выполняется; вне пространства пользователя (внутриядерный вызов) сохраняется прежний путь через rt_memcpy, и добавляется err = RT_EOK. Проверка ограничена компиляцией на qemu-vexpress-a9 и ручной сверкой.

Соответствующий дефект #11952 открыт 29 октября тем же докладчиком, от доклада до предложения — 5 дней.

2.4 Очередь: патч pipe всё ещё дорабатывается, пять старых задач продолжают висеть (11-03)

Дата: 2026-11-03 (время обновления предложения)　Источники: Предложение #11971, Предложение #11954, Предложение #11911, Предложение #11918, Предложение #11947, Предложение #11935

Патч pipe FIONREAD (#11971), о котором сообщалось в прошлом выпуске, снова обновлён 11-03 в 16:13, всё ещё не слит. Способ правки не изменился: сначала длина данных кольцевого буфера или оставшееся пространство вычисляются в int на стеке, в сборке с MMU копирование обратно в адрес пользователя выполняется через lwp_put_to_user(), без MMU сохраняется прямая запись; попутно добавлены проверки на null для pipe и pipe->fifo, а include lwp_user_mm.h обёрнут в ARCH_MM_MMU.

Статус остальных пяти задач в очереди: граница имени каталога cromfs (#11911), переполнение при умножении счётчиков poll и epoll (#11954), доверие клиента 9pfs к длине от сервера (#11918), неограниченный поиск после исчерпания пула адресов DHCP (#11947), удаление слушателя при закрытии signalfd (#11935) — в этом выпуске ни одна не слита. Вчера слитое #11978 (перепутаны начало и конец раздела GPT) закрыто.

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

3.1 Учжэнь «Новый свет»: базовая платформа AIOS вошла в список, речь о виртуализированном гибридном развёртывании (11-02 ~ 11-03)

Дата: 2026-11-02 (открытие выставки) / 2026-11-03 14:30 (публикация официальной колонки)　Источники: EE Times China: RT-Thread на саммите в Учжэне, Всемирная конференция по интернету: выставка открылась в Учжэне, Пресс-релиз CAC

Саммит Всемирной конференции по интернету 2026 года в Учжэне проходит с 2 по 5 ноября в Учжэне провинции Чжэцзян, одновременно выставка «Свет интернета» открылась утром 2 ноября. Официальные данные: участвуют 671 китайская и зарубежная компания и организация из 54 стран и регионов, представлено и анонсировано более 1000 новых технологий и продуктов, отобраны и рекомендованы 35 продуктов «Новый свет» и 20 сценариев «Новое сияние».

Позиция, которую RT-Thread Ruiside получила на этом саммите, — это список рекомендаций продуктов «Новый свет»: в него вошла самостоятельно разработанная компанией «гетерогенная интегрированная оконечная интеллектуальная базовая платформа AIOS RT-Thread». Директор по экосистеме Ли Янь выступила на выставке с программной речью «Решение для воплощённого интеллекта на основе виртуализированного гибридного развёртывания · AI Kit».

Технические тезисы базы изложены чётко: гибридная архитектура развёртывания размещает AI-инференс на стороне Linux, а управление в реальном времени — на стороне RT-Thread; обе стороны работают независимо и не мешают друг другу, и даже при возникновении аномалий на стороне AI сторона управления продолжает стабильно выполняться — официально заявленная точность управления достигает микросекундного уровня. В комплекте AI Kit объединяет движок инференса, оптимизацию моделей, адаптацию оборудования и среду отладки в единую цепочку инструментов; ключевое преимущество — разработчикам не нужно «владеть каким-то конкретным чипом или каким-то конкретным фреймворком», весь процесс проходится одним набором инструментов.

Что здесь стоит зафиксировать — это изменение риторики. Раньше RT-Thread представлял себя как «база управления в реальном времени» и «самая массовая по установкам отечественная встраиваемая операционная система»; на этот раз носителем, вошедшим в список, стала интеллектуальная операционная система для конечных устройств, а точка приложения — синергия «мозга» и «мозжечка» робота. Фраза из официального пресс-релиза «ключевой скачок от базы управления в реальном времени к интеллектуальной операционной системе для конечных устройств» — это официальная версия данной риторики. По цифрам: заявленный в материале масштаб сообщества — около 300 тысяч разработчиков, что согласуется с прежними формулировками.

3.2 Альянс Open Source AIOS о малой воплощённой интеллектуальности, RT-Thread о трёх типах Agent-решений (11-03)

Дата: 2026-11-03 17:14 (время публикации) / 2026-10-23 (время мероприятия)　Источник: Phoenix Net: Альянс Open Source AIOS собирается на WTCC 2026

Коммерческий пресс-релиз, вышедший только 11-03, описывает «Jishu Maker Workshop: семинар по решениям малой воплощённой интеллектуальности», прошедший 23 октября в рамках Шанхайского международного фестиваля технологий и потребительской электроники West Bund (WTCC 2026). Организатор — сообщество Jishu под эгидой Arm China, на одной сцене — три партнёра «Альянса Open Source AIOS»: Rockchip, Radxa Computer и RT-Thread.

Arm China учредила этот альянс в июле текущего года, сосредоточившись на таких возможностях, как непрерывное восприятие, автономное выполнение и долговременная память; тогда же были представлены два практических результата — JishuFriends и JishuBuddy: первый в виде первого прототипа Puppy на базе робота-собаки объединяет восприятие environment, голосовое и визуальное взаимодействие и автономное перемещение; второй — аппаратный инструмент разработки для Agentic AI с естественным языком как входной точкой, адаптированный к встраиваемым устройствам на архитектуре Arm и способный на основе симуляционной среды связываться с реальными воплощёнными устройствами.

От RT-Thread выступил старший инженер по AI Чжэн Вэй, рассказавший о трёх типах Agent-решений: робот-собака, HyperCar и оркестрация Codex; точка приложения — продвинуть интеллектуальных агентов от «диалога» к «выполнению», и было чётко заявлено, что RT-Thread сосредоточится на проектах воплощённой интеллектуальности и совместно с Arm China подключит возможности Agent к реальным приложениям. Разделение труда трёх партнёров в этом материале также довольно ясно: Rockchip говорит о главном SoC управления плюс AI-сопроцессоре, разделяющем вычисления и управление; Radxa — об использовании открытого оборудования вроде ZERO 3W для пути от прототипа до серийной поставки; RT-Thread — о планировании и выполнении Agent на стороне системы.

Следует напомнить о временных соотношениях: мероприятие состоялось 23 октября, а репортаж появился только 3 ноября; в этот выпуск он включён потому, что впервые даёт конкретное техническое разделение труда RT-Thread в альянсе, а не потому, что это событие сегодняшнего дня.

3.3 Официальный новостной интерфейс по-прежнему на июне, выход публикаций продолжается в медиа-колонке (11-04)

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

Последняя запись, возвращаемая официальным новостным интерфейсом getList?type=rt_org, — всё ещё «Компания Ruisaide Technology приглашена на Инвестиционный форум Абу-Даби 2026» от 2026-06-17; новостной блок на главной странице официального сайта также застыл на июне, в этом выпуске новых записей нет. Сам новостной модуль официального сайта не загружается (страница выдаёт «Ой, загрузка не удалась»), список приходится сверять только через интерфейс.

Фактический выход публикаций — в медиа-колонке: в этом выпуске официальная колонка RT-Thread в EE Times China обновилась одной статьёй (материал о «новом свете» Учжэня от 11-03); предыдущий материал о промоакции 11-01 ко Дню холостяков относится к рекламному контенту и не включён. Форум club.rt-thread.org по-прежнему возвращает 468 с предварительной страницей WAF-челленджа, список постов и текст напрямую прочитать невозможно, поэтому со стороны обсуждений в сообществе приходится перекрёстно сверять по GitHub и медиа-колонке.

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

4.1 Studio BSP для Wildfire HPM6750 BTB выложен на GitHub, процесс установки описан в пять шагов (11-04)

Дата: 2026-11-04 03:47 (создание репозитория)　Источник: Репозиторий: rt-thread-bsp-hpm6750-fire-btb

Персонально поддерживаемый пакет Board Support Package для RT-Thread Studio, целевая плата — отладочная плата Wildfire HPM6750 BTB. Таблица параметров в README дана довольно полно: версия BSP 1.0.19, MCU — HPM6750IVM2 (двухъядерный 32-битный RISC-V, до 816 MHz), RT-Thread Full / Latest (фактически работает на 5.4.0), инструментальная цепочка RISC-V GCC 11.1.0, консоль через UART0 на PY06/PY07 (115200 8N1), отладка через внешний JTAG (отмечено, что данная плата не поддерживает SWD).

Процесс установки описан в пять шагов: скачать BSP ZIP из Releases, установить пакет ресурсов в менеджере SDK в Studio, при создании нового проекта выбрать HPM6750-FIRE-BTB, отметить периферию в RT-Thread Settings, собрать и загрузить через USB, DAPLink или J-Link. Эта схема совпадает с той, что используется в официальных репозиториях BSP от HPMicro, только сопровождающий сменился с производителя чипа на частное лицо.

Заслуживает внимания частота появления таких репозиториев. Вчера сообщалось, что HPMicro за тринадцать минут перевёл 12 официальных BSP на v1.13.0, сегодня видно, что сторонние платы тоже дополняются по той же инженерной структуре — BSP разбит на отдельные репозитории и поддерживается как проект Studio. Это соглашение уже переросло от производителя к сообществу и стало фактическим стандартом.

4.2 Community BSP для Nuvoton N9H30: ветеран ARM926EJ-S на платформе HMI (11-03)

Дата: 2026-11-03 20:13 (время пуша)　Источник: Репозиторий: sdk-bsp-nk-n9h30

Community BSP для серии Nuvoton N9H, целевые чипы N9H30F61IEC или N9H30F63IEC. Это ядро ARM926EJ-S с максимальной частотой 300 MHz, встроенный контроллер TFT LCD и 2D-графическое ускорение, параллельный интерфейс может управлять до 1024x768, 24-битный цвет, на кристалле 64 MB DDR, корпус LQFP216 MCP.

N9H — типичная платформа человеко-машинного интерфейса: невысокая вычислительная мощность, полный набор интерфейсов дисплея и периферии, дешёвый BOM, подходит для промышленных HMI, контроля доступа и панелей бытовой техники. BSP RT-Thread на таких MPU всегда поддерживались сообществом, официальная поддержка Nuvoton далеко не такая плотная, как у линейки MCU, поэтому каждый работающий репозиторий имеет справочную ценность при выборе.

4.3 Двух-MCU устройство обеззараживания: M7 управляет движением, M3 — распылением, обе стороны работают на RT-Thread (11-03)

Дата: 2026-11-03 14:02 (время пуша)　Источник: Репозиторий: GD32

Конкурсный проект под названием «Jingxun Weishi», представляющий собой интеллектуальное мобильное устройство обеззараживания для небольших и средних общественных зон — учебных классов, коридоров, общественных сидений. Архитектура двух-MCU: GD32H759IMT6 (Cortex-M7) в роли главного контроллера движения, STM32F103C8T6 (Cortex-M3) в роли контроллера распыления, обе стороны работают на RT-Thread 4.1.1.

Функционально охватывает четырёхколёсное дифференциальное движение, распыление через манипулятор с форсунками, мониторинг остатка через взвешивание HX711, дистанционное управление, обеззараживание по расписанию, отчёт о состоянии и обратную передачу видео. Структура репозитория аккуратнее, чем у большинства конкурсных проектов: в docs/ есть описание аппаратного обеспечения, протокол связи, стиль кода и документация по коммитам, в scripts/ — скрипты сборки Keil и самопроверки репозитория, также приложена конфигурация clang-format.

Интерес в таких проектах не в технической сложности, а в инженерном компромиссе «одного M7 недостаточно, добавим M3 для разделения нагрузки»: управление движением требует реального времени, распыление и мониторинг остатка — медленные переменные, после разделения у каждого чипа остаётся запас, а стоимость связи покрывается одним последовательным протоколом.

5. Отраслевые применения

5.1 Двухвыпускной FPGA CPU RV32IM подключает RT-Thread Nano к цепочке валидации CoreMark (11-03)

Дата: 2026-11-03 20:58 (время пуша)　Источник: Репозиторий: RISC-V-CPU

Проект конвейерного CPU RV32IM для Xilinx Kintex-7, последний пуш обновил точку входа эксперимента. Со стороны CPU: набор команд RV32IM, машинные CSR и таймерные прерывания, основной исполнительный канал плюс один целочисленный вспомогательный канал, поддержка подходящих пар двойных инструкций; во фронтенде BTB, RAS и предсказание косвенных переходов, в части доступа к памяти двухканальная передача вперёд, пары load/store и обход при попадании в кэш.

Со стороны программного обеспечения — точка внедрения RT-Thread: работает RT-Thread Nano v3.1.5 с командной строкой UART и CoreMark 1.0, дополнительно опциональная пользовательская инструкция cmcrc16. Целевое устройство xc7k325tffg900-2, Vivado 2023.2.

Данные валидации приведены подробнее, чем в обычных любительских проектах: при timingopt15 с 256 строками DCache и идеальной тактовой 180 MHz выполнено 100 поведенческих симуляций CoreMark, 31 445 017 циклов CPU, 30 605 777 выведенных из эксплуатации инструкций, CPI 1.027421, итоговый CRC 0x988c, пройдено 7 направленных регрессий. Недостатки также указаны: после трассировки на 180 MHz WNS составляет -1.371 ns, WHS +0.013 ns, временные характеристики не сошлись, bitstream ещё не сгенерирован; 100 симуляций использовались только для сравнения функциональности и CPI, частота на плате определяется отчётом реализации.

Для RT-Thread смысл этой строки в том, что Nano в очередной раз использован как минимальный рабочий программный стек для валидации CPU — это лучше выявляет проблемы в путях прерываний, переключения контекста и таймеров, чем тесты на голом железе.

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

6.1 Тенденция: на стороне безопасности — от отчётов к предложениям, на стороне тестирования — от списков к коду

За эти 24 часа в основной репозиторий влито 4 коммита (#11977, #11973, #11963, #11957), создано 4 новых предложения (#11979, #11981, #11982, #11983), создано 2 новых дефекта (#11980, #11984). Количество совпадает с прошлым периодом, но структура изменилась: в прошлый раз разбирали накопившееся, в этот раз открывают новые позиции и дополняют инфраструктуру.

Первая линия — два новых отчёта по безопасности, по форме практически идентичных: оба про «отсутствие проверки типа для дескриптора или идентификатора». timerfd не проверяет, является ли fd дескриптором timerfd, POSIX timer не проверяет, не выходит ли id за границы, и оба входа принимают переданное пользователем значение непосредственно как вход в объект ядра. Вместе с обнаруженными в прошлый период отрицательным смещением в графике (переданное пользователем смещение не проверяется на знак) и pipe (пользовательский указатель не проверяется) эти четыре можно отнести к одному классу: слой системных вызовов RT-Smart на шаге «значение → объект» лишён единой проверки. Исправление таких дефектов несложно, сложно найти все входы.

Вторая линия — скорость реакции растёт. #11952 — это отчёт от 29 октября о произвольной записи в разделы блочного устройства, а 3 ноября уже появилось предложение #11981; вчерашняя переработка getaddrinfo (#11977) влита сегодня; патч для pipe продолжает обновляться в очереди. Отчёт, предложение, переработка мейнтейнером, вливание — эти четыре этапа теперь проходят за несколько дней, и по сравнению с прошлым периодом с его оценкой «много отчётов, мало патчей» это явное изменение. Плата за это — давление ревью перешло на сторону мейнтейнеров: в очереди по-прежнему пять позиций на рассмотрении, и по каждой кому-то нужно разобраться в шагах воспроизведения.

Третья линия — список тестов для версии Z начинает давать код. Упомянутый в прошлый период #11972 разложил вопрос «можно ли выпускать версию Z» на пофреймворковые списки QEMU и utest, и в этот период появились три предложения, напрямую на него ссылающихся: виртуальная шина с обратной связью внутри прошивки для SPI (#11979), utest для симулированной шины фреймворка I2C (#11982), а также #11983, добавляющий циклы и сэмплирование памяти к автоматическому запуску (это продолжение #11963, решающее проблему «однократный запуск не выявляет утечки памяти»). В сочетании с влитым сегодня многократно воспроизводимым тест-кейсом mailbox тестовая база на стороне CI движется в сторону «воспроизводимости и наблюдаемости».

Два противоположно направленных действия на стороне экосистемы заслуживают внимания: с одной стороны, производитель чипов скриптовал массовую публикацию репозиториев BSP (вчерашние 12 репозиториев одной версии от HPMicro), с другой — отдельные разработчики дополняют Studio BSP для сторонних плат вроде Wildfire HPM6750 BTB и добавляют BSP в сообщество для старых платформ вроде Nuvoton N9H30. Производитель обеспечивает согласованность между платами, сообщество закрывает длинный хвост покрытия — только вместе эти две стороны и составляют полную картину платформенной экосистемы RT-Thread.

На стороне мероприятий «Новый свет» в Учжэне — самая весомая позиция этого периода: государственная платформа включила «гетерогенную интегрированную базовую AIOS для интеллекта на периферии» в 35 рекомендованных продуктов, и нарратив сместился с «базы реального времени и управления» к «операционной системе интеллекта на периферии» с акцентом на взаимодействие «большого мозга» и «малого мозга» роботов. Появившийся в тот же день материал альянса WTCC — это как раз версия этого нарратива в конкретных сценариях: три типа агентных решений, разделение ролей с Arm Technology, акцент на воплощённом интеллекте. Пропаганда и инженерия идут по одной линии, что в прежних материалах о мероприятиях встречалось нечасто.

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

Форум club.rt-thread.org в этот период по-прежнему возвращает 468 с предварительной страницей вызова WAF, список и тела постов прочитать невозможно, пробел в информации со стороны обсуждений в сообществе восполнен GitHub и колонками СМИ. Официальный интерфейс новостей и список новостей на сайте как застыли на 17 июня, сам модуль новостей на сайте не загружается.

Лимит анонимного API GitHub (60 раз в час) был исчерпан на позднем этапе сбора, для полного проталкивания на уровне организации использовалась проверка Atom-коммитов тринадцати ключевых репозиториев (packages, env, rtthread-nano, sdk, smart-build, UtestRunner, userapps и др.), в пределах окна коммитов нет, проталкивание было только в основном репозитории. У дефекта #11950 получены только заголовок и аннотация, тело не читалось; детали PoC для #11984 и #11980 полностью взяты из тела отчётов, независимое воспроизведение не проводилось, в отчётах формулировки ограничены условиями оригинала (модель QEMU, базовый коммит, затронутые версии).

По китайской стороне Google News за три дня 5 совпадений, включено 2 (учжэньский «Новый свет», материал альянса WTCC), рекламный материал о 11.11 относится к продвижению и выходит за пределы окна, не включён, материал о Шанхайском конкурсе открытого кода уже был в прошлом периоде. По англоязычной стороне два набора запросов дали ноль совпадений. В окне HN Algolia все 5 записей — про сетевой протокол Thread, доски вакансий и поддержку Mbed TLS, к теме не относятся, исключены.

Дедупликация: вчерашнее предложение #11977 влито в этот период, обработано как «прогресс» и учтено одной позицией; #11971, #11954, #11911, #11918, #11947, #11935 были перечислены в прошлом периоде, в этот раз фиксируется только изменение статуса, повторно позициями не становятся; #11978 был закрыт вчера, в этот период не раскрывается.

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

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

Источник Результат проверки
Официальный новостной API (rt_org) За 24 часа новых записей нет, последняя запись остановилась на 2026-06-17
Список новостей на официальном сайте Новостной блок на главной странице по-прежнему за июнь, модуль новостей не загружается
Форумы сообщества Страница с challenge от WAF (HTTP 468), список и текст недоступны для чтения
Коммиты основного репозитория 4 коммита в окне мониторинга, сосредоточены с 11-03 09:04 ~ 13:11
PR основного репозитория Смержено 4 (#11977, #11973, #11963, #11957); создано 4 (#11979, #11981, #11982, #11983)
Issue основного репозитория Создано 2 (#11980, #11984), оба касаются безопасности RT-Smart
Releases и tags основного репозитория Новых нет, последний по-прежнему v5.3.0 (2026-09-10)
Ключевые репозитории RT-Thread org Проверка Atom по тринадцати репозиториям, в окне мониторинга коммитов нет
Поиск по репозиториям GitHub Добавлено 2 репозитория, связанных с RT-Thread (HPM6750 BTB BSP, N9H30 BSP), совпадений по topic — 3
Google News на китайском 5 материалов за 3 дня, включено 2 (Wuzhen Xinguang, материал альянса WTCC)
Google News на английском Ноль совпадений
HN Algolia 5 материалов — все про протокол Thread или вакансии, не по этой теме
Официальная колонка EE Times China 11-03 один материал про Учжэнь, включён
Официальный сайт Всемирной интернет-конференции / Канцелярия по делам киберпространства Открытие выставки и формулировка о 35 проектах «Xinguang», использованы для сверки с официальным материалом

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