Research window: 2026-11-04 08:00 ~ 2026-11-05 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, GitHub repository search (topic:rt-thread and rt-thread keyword), Google News five query groups in Chinese and English (via proxy), HN Algolia, Electronic Engineering Album RT-Thread official column, Espressif official press releases, club.rt-thread.org forum (still restricted by the site’s WAF this issue)

Issue Index

  • I. Kernel and Version Updates
    • Version numbering and release process documented for the first time: Z versions monthly, Y versions every 3 to 6 months (11-04)
    • Serial TIOCGWINSZ changed to query the device directly: no longer borrows tshell to read characters (11-04)
    • GPT partition head-tail inversion validation added: underflowing giant partitions are no longer registered (11-04)
  • II. Security Follow-up and Pending Merge Queue
    • MSI-X table BIR and offset not validated; malicious PCIe devices can write to arbitrary physical addresses during probe (11-05)
    • Fix proposal issued 6 hours after report: five validations completed in one pass (11-05)
    • Queue: block device partition patch updated again, four items still pending (11-05)
  • III. Official and Community Activities
    • Ruiqing RK3576 desktop pet: the board handles listening and speaking, the PC handles thinking (11-04)
    • Official news API still stuck at June; media column is the only stable outlet (11-05)
  • IV. Ecosystem and Vendor Adaptation
    • RT-Thread embedded into ESP-IDF on ESP32-S31: all 36 self-checks pass (11-04)
    • coact: one header file connects RT-Thread, FreeRTOS, and Linux simultaneously (11-04)
  • V. Trends and Summary for This Issue
    • Trend: attack surface shifts from syscall parameters to device firmware
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 Version numbering and release process documented for the first time: Z releases monthly, Y releases every 3 to 6 months (11-04)

Date: 2026-11-04 10:44 (merge time)　Source: PR #11955, Issue #11956

751 lines added across 14 files, all documentation: bilingual (Chinese and English) “Version Numbering Rules and Implementation Details” and “Release Process,” with 7 flowcharts, registered in the Doxygen index and published alongside the documentation center. Author kurisaW, opened October 30, merged at the start of this window. The documents themselves are marked version 1.0, dated 2026-10-27.

The core of the rules is putting the release cadence into numbers: Z patch releases in principle one per month, Y minor releases every 3 to 6 months depending on feature accumulation and maintenance resources, X major releases not on a fixed cycle. Version numbers use vX.Y.Z and must match RT_VERSION_MAJOR/MINOR/PATCH in the source, the Git Tag, the Release, and deliverable names; routine commits do not bump the version number, and development snapshots may only be identified by the target version plus the full SHA.

The tier criteria are more detailed than any previous attempt. X is triggered by a kernel change, a device model or driver framework change, coordinated upgrades of multiple core subsystems, and API, ABI, Kconfig, or boot-flow changes that force existing projects to migrate. Y requires “new kernel or component APIs, a new set of BSPs forming an independent deliverable capability, or multiple small features combining into a complete verifiable set,” with an explicit statement: a single scattered feature, a local parameter extension, or a single implementation optimization does not automatically trigger Y. Z covers only defects, security, performance, single-BSP adaptation, and documentation, and must not introduce new public APIs, components, or driver frameworks—if a single BSP brings in a new driver framework, it must go to Y or X. When a release mixes multiple change types, the highest tier wins (X over Y, Y over Z), regardless of commit count, PR count, or lines of code.

Several points in the implementation details are most useful downstream: once a Y cycle is set it must be written into the version goals, and features not fully validated within the period are deferred; roughly one month before a Z release, the tree enters fix convergence, and roughly one month before a Y release, it enters feature convergence and freezes X.Y; after an official release, any issue found can only be addressed by releasing X.Y.Z+1, and the original Tag, Release content, or deliverables must not be modified; Y and Z releases that change default behavior or resource usage must state so in the Release notes. The accompanying “Release Process” splits a release into six stages—version preparation, setting preliminary goals for the next version, development preparation, development, pre-release, and release—with the pre-release part covering feature convergence, BUG regression, and test case templates grouped by architecture and BSP.

Notably, the document examples uniformly use v6.0.0, v6.1.0, v6.1.1, indicating the next mainline is planned as the 6 series. Previously the 5.2-to-5.3 interval and the Z cadence existed only in practice; this is the first time the cadence, the criteria, and the rule that Tags are immutable after release have been written into formal in-repo documentation—directly usable evidence for downstream distributions and commercial editions assessing upgrade costs.

1.2 Serial TIOCGWINSZ now queries the device directly: no longer reads characters via tshell (11-04)

Date: 2026-11-04 21:33 (merge time)　Source: PR #11891

136 lines added, 153 deleted, touching dev_serial.c, dev_serial_v2.c, and serial_tty.c across four commits; opened by maintainer BernardXiong himself on October 18 and merged this period.

The old implementation had two problems. First, it only worked in the tshell thread: it relied on finsh_getchar() to read the terminal’s CSI response, and calls from non-tshell threads simply got 80x24. Second, it consumed input—the response came in through the shell’s input channel and could swallow characters the user was typing. In addition, termios unconditionally called ops->configure on every setting change, so even pure software parameter changes would reset the UART FIFO.

The new approach writes the query command directly to the serial device (five bytes, CSI 18 t), reads the response byte by byte with a total wait of 200 ms, stopping at ‘t’; the response must strictly match the CSI 8;rows;cols t shape, with rows and columns limited to 1–999, and any mismatch falls back to the default 80x24 instead of loosely parsing with atoi. The v2 version adds one more step: during the query it temporarily sets the RX timeout to RT_WAITING_NO so a non-responding terminal cannot block the read forever, restoring it afterward.

On the termios side it now compares before configuring: if the new configuration is byte-for-byte identical to serial->config, ops->configure is not called; on the tty side, when opening the serial port it checks whether it is the console, and if so queries the window size once before installing bypass, so the response stays in the raw receive queue and does not become input. The old ioctl switch that only returned ENOSYS is also removed.

The validation conditions are stated plainly: BSPs used are bsp/k230 and bsp/qemu-virt64-aarch64; the author did not run them locally, citing the absence of a RISC-V musleabi toolchain in the environment, leaving compilation to CI. Commits like this—thought through on only one architecture and backed by CI—are not rare in the serial layer, but the direction is right: terminal size is a device property and should not depend on the existence of a particular shell thread.

1.3 GPT partition start/end inversion now validated: underflowing giant partitions no longer registered (11-04)

Date: 2026-11-04 21:30 (merge time)　Source: PR #11978, Bug #11271

11 lines added, 5 deleted, changing only efi.c in block device partition parsing. This is a redo of the previously closed PR #11275.

is_pte_valid() previously only required starting_lba and ending_lba to fall within the disk range, without checking that ending_lba is not less than starting_lba. A crafted GPT image with a valid CRC could make size = ending_lba - starting_lba + 1 in efi_partition() underflow as unsigned, yielding an astronomical partition size that gets registered as a logical partition. The fix is two steps: add an end-less-than-start check in is_pte_valid() to reject outright; and move the start and size computation after the validity check, deriving size from the already-validated start so the underflowing expression is never evaluated.

One correction: the previous report marked #11978 as “closed” based on its PR status, but the actual merge timestamp is 11-04 21:30 (Beijing time), within this window, so it is recorded here as merged. The corresponding bug #11271 was opened on March 19, so more than seven months passed from bug to merge.

II. Security Follow-up and Merge Queue

2.1 MSI-X Table BIR and Offset Not Validated: Malicious PCIe Devices Can Write to Arbitrary Physical Addresses During Probe (11-05)

Date: 2026-11-05 01:12 (report time)　Source: Issue #11985

The reporter is again XueDugu, against baseline master 5d1fb66d (v5.4.0-dev, 2026-10-15), with the affected range stated as since v5.2.0, introduced by 2168ed8e7 (the initial merge of the PCI/PCIe bus framework) on 2024-05-30.

The problem lies in msix_table_remap(): it reads the device-side read-only register MSI-X Table Offset, treats the low three bits as the BIR, and uses that directly to index pdev->resource[]. That array has only 6 entries, yet the BIR is masked with 0x7, so values 6 and 7 can be produced. A value of 6 aliases exactly onto pdev->rom, which sits adjacent in the struct—for devices without an option ROM, this member is {base:0, size:0, flags:0}. Since PCI_BUS_REGION_F_MEM is 0, the “BAR not allocated” check (flags ANDed with F_NONE) actually passes, so table_base_phys = 0 plus the offset becomes an absolute physical address entirely determined by the device, 29 bits wide, enough to cover all memory on the reference board.

Two other checks are also missing: table_offset can be as large as 0xFFFFFFF8 and is never compared against the BAR’s size; entries_nr comes from a separate read of the MSI-X Control register, so a device returning different values on the two reads can make the final loop—which writes 0x80000000 to each table entry—run past the mapped region, up to 2048 entries, 32 KB. More critically, rt_ioremap() itself performs no physical-address validity check, so the forged mapping succeeds.

The reproduction chain is complete: with the official qemu-virt64-aarch64 default configuration (RT_USING_PCI, RT_PCI_MSI, RT_PCI_ECAM, RT_NVME_PCI, RT_PIC_ARM_GIC_V2M all enabled), a locally patched QEMU nvme model forges the device-side MSI-X Table Offset as 0x4023f06e—that is, the address of rt_interrupt_enter_hook, 0x4023f068, ORed with BIR 6. At boot, pci_nvme_probe proceeds through msix_capability_init and msix_table_remap in turn, and the kernel then writes the MSI doorbell value 0x08020040 into that physical address; on the next interrupt trigger, the EPC in the exception log is 0x08020040, and the system enters an infinite loop. The report provides GDB watchpoints, console logs, and before/after memory comparisons; the attack group’s three runs produced byte-identical results.

The characterization is restrained: CVSS 3.1 is 6.8 (AV:P), the score held down by the physical-access or peripheral-supply-chain precondition, but the technical consequence is kernel arbitrary physical memory read/write at boot. The attack precondition is a malicious or tampered PCIe device (an NVMe drive with malicious firmware, a swapped peripheral, an exposed M.2 slot), requiring no software privilege or user interaction. It is associated with CWE-787, CWE-129, and CWE-20, and v5.2.0 through v5.3.0 as well as master are all verified affected. The reporter also notes that the PCI framework has had no security audit coverage before this, and that this finding does not overlap with any existing report.

2.2 Fix Proposal Six Hours After the Report: Five Checks Added at Once (11-05)

Date: 2026-11-05 07:21 (proposal time)　Source: PR #11986

47 lines added, 5 removed, touching only the PCI MSI-X core file msi.c; submitted by maintainer BernardXiong, still pending review.

The five checks correspond to the three gaps and two details in the report: reject outright if the BIR is greater than or equal to the resource array length; reject outright if the BAR is marked unallocated or its size is 0; require table_offset plus entries_nr times 16 to fall entirely within the BAR (also normalizing table_offset with the PCIM_MSIX_TABLE_OFFSET mask); check the return value of the config-register read and stop on failure; and reject when nvec exceeds table_size, preventing a device from returning inconsistent table sizes across two reads. On the computation side, table_base_phys and table_bytes are promoted to 64-bit to avoid the addition overflowing at 32 bits.

Verification stops at compilation: bsp/qemu-virt64-aarch64 with RT_USING_PCI and RT_PCI_MSI enabled passes under xPack aarch64-none-elf-gcc 13.2.1; no attack reproduction was performed. From report at 01:12 to proposal at 07:21—six hours and nine minutes—this is the fastest “report to patch” turnaround in this topic so far.

2.3 Queue: Block Device Partition Patch Updated Again, Four Still Pending (11-05)

Date: 2026-11-05 (proposal update time)　Source: PR #11981, PR #11954, PR #11971, PR #11983

The block device partition user-pointer hardening covered in the previous issue (#11981, addressing the arbitrary kernel write in issue #11952) was updated again at 11-05 07:34 and remains unmerged; the approach is unchanged: in user-mode context, copy the partition data to the kernel stack first, then copy it back with lwp_put_to_user(), returning -EFAULT for invalid pointers without writing.

Status of the other three in the queue: the poll and epoll counter multiplication wraparound (#11954) updated 11-05 00:04; pipe ioctl user-pointer hardening (#11971) updated 11-04 14:57; the utest proposal adding loop and memory sampling to the autorun (#11983) updated 11-04 12:44—all three pending review. #11978, merged in the previous issue, is closed out in this issue, and #11977, #11973, #11963, and #11957 are all closed; the backlog has not continued to grow.

III. Official and Community Activities

3.1 Ruiqing RK3576 Desktop Pet: The Board Handles Listening and Speaking, the PC Handles Thinking (11-04)

Date: 2026-11-04 13:54 (column publish time) / 2026-11-04 20:00 (livestream time)　Source: EET-China: Ruiqing Platform, Raising a Blue Whale with RK3576

The official RT-Thread column published an engineering retrospective on 11-04, describing how the blue whale from DeepSeek Harness was ported to an RK3576 with a small screen: press KEY5, say a sentence, it goes “diii,” and a few seconds later replies in the voice of the big fat fish, with the eyes on screen moving along. A live hardware demo was held the same day at 20:00 in the Ruiqing tech livestream room.

The division of labor is spelled out clearly: the board handles listening and speaking, the PC handles thinking. On the board side, an RK3576 pairs with an ES8388 sound card, recording via arecord and playback via aplay, both on hw:0,0; expressions don’t use the GPU, nor do they run Qt or LVGL—instead they mmap /dev/fb0 and write pixels directly. The persona, memory, tools, and model all live on the PC’s DSH Desktop; the board stores no API Key and does no inference, so if the PC isn’t powered on, it goes mute.

A single conversation round is split into seven steps: evdev reads KEY5, then plays a prompt tone and starts recording; arecord records at 16 kHz, S16_LE, stereo into WAV; voice-once multipart POSTs the file to the relay service’s /v1/voice-turn; server.mjs strips the WAV header, converts to f32 PCM, and sends it to ASR; session.prompt returns only “accepted,” while the body is polled from session.history until stable; spokenForTts picks only the text inside 【】 and hands it to Edge TTS to synthesize mp3; the board uses mpg123 to convert to WAV, sox to resample to 48 kHz, and aplay to output sound, while switching frames according to the expression marker in the response headers.

Why a bridge layer is needed in between—the article gives two concrete reasons: api.deepseek.com only has a text interface, with no /v1/audio/ series endpoints, so a direct board-side connection can’t assemble a voice pipeline; and session continuity requires a fixed DSH_SESSION_ID, so if voice opened a new session, the persona and context would all change. The bridge is blocking, and the board-side curl carries a 180-second timeout, hanging from the keypress all the way until the audio comes back.

The three pitfalls are more valuable than the conclusions. First, a single keypress ran two conversation rounds—when the daemon is killed, child processes don’t necessarily die with it, and two processes read the same event7 simultaneously; the fix is flock single-instance, EVIOCGRAB exclusive device access, and clearing orphan processes by /proc fd at startup—miss any one of the three and it reproduces. Second, streaming TTS truncates; the DSH_VOICE_TTS_SSE switch in the code defaults to off, with the comment literally reading often truncates—early on it synthesized as soon as the first segment arrived, yielding only 10 KB per sentence; after changing to “synthesize only when consecutive polls show unchanged content and at least two Chinese characters of spoken text,” the size reached 115 KB. Third, expressions have two priority tiers: idle, listening, and speaking are 0, emotions are 1; when 1 is locked, 0 requests are simply ignored, and the lock must automatically return to idle on expiry, otherwise after playing confused it stays stuck on the last frame.

The value of this piece is that it turns “keep real-time IO on the board, put inference on the side with more compute” into a reproducible seven-step pipeline—the same idea as the division of labor in the Wuzhen “Xinguang” article, where AI is on the Linux side and control is on the RT-Thread side, except this time inference was moved to the PC. Future plans include an LVGL interface, an interrupt mechanism, and LLM-controlled hardware.

3.2 Official News API Still Stuck in June; Media Columns Are the Only Stable Outlet (11-05)

Date: 2026-11-05 (verification)　Source: RT-Thread Official News List

The latest entry returned by the official news API getList?type=rt_org is still the 2026-06-17 “RT-Thread Ruisaide Technology Invited to Attend the 2026 Abu Dhabi Investment Forum,” and the news section on the official homepage is likewise stuck in June, with no new items this issue; the list area of the official site’s news module still requires checking against the API to read in full.

The actual publishing outlet has stabilized on media columns: this issue, the RT-Thread account on EET-China updated with one Ruiqing desktop pet article, which has been included. The forum club.rt-thread.org still returns 468 behind a WAF challenge page, so post lists and bodies cannot be read directly; on the community discussion side, we can only cross-verify via GitHub and columns.

IV. Ecosystem and Vendor Adaptation

4.1 Putting RT-Thread inside ESP-IDF on ESP32-S31: All 36 Self-Tests Pass (11-04)

Date: 2026-11-04 20:56 (push time)　Source: Repo: esp32s31-rtthread, Espressif: ESP32-S31 release announcement

A repository that ports RT-Thread 5.4.0 to the ESP32-S31. Rather than the usual BSP form, it packages itself as an ESP-IDF v6.1 component: component/ is dropped directly into esp-idf/components/rtthread, replacing the FreeRTOS kernel; patches/ uses git apply to modify 10 files of IDF itself, about 440 lines, including the freertos Kconfig and CMakeLists, the boot flow, the interrupt stack and heap segment definitions in the linker script, plus newly added RISC-V trap entry and flash cross-core hooks; project/ holds only the example application. The RT-Thread source stays unmodified, pulled at a fixed commit 9e6dec3b for 5.4.0 by script.

The capability list is concrete: scheduling, threads, semaphores, mutexes, events, mailboxes, message queues, software timers, and both dynamic and static objects are all present; SMP dual-core scheduling (independent tick per core, independent interrupt stacks, IPI), CLIC interrupts with hardware nesting, the interrupt watchdog, FinSH’s 22 commands, and heaps in internal DRAM plus 16 MB PSRAM all work. On the peripheral side, UART, GPIO and pin interrupts, three I2C channels, SPI (polling, not a full bus framework), two 17-bit ADC channels, eight LEDC PWM channels, MCPWM complementary output with dead time, four GPTimer channels, PCNT, RMT, and TWAI are all wired up; on the wireless side, Wi-Fi 2.4 GHz can connect and obtain an IP and can scan, and the BLE controller plus NimBLE work; not ported are I2S, SD/MMC, LCD, camera, touch, Ethernet, hardware crypto, and low power.

On-board results: all 36 self-tests pass with 0 failures, both cores are running threads, and Wi-Fi connects and obtains an IP with dual-core enabled. Three non-obvious design points in the article are worth noting: CONFIG_FREERTOS_UNICORE=y does not contradict “dual-core” — these two macros describe whether FreeRTOS schedules across multiple cores; with y, IDF does not call start_other_core, leaving the second core for RT-Thread to start itself, whereas setting n would cause entry() to never be called at all; CPU1 must first set mstatus.FS to 3, because the trap entry unconditionally saves f0 through f31 when the float width is 32, and FS is 3 when the thread stack frame is constructed but 0 when CPU1 powers on, so without this fix the first float save fails.

Background: the ESP32-S31 was released by Espressif on March 26, 2026: dual-core 32-bit RISC-V, up to 320 MHz, Wi-Fi 6, Bluetooth 5.4, 802.15.4, with the official software stack being ESP-IDF plus FreeRTOS. This project swaps out the kernel while keeping IDF’s wireless firmware and drivers, effectively validating the pluggability of another kernel on a chip where the vendor offers only one RTOS. Its positioning is stated honestly: host and multi-architecture ports are only test references; the product target remains single-core MCUs.

4.2 coact: One Set of Headers Works with RT-Thread, FreeRTOS, and Linux at Once (11-04)

Date: 2026-11-04 22:35 (push time)　Source: Repo: coact

A C++17 active-object and hierarchical state machine framework by DeguiLiu, MIT licensed, currently at 98 stars. The model follows the QP/C++ approach: events replace threads, behavior is written as hierarchical state machines, transition tables are constexpr, and nothing is allocated at runtime; the same headers run on RT-Thread and FreeRTOS and also compile on Linux and Windows through a PAL, with host used only as a test reference.

It encodes three properties as structural constraints rather than slogans. Bounded: every queue, memory pool, and batch size is a compile-time constant — no heap, no new and delete, no dynamic registration — so worst-case flash and RAM usage is determined at link time, and the repo ships a footprint script for Renode. Detectable: submission results come back as SubmitResult return codes, plus Monitor counters, Breaker::level(), and fatal_assert handling, so a failure shows at the point of occurrence which active object and which partition it belongs to. Recoverable: each active object has a circuit-breaker state machine with five states — Normal, BrokenL1, BrokenL2, Safe, Recovering — with recovery conditions explicitly defined as cooldown time, sustained low watermark, successful probe, and a consecutive healthy window; the example gives the complete implementation of a safety supervisor.

Its significance for RT-Thread lies in application-layer methodology. Most projects in the ecosystem build logic directly out of threads plus message queues, and state machines are often hand-written as switch statements, lacking a framework that constrains boundedness, observability, and recoverability together; this implementation makes the critical section an injectable interface — interrupt disabling on the RT-Thread side, task critical section plus ISR masking on the FreeRTOS side — and the ISR path takes no locks and does not depend on libatomic, with single-core MCUs as an explicit design point.

5.1 Trend: The attack surface shifts from syscall parameters to device firmware

In this issue’s 24-hour window, the main repository merged 3 pull requests (#11955, #11978, #11891), opened 1 new proposal (#11986), and opened 1 new defect (#11985). The volume is lower than last issue, but each of the three threads shows substantive change.

The first thread is a shift in attack surface on the security side. Recent issues have all reported missing “value-to-object” validation at the syscall layer: nested user pointers in getaddrinfo, the ioctl pointer in pipe, timerfd accepting arbitrary fds, out-of-bounds ids in POSIX timers, and raw pointers in block device partitions. All of these defects presuppose “a non-privileged process exists.” This issue’s MSI-X defect changes that premise to “a malicious device is plugged in”: a read-only configuration register supplied by device firmware is treated by the kernel as trusted input, and a one-bit out-of-bounds BIR aliases onto the rom member, which in turn turns the mapping base address into an arbitrary physical address. The CVSS score is therefore only 6.8, but the consequence is likewise arbitrary kernel write during the boot phase. Beyond RT-Smart, the PCI framework is equally affected on MCUs, which shows that device-side input validation is a less-scrutinized area than syscalls.

The second thread is response speed. Reported at 01:12, proposal at 07:21 — six hours; last issue’s block device partition was reported on October 29 and a proposal appeared on November 3 — five days. The reporter supplied complete material with a PoC, GDB logs, and version tracing, so the maintainer could act on it directly; this shortens fix time more than any process rule could. The cost is that review pressure keeps building: four items remain in the queue awaiting review.

The third thread is version governance landing as documentation for the first time. The 751-line version numbering and release process fixes Z to monthly, Y to three to six months, and X to irregular intervals, and further stipulates that Z must not introduce new public APIs, that original tags must not be modified after release, and that the Y cadence must be written into version goals. For downstream distributions and commercial versions, this is a direct basis for judging whether to follow an upgrade and how much migration cost it will incur — more reliable than verbal promises in release notes.

On the ecosystem side, two moves in opposite directions are both worth watching: on one hand, the community squeezes RT-Thread into a new chip that only ships FreeRTOS (ESP32-S31), replacing the kernel as a component while retaining the vendor’s wireless stack; on the other, a C++ framework like coact brings the mature active-object and hierarchical state machine paradigms into the RT-Thread application layer. One validates the kernel’s pluggability, the other fills in application-layer methodology. On the events side, the Ruiqing desktop pet provides a minimal reproducible sample of “real-time IO on the board plus inference on the PC,” which is the same line as the hybrid deployment narrative in the Wuzhen “Xinguang” piece.

5.2 Limitations and Deduplication Notes

The forum at club.rt-thread.org still returned 468 this issue with a WAF challenge page in front, so the post list and bodies could not be read; the gap on the community discussion side is filled by GitHub and media columns. Both the official news API and the news list on the official website remain stalled at June 17, with no additions this issue. The column aggregation page on EETop timed out on direct connection; the Ruiqing desktop pet item was verified by hitting the title via Google News and then fetching the original article page, with both the publication time and the body taken from that page.

On the GitHub side, the anonymous API quota was ample this issue; organization-level checks covered 35 repositories, and only the main repository had pushes within the window — key repositories including packages, env, rtthread-nano, sdk, smart-build, and UtestRunner had no commits. A repository search for topic:rt-thread returned 8 hits, of which 2 were included (the ESP32-S31 port and coact); the rest were general GUI projects or personal forks.

Deduplication: #11978 was recorded as closed in the previous issue based on its proposal status; this issue supplements it with the actual merge time and root-cause details. #11981, #11954, #11971, and #11983 were listed in the previous issue; this issue records only status changes without repeating the details. #11985 and #11986 form a complete new chain opened this issue, recorded as two separate items, defect and proposal. Not included: the push to zlgopen/awtk is a general GUI improvement with no specific relationship to RT-Thread; WorkerHMan/imx6ull_rt-thread and JiaVerso/myPilot_board were both found on inspection to be complete forks of the RT-Thread mainline with no independent application code, so they are not treated as ecosystem items; the October 30 Double Eleven promotional piece is promotional content and has also fallen outside the window.

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 Homepage news section still shows June; no new items
Community forum Fronted by WAF challenge page (HTTP 468); list and body content unreadable
Main repo commits 3 within the window, concentrated at 11-04 10:44 and 21:30 to 21:33
Main repo PRs 3 merged (#11955, #11978, #11891); 1 newly opened (#11986)
Main repo Issues 1 newly opened (#11985), PCI MSI-X device-side input not validated
Main repo releases and tags No new items; latest remains v5.3.0 (2026-09-10)
RT-Thread org repos 35 repos checked; only the main repo had pushes within the window
GitHub repo search topic:rt-thread returned 8; 2 included (ESP32-S31 port, coact)
Google News Chinese 3 items within 3 days, all previously reported before the window or promotional; 7-day query returned 2 hits, 11-04 Ruibing desktop pet already included, 10-30 livestream preview outside the window
Google News English Zero valid hits; only one unrelated HackerNoon piece
HN Algolia All 7 items were Thread networking protocols, job postings, or unrelated content; excluded
EET-China official column One Ruibing desktop pet article on 11-04, included
Espressif official release Used to verify ESP32-S31 specs and release date

Full Source List