Research window: 2026-11-05 08:00 ~ 2026-11-06 08:00 (Beijing time, 24 hours)

Sources: RT-Thread official news API and official website news list, GitHub main repository commits / PR / Issue / releases / tags, RT-Thread org repository push list (the env and sdk repositories had pushes this period), four groups of Google News queries in Chinese and English (via proxy), EETimes China RT-Thread official column, club.rt-thread.org forum (still restricted by the site’s WAF this period)

This Issue’s Index

  • I. Kernel and Version Updates
    • ARM configuration moved out of the common Kconfig: libcpu begins splitting by architecture (11-05)
    • RISC-V Smart’s MMU and user exceptions: four root causes fixed together (11-05)
    • Signal delivery no longer sleeps while holding locks, ELF segment protection order corrected (11-05)
    • Seven driver and tooling commits: SDIO, serial, virtio, NVMe, HID, mkdist (11-05)
  • II. Security Follow-up and Merge Queue
    • ivshmem treats device configuration words as trusted input, /dev node becomes an arbitrary physical memory channel (11-06)
    • Fix out two hours and eleven minutes later: new option cages the JailHouse fallback (11-06)
    • MSI-X validation from pending review to merged: the one reported yesterday lands today (11-05)
    • Eleven out-of-bounds and parameter validation fixes merged in one day (11-05)
    • Queue: forty-eight pending updates, the block device partition one still hanging (11-05)
  • III. Official and Community Activities
    • Titan Board connects to OpenMV: 170 Python examples, NPU runs TFLM (11-05)
    • Env plugin market switched to a serverless index: plugin packages placed in GitHub Release (11-06)
    • Official news API still stuck in June, forum still at 468 (11-06)
  • IV. Ecosystem and Vendor Adaptation
    • ESP32-C3 prebuilt image rejects v1.x chips: minimum version field not aligned (11-05)
    • Five BSP and test infrastructure commits: D1s into QEMU, efm32 into menuconfig, three framework test suites (11-05)
  • V. This Issue’s Trends and Summary
    • Thirty-one commits in one day: backlog clearing replaces incremental progress
    • Trend: device-side input becomes the second main battlefield
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 ARM configuration moved out of the common Kconfig: libcpu begins splitting by architecture (11-05)

Date: 2026-11-05 22:26 (merge time)　Source: PR #11988, Issue #9187

267 lines added, 173 lines removed, three files: a new libcpu/arm/Kconfig is added, and the ARM-related architecture identifiers, core models, and ARM MMU/MPU and GIC configuration from the original libcpu/Kconfig are moved wholesale into the architecture directory, pulled in place via rsource; common capabilities and the cross-architecture KERNEL_VADDR_START stay in the original file. Author zijunteng238-dot opened the PR at 11:51 AM and it was merged at 22:26 that evening—ten and a half hours end to end.

This approach deserves a separate note: it adds no menus, changes no symbols, changes no defaults, and changes no dependencies or select relationships—it only moves things. Verification was not “it compiles, so it’s fine” either—the author used Kconfiglib 14.1.0 to compare all parsed symbols before and after the split, checking configuration values, types, visibility, assignable ranges, defaults, and selection relationships item by item; after excluding file path and line number changes, there were no new parse warnings. The comparison covered five BSPs: frdm-k64f (Cortex-M4), qemu-vexpress-a9 (Cortex-A9), renesas/rzt2m_rsk (Cortex-R52), qemu-virt64-aarch64, and qemu-virt64-riscv, and on RISC-V the author ran scons –menuconfig to compare menu output. In addition, SMART and IOREMAP_LATE were enabled in memory for A9, AArch64, and RISC-V and compared for another round, without writing back to the configuration files.

The long-term maintenance significance lies in the structure: libcpu/Kconfig previously mixed CPU common capabilities with multi-architecture configuration, so any architecture adding an option had to touch the same file, and the probability of conflicts and accidental changes grew with the number of architectures. After this split, the RISC-V and ARM Kconfigs can evolve independently, which is the same governance line as the documented release process in the previous issue—straighten out the structure first, then discuss release cadence. A companion document, documentation/4.tool/scons/libcpu_kconfig_arm_split.md, was added, recording the split scope, dependency handling, and verification results in the repository, so other architectures can be migrated following the same procedure.

1.2 RISC-V Smart MMU and user exceptions: four root causes fixed together (11-05)

Date: 2026-11-05 11:15 (merge time)　Source: PR #11892

109 lines added, 8 lines removed, four files, opened by maintainer BernardXiong on October 18 and merged this issue after 11 inline reviews. This is the most substantive change for RT-Smart on the RISC-V side in this issue.

The change lists four root causes, all different facets of the same class of problem. First, the early page table pointer was not translated by the kernel physical offset, so page table descriptors pointed to the wrong place when the kernel was loaded at a non-zero physical address. Second, each hart’s kernel page table inherited user mappings, effectively leaving address space between harts that should not be there. Third, the early page tables were not cleaned before enabling the MMU. Fourth and most critical: an unhandled user-mode exception would terminate the entire kernel rather than just the current process—a single wild pointer in a user process could bring down the system.

The corresponding fixes are: add XuanTie architecture selection and the SVPBMT option; translate the early page table pointer by the kernel physical offset; allow the MPR range to extend below the linked kernel base address; clean the early page tables before enabling the MMU; clear user address entries from each hart’s kernel page table; terminate only the current LWP on user exceptions; and keep interrupts enabled while reporting user context.

The verification conditions are stated candidly: the BSPs used are qemu-virt64-riscv and bsp/k230, with RT_USING_SMART plus ARCH_RISCV64 configured; the author did not run a local build because the environment lacks a RISC-V musleabi toolchain, and left verification to CI. This is the same kind of candor as the verification note for the serial change in the previous issue—the direction is fine, but runtime behavior on the RISC-V Smart line would be best backed by retesting on real hardware.

1.3 Signal delivery no longer sleeps while holding a lock; ELF segment protection order corrected (11-05)

Date: 2026-11-05 11:16 (merge time)　Source: PR #11895, PR #11899

Both changes belong to the lwp subsystem and were merged by BernardXiong. The first, #11895, touches five files with 58 lines added and 27 removed, including the RISC-V assembly entry lwp_gcc.S, lwp_elf.c, and lwp_signal.c, across three commits. The core issue is ordering: the signal handling path takes a sleeping lock, so it must remain schedulable, and the code uses OPEN_INTERRUPT and CLOSE_INTERRUPT to explicitly enable and disable interrupts in critical sections; it also corrects the order in which ELF segment protection is applied, avoiding write-then-protect.

The second, #11899, is smaller: 16 lines added across two files; sys_sigaction validates the signal number before indexing the action array, rejecting values less than or equal to zero and greater than _LWP_NSIG, returning EINVAL. Patches of this “validate before indexing” kind have appeared several times in recent issues and are products of the same audit batch.

1.4 Seven driver and tool changes: SDIO, serial, virtio, NVMe, HID, mkdist (11-05)

Date: 2026-11-05 (merge time)　Source: PR #11886, PR #11931, PR #11726, PR #11920, PR #11968, PR #11873, PR #11874

Seven medium-sized fixes merged in the same batch, one sentence each:

  • SDIO block size is now set after block configuration completes, avoiding timing inconsistency from setting the size before configuring (#11886, 8 lines changed each way, three files).
  • The serial driver removes the receive callback only when the reference count reaches zero on file descriptor close, so a shared port no longer loses its callback to the first closer (#11931, 9 lines added).
  • The virtio network driver adds RX buffer release when pbuf allocation fails, plugging a leak on the packet-drop path (#11726).
  • NVMe leaked one allocation per inactive namespace during device scan; allocation and release are now paired (#11920, two files).
  • The virtio RPMsg probe failure path adds NS resource release and propagates the error code upward (#11968).
  • USB HID interface descriptor bInterfaceProtocol selection is corrected to be filled in by protocol rather than a fixed value (#11873).
  • The mkdist disk command fixes two problems: duplicate injection of RTT_ROOT in SConstruct, and direct failure when rebuilding dist encounters a directory that cannot be deleted due to permissions (#11874).

Individually none of these seven is large, but together they cover six layers—block devices, character devices, networking, storage, USB, and build tooling—and all landed on the same day, the same wave as the batch merges below.

II. Security Follow-up and Merge Queue

2.1 ivshmem Treats Device Configuration Words as Trusted Input; /dev Node Becomes an Arbitrary Physical Memory Channel (11-06)

Date: 2026-11-06 00:54 (report time)　Source: Issue #11992

Reported by XueDugu, continuing a line he has been pursuing recently on the PCI and device driver side. The problem lies in the ivshmem driver’s probe function: when BAR2 reports a size of zero, the code takes the JailHouse fallback branch and reads the shared memory address and size directly from four dwords at PCI configuration space 0x40 to 0x4f—these four segments are determined by the device side, the driver performs no validation, and then hands them to rt_ioremap, which itself does not check physical address validity.

The consequence chain is short: a malicious or malformed device describes “shared memory” as a kernel memory region, the mapping still succeeds, and the window is then registered as /dev/ivshmemN. Subsequent reads and writes go through two memcpy calls in the official open/read/write path—one copying kernel contents to user space, one writing user data back to the kernel. Thus any unprivileged process that opens this device node gains read/write access to arbitrary kernel physical memory, at byte granularity, with fully controllable data, requiring no special ioctl or extra privileges.

The report also points out an incidental issue: the original code splits a 64-bit field into two 32-bit writes, which on 32-bit builds writes into adjacent fields, effectively corrupting the struct in passing. This is the same pattern as the MSI-X item—values supplied by device firmware are treated as trusted input, while the driver side lacks the fixed “validate before use” action.

2.2 Fix Lands Two Hours and Eleven Minutes Later: New Option Cages the JailHouse Fallback (11-06)

Date: 2026-11-06 03:05 (proposal time)　Source: PR #11993

99 lines added, 7 lines removed, two files, submitted by maintainer BernardXiong, status pending review, with one discussion comment already.

The fix has four layers. The first layer disables the dangerous path by default: a new RT_IVSHMEM_JAILHOUSE option, default n, with help text stating the device must be trusted; when it is not enabled, a missing BAR2 causes probe to be rejected outright, with no further reading of configuration words. The second layer validates before mapping: size is non-zero, address plus size does not overflow, and the entire region can be expressed with local pointer and size types. The third layer corrects types: the four configuration dwords are first read into 64-bit local variables, no longer written to struct fields through 32-bit aliases, incidentally fixing the adjacent-field clobbering. The fourth layer checks the return value of configuration space reads, no longer continuing on read failure.

Verification only extends to compilation and formatting: both option combinations (JAILHOUSE off and on) compile on qemu-virt64-aarch64, and the modified files pass clang-format. From the 00:54 report to the 03:05 proposal, two hours and eleven minutes—a further step up in speed from the six hours of the previous issue’s MSI-X item.

2.3 MSI-X Validation Moves from Pending Review to Merged: Yesterday’s Report Lands Today (11-05)

Date: 2026-11-05 10:47 (merge time)　Source: PR #11986, Issue #11985

The MSI-X fix reported as pending review in the previous issue was merged at 10:47 this issue, with 47 lines added and 5 lines removed, touching only the single file msi.c. The five validations landed as originally proposed: reject out-of-range BIR, reject unallocated BAR or zero size, compare table offset plus table entry count against BAR size, check the return value of configuration register reads, and reject table entry counts exceeding the table size; on the computation side, the physical base address and byte count are promoted to 64-bit to avoid 32-bit addition overflow.

From the 11-04 17:12 report, to the proposal at 02:47 the next day, to the merge at 11-05 10:47, the entire chain closed within two days. The reason for listing it separately this issue: together with the two similar defects below, it forms a continuous sample of the same class of problem—device-side input validation—an area that previously had almost no audit coverage.

2.4 Eleven Out-of-Bounds and Parameter Validation Fixes Merged in One Day (11-05)

Date: 2026-11-05 (merge time)　Source: PR #11941, PR #11935, PR #11899, PR #11895, PR #11970, PR #11971, PR #11962, PR #11918, PR #11558, PR #11901, PR #11986

Of the 31 merges this issue, 11 are directly related to the security line tracked continuously over recent issues, all landing within 24 hours. Besides the three listed separately, the key points of the other eight:

  • Hardening of user pointers in terminal ioctl (#11941, 503 lines added, 57 lines removed, seven files): commands such as TIOCGWINSZ, TIOCSWINSZ, TIOCGPGRP, TIOCGSID, FIONREAD, and TIOCGPTN now first go through a kernel stack buffer and then copyin/copyout, with unrecognized commands returning ENOTTY.
  • Boundary validation and safe unlinking added to the signalfd close path (#11935, 526 lines added, 228 lines removed, 11 files): the largest of this batch, involving slot references and lwp lifecycle, with changes spanning both the libc and lwp subsystems.
  • Framebuffer reads and writes reject invalid offsets (#11970): when the offset is negative or exceeds the plane length, zero is returned directly.
  • pipe ioctl user pointer validation (#11971), the same approach as #11941.
  • ADC channel validation for BlueX AB32 (#11962): channel numbers are restricted to 0 through 15, and conversion failure returns EINVAL.
  • 9PFS client constrains server-controllable lengths to actually received bytes (#11918, 63 lines added): fixes the out-of-bounds read and directory information leak in report #11289, validating record length, name length, and remaining bytes item by item.
  • CFI MTD erase region count and sector table bounds (#11558): a count exceeding the local table causes probe to fail, and a sector count equal to the array length is treated as full.
  • Depth limit added to device tree unflattening (#11901, 72 lines added): a pre-check traversal computes the maximum depth, and anything exceeding 63 levels is rejected outright for unflattening, no longer writing past the fixed stack.

A distribution worth noting: of these 11, usualtreee and maintainer BernardXiong each contributed 3, adilalperenciftci 2, and the remaining 3 came from cms19859230182-lang, Old-Ding, and liangzhan5. Viewed together with the full distribution in 5.1, external contributors have developed a steady rhythm of audit output, and the maintainers’ focus is shifting from “finding problems” to “reviewing patches.”

2.5 Queue: Forty-Eight Pending Updates; the Block Device Partition Item Still Hanging (11-05)

Date: 2026-11-05 (proposal update time)　Source: PR #11981, PR #11990, PR #11989, PR #11987, PR #11897

A total of 48 pending proposals were updated within the window, three of which are worth watching:

The fix for arbitrary kernel writes in block device partitions (#11981) saw another update at 16:03 and remains unmerged. This one has been hanging for three days; the defect itself is that a partition struct pointer passed from user space is dereferenced directly by the kernel—high severity, and it should be prioritized.

Two test infrastructure items are advancing in parallel: #11990 wires DAC and I2C framework tests into QEMU automated runs (20 lines changed, modifying utest_auto_run.yml and adding configuration), while #11989 adds QEMU regression coverage for dlmodule. These two, together with the three framework test suites merged this issue (see 4.2), form a coordinated push.

On the feature side, ulog supports outputting the calling function, file, and line number (#11987, created 14:22); K230D support and Smart improvements (#11897) was created 10-18 and updated at 17:21 this issue—the BSP is the RISC-V K230, on the same line as the Smart fix in 1.2.

III. Official and Community Activities

3.1 Titan Board connects to OpenMV: 170 Python examples, NPU runs on TFLM (11-05)

Date: 2026-11-05 17:30 (column publish time)　Source: EE Times China: Titan can now run OpenMV too, Project: Titan_Openmv

This installment of the official RT-Thread column publishes the Titan Board’s OpenMV project, bringing RT-Thread 5.1, OpenMV 5.0.1, and MicroPython together onto this board based on the Renesas RA8P1: a 1 GHz Cortex-M85 runs the system and applications, a 250 MHz Cortex-M33 handles coprocessing, an Ethos-U55 NPU is clocked at 500 MHz, and 32 MiB of external HyperRAM stores images and runtime memory, with peak AI compute rated at 256 GOPS. On the peripheral side it connects an OV5640 MIPI camera, a FAT/FAT32 SD card, a USB HS CDC and MSC composite device, and the onboard tri-color LED and buttons.

The scale of the examples is the main selling point this time: 170 standalone Python scripts in total, 124 for traditional vision, covering camera control, photo and video capture, drawing, filtering, color tracking, barcodes, feature detection, and AprilTag; and 23 for machine learning, paired with 20 model files targeting the Ethos-U55-256 plus one numerical regression model executed on the CPU, with tasks covering gestures (rock-paper-scissors, palm detection, 21-point hand keypoints), face and pose (face detection, 468-point keypoints, human pose), object recognition (pedestrians, cats and dogs, common COCO80 objects), and image classification and segmentation.

The project organization is genuinely helpful for getting started: the code lives in the SDK’s project/Titan_Openmv and supports both RT-Thread Studio and SCons; the build produces two files that must be used together—rtthread.hex is flashed via DAP-Link or J-Link, and openmv-vision.bin is transferred via the USB composite device, and the two must come from the same build. Models and labels go in models/sdcard/ and just need to be copied to the SD root per the instructions; /rom in scripts is a read-only alias for the SD root, so no separate directory is needed; to make a project auto-start on boot, save the application as main.py in the SD root. The article also specifically warns that the AE3 shown in the IDE is only a protocol compatibility identifier and that Alif AE3 firmware must not be flashed—the board uses this project’s RA8P1 firmware.

Two technical judgments: first, this combination strings “camera capture, image processing, neural network inference, peripheral control” into a single Python script, lowering the barrier to edge vision from writing C drivers to changing parameters; second, operators are split between CPU and NPU according to support, with TFLM handling scheduling, meaning whether a model can run depends on operator coverage—the 20 models in the examples are themselves a usable coverage list.

3.2 Env plugin marketplace moves to a serverless index: plugin packages go into GitHub Releases (11-06)

Date: 2026-11-06 07:05 (merge time)　Source: Proposal env #304, Proposal sdk #11, Index directory env-plugins

The same batch of changes across two repositories: the sdk repository adds an env-plugins directory holding an index.json as the plugin catalog, with each plugin in its own subdirectory holding its own index.json; the env repository implements reading this “serverless index” and downloading .epack installers from GitHub Releases. On the env side, 1108 lines added and 48 deleted across 18 files, including marketplace logic, WebUI frontend pages, command-line subcommands, and five groups of tests; on the sdk side, 125 lines added across four files.

The externally visible change is in how it is used: by default the index is read from the local SDK repository, with no marketplace server to deploy; plugin packages are published in GitHub Releases; explicitly setting an environment variable or running rt-env plugin market set still takes priority and uses the HTTP marketplace, while rt-env plugin market clear can wipe the HTTP configuration from the file and fall back to the SDK source, with environment variables always highest priority. The first listed plugin is the RT-Kconfig configurator 0.1.34, and the download record in the index points to a real .epack asset in that repository’s Release, not a placeholder entry.

The security side is more thorough than expected: download size is capped, returning 413 when exceeded; redirects must be same-host and same-protocol, and jumps to unexpected domains are rejected outright; index paths cannot escape the env-plugins directory; plugin ids have a regex constraint and duplicates are detected. Accompanying commits wire plugin regression tests into GitHub Actions and build the bundled epack before the CI packaging tests. The practical significance for the ecosystem is that third-party plugins no longer have to wait for official marketplace review and servers—publishing a Release plus one index entry is enough to distribute—at the cost of moving the trust boundary from “official marketplace” to “repository maintainer.”

3.3 Official news endpoint still stuck in June, forum still 468 (11-06)

Date: 2026-11-06 (verification)　Source: RT-Thread official news list

The latest entry returned by the official news endpoint getList?type=rt_org is still the 2026-06-17 “RT-Thread Ruisaide Technology invited to attend the 2026 Abu Dhabi Investment Forum,” with nothing new this period; the news section on the official homepage is likewise stuck in June. This is the same conclusion for several consecutive periods—the focus of official external publishing has stabilized on media columns and GitHub.

The forum at club.rt-thread.org still returns 468 this period with a WAF challenge page in front, so post lists and bodies cannot be read directly. On the community discussion side, only GitHub issue and PR comments can fill the gap—this period’s three discussions in #11992 and #11993 were obtained exactly this way.

IV. Ecosystem and Vendor Adaptation

4.1 ESP32-C3 Prebuilt Images Reject v1.x Chips: Minimum Revision Fields Not Aligned (11-05)

Date: 2026-11-05 23:24 (report time)　Source: Defect #11991

Reported by anamarija-j, with affected versions listed as v5.3.0 and master cbadbdf. The hardware is an ESP32-C3, chip revision v1.1 (ROM version esp32c3-eco7-20230720), and the BSP is bsp/ESP/ESP32_C3. This is the only regression defect in a RISC-V BSP in this issue.

The symptoms come in two stages: esptool refuses to flash outright, reporting that the prebuilt bootloader.bin requires chip revision 3 or higher, while this board is revision 1. After forcing the flash with –force, the second-stage bootloader starts but halts before reading the partition table, with the log stating that the chip is V101 and the minimum revision configured by the application is 3.

The root cause lies in field semantics: the prebuilt bootloader only populates the legacy min_chip_rev field (value 3), while the full field min_chip_rev_full is 0. This ESP-IDF v5.0-dev bootloader happens to compare the legacy field against the minor version number, and v1.1 has a minor version of 1, so the check fails. The BSP’s SConstruct likewise only sets image.min_rev = 3, so the generated rtthread.bin carries the same problem. In other words, the same “minimum revision” is expressed through two sets of fields, old and new, but both the prebuilt artifact and the build script only write the old one, so they stall on chips interpreted under the new rules.

The practical impact is significant: the ESP32-C3 is one of the most common RISC-V wireless MCUs in the RT-Thread ecosystem, and unusable prebuilt images mean new users fail on their very first board bring-up and must build from scratch. The fix is not complicated—write min_chip_rev_full in both SConstruct and the prebuilt artifacts—but it requires repackaging as well.

4.2 Five BSP and Test Infrastructure Commits: D1s in QEMU, efm32 in menuconfig, Tests for Three Frameworks (11-05)

Date: 2026-11-05 (merge time)　Source: PR #11903, PR #11867, PR #11883, PR #11982, PR #11976

Two BSP-side commits, both in the “make the board easier to use” direction. Allwinner D1s gains a qemu-d1s.sh launch script, so this BSP can run directly on the d1s QEMU machine type, eliminating the need to hunt for images and assemble parameters (#11903). EFM32 gains Kconfig and .config, officially supporting scons –menuconfig; previously configuration could only be edited by hand (#11867).

Three test infrastructure commits, all in the same direction: adding mock-device tests to the frameworks themselves. The watchdog gains a smoke test that tolerates timeout quantization error and non-stoppable shutdown paths (#11883, corresponding to defect #11446); I2C uses a mock bus to cover the framework layer without depending on real hardware (#11982); DAC is tested with a mock device (#11976). All three were submitted by community contributors, and together with the pending QEMU autorun rework in 2.5, a clear move is visible: shifting driver framework validation from “waiting for hardware” to “entering CI.”

5.1 Thirty-one PRs in One Day: Clearing the Backlog Replaces Incremental Progress

The main repository merged 31 proposals in the 24-hour period, the largest single-day batch in recent memory. The timing was highly concentrated: 17 merged within 31 minutes between 02:47 and 03:18 (10:47–11:18 Beijing time), another 13 between 05:23 and 10:40, and the final one—the ARM Kconfig split—landed separately at 22:26.

The composition of the batch shows this was not “written today, merged today”: many are old proposals opened in mid-to-late October—#11892 and #11897 opened the same day (10-18), #11901 opened (10-19), #11918 opened (10-22), #11935 and #11941 opened (10-28), #11947 opened (10-29), and the oldest, #11558, opened on July 5. In other words, a backlog spanning four months landed all at once after a concentrated review. The implication for downstream users: pulling master over these two days will surface a large wave of changes, concentrating regression-testing cost rather than spreading it across days.

Another signal is the structure of mergers. Of the 31, usualtreee merged 7, BernardXiong 5, cms19859230182-lang 4, and adilalperenciftci 2, with the remaining 13 coming from different contributors. The division between review and submission is now fairly clear: external contributors supply patches, maintainers validate and batch-merge.

5.2 Trend: Device-Side Input Becomes the Second Main Battleground

Looking across the last four issues, the attack surface is shifting. Late October to early November reports were mostly missing validation of “value-to-object” at the syscall layer: nested user pointers in getaddrinfo, the ioctl pointer in pipe, timerfd, and raw pointers in block device partitions. This issue’s two new defects change the premise—MSI-X requires plugging in a malicious device, and ivshmem requires a device to fill a config word with a kernel address. The common thread: registers supplied by device firmware are treated by the kernel as trusted input, and rt_ioremap performs no physical-address validity check, so “whatever the device says gets mapped.”

Response speed is another thread: MSI-X went from report to proposal in 6 hours and to merge in two days; ivshmem went from report to proposal in 2 hours 11 minutes. Reporters supplied complete material—with PoC, logs, and version tracing—so maintainers could patch directly, which compresses fix time more effectively than process rules. The cost is a growing queue: 48 updates awaiting review, and the block device partition fix has been pending for three days without merging.

A third thread is structure and tooling advancing in parallel: libcpu/Kconfig is being split by architecture, version numbering and the release process are now documented, Env’s plugin distribution is moving from a centralized marketplace to “repository index plus Release,” and testing is shifting from waiting for hardware to running in CI. These four items are not on the same track, but all replace “relying on people to remember” with “relying on structural constraints.”

5.3 Limitations and Deduplication Notes

The forum still returns 468 with a fronting WAF challenge page, so the community-discussion gap was filled by GitHub; both the official news API and the website’s news list remain frozen at June 17, with no additions for several consecutive issues. The column aggregation page of Electronics Engineering Album did not yield a list via direct access this issue; the Titan item was obtained by matching the headline via Google News and then verifying the body text and publication time through web extraction.

On the GitHub side, collection this issue hit the anonymous API rate limit (60 per hour) late in the process. The main repository’s merges, defects, and pending-review list, plus commits in the two affiliated repositories, were all verified, but topic searches outside the organization were not run this issue, so minor updates to a few community repositories may not be captured; this is stated as-is, with no speculative additions.

Deduplication: #11986 was recorded as pending review last issue and is now recorded as merged with the timeline noted; #11981 was listed last issue and only its status is recorded here; #11897 appeared in the queue last issue and only its update time and RISC-V association are recorded here; Titan’s engineering code entered the repository on 10-30, and what is covered this issue is the official release note and engineering description from 11-05, not double-counted as a code update.

Appendix: Source Verification Table and Source List

Source Verification Table

Source Verification Result
Official news API (rt_org) No new items in 24 hours; latest entry remains at 2026-06-17
Official website news list News section on homepage still shows June; no new items
Community forum Fronted by WAF challenge page (HTTP 468); list and body content unreadable
Main repo commits Pushes within the window concentrated in three waves from 11-05 02:47 to 14:26 (UTC)
Main repo PRs 31 merged; 48 pending review updates
Main repo Issues 2 new (#11992 ivshmem, #11991 ESP32-C3)
Main repo releases and tags No new items; latest remains v5.3.0 (2026-09-10)
RT-Thread org repos 35 repos checked; pushes in three: main repo, env, sdk
env and sdk repos env merged plugin directory proposal (18 files); sdk published first plugin index
Google News Chinese 4 items within 3 days; only the 11-05 Titan OpenMV article is new for this issue and included
Google News English Zero valid hits
HN Algolia All 7 items were Thread networking protocol, recruiting, or unrelated content; excluded
EET-China official column One Titan OpenMV article on 11-05; included
Repo search (topic:rt-thread) Not executed this issue due to anonymous API rate limits; see 5.3

Full Source List