Research window: 2026-11-02 08:00 ~ 2026-11-03 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, all 35 repositories under the RT-Thread org checked by push time, GitHub repository search (rt-thread keyword and topic:rt-thread), chip vendor GitHub organizations (HPMicro 64 repositories), seven groups of Google News queries in Chinese and English (via proxy), HN Algolia, EET China RT-Thread official column, Shanghai Municipal Commission of Economy and Informatization website, club.rt-thread.org forum (still restricted by the site’s WAF this issue)

Issue Index

  • I. Kernel and Version Updates
    • Two USB device host-controllable length fixes merged together: string descriptor index and MS OS compatible ID (11-02)
    • The 32-byte name buffer in SDHCI host initialization overflows the stack when RT_NAME_MAX is raised to 64 (11-02)
    • klibc’s byte loop is recognized by GCC as memset, causing link failure for targets without libc (11-02)
    • tiny vsnprintf treats long long as long, printing INT64_MAX as -1 (11-02)
    • SCMI reset controller takes the wrong container; driver registration order also moved to subsystem initialization (11-02)
    • X/Y/Z version rules enter documentation review; the QEMU test checklist accompanying Z versions is posted at the same time (11-02 ~ 11-03)
  • II. Security Follow-up and Pending Merge Queue
    • Negative offset in graphics device: pread and pwrite bypass position validation, leading directly to arbitrary kernel read/write (11-02)
    • The pipe patch lands the same day, changed on the driver side to guard itself per command (11-02)
    • Maintainer personally reworks two old proposals: getaddrinfo and GPT partition table (11-03)
    • Five more remain queued: cromfs directory name, poll count, 9pfs length, DHCP pool exhaustion, signalfd (10-21 ~ 11-03)
  • III. Official and Community Activities
    • Shanghai Open Source Software Application Innovation Competition concludes; RT-Thread is one of the 12 industry problem sponsors (10-29 ~ 10-30, official release 11-02)
    • RT-Thread and NXP user survey opens; NXP adaptation coverage already lists MCX A366 and A156 (11-02)
    • Official news API still stuck at June 17; release output remains in the media column (11-03)
  • IV. Ecosystem and Vendor Adaptation
    • HPMicro pushes 12 BSP repositories to v1.13.0 at once and opens HPM5100EVK (11-02)
    • AWTK mainline iterates as usual; this issue’s commits have no specific RT-Thread connection (11-02)
  • V. Industry Applications
    • Industrial gateway open-sourced: FreeModbus master, LVGL panel, 4G cloud connectivity and HTTP OTA combined into one image (11-02)
    • Sifli SF32LB52 smartwatch firmware puts RT-Thread on a wearable foundation (11-02)
  • VI. Trends and Summary for This Issue
    • Trend: all six merges in one day are old backlog items; the security queue begins to be taken over by maintainers
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 Two Host-Controlled-Length Fixes in USB Device Merged Together: String Descriptor Index and MS OS Compatible ID (11-02)

Date: 2026-11-02 11:47 (merge time)　Source: PR #11545, PR #11546, Issue #4782, Issue #11287

Both were merged by the same author within the same hour, and both fix long-standing issues in the USB device stack where “length and index come from the host.”

#11545 handles string descriptor indices (39 insertions, 15 deletions). The original implementation did not validate the host-supplied index before fetching a string, reading the string table directly by index; on out-of-bounds access it would read an adjacent interface string pointer, and could also dereference a null pointer when unregistered. The fix has two parts: check index bounds before reading the table, and have EP0 return STALL for any unknown or unregistered index; the OS string is returned only when a Microsoft OS compatible ID descriptor has been registered. The corresponding issue #4782 was opened on June 10, 2021 and sat open for over four years.

#11546 handles the length of the MS OS compatible ID response (4 insertions, 1 deletion). The host can supply an arbitrary wLength when fetching this descriptor, and the original implementation organized the EP0 transfer according to wLength, potentially sending out content beyond the constructed descriptor buffer. The fix clamps the response length to the actual constructed descriptor size, leaving allocation and caching behavior unchanged. The corresponding issue #11287 was opened on March 23, 2026.

Both PRs were opened on July 1, 2026 and entered the merge queue the same day. The author honestly noted in the PRs that verification consisted only of git diff --check and line-ending checks, with no build or USB device utest run, because the Windows machine at hand lacked scons, a C compiler, and an embedded cross toolchain. This is worth noting: both changes are small, but the USB descriptor path has no automated test coverage, so merge confidence came mainly from code review.

1.2 SDHCI Host Init’s 32-Byte Name Buffer Overflows the Stack When RT_NAME_MAX Is Set to 64 (11-02)

Date: 2026-11-02 11:24 (merge time)　Source: PR #11542

6 insertions, 4 deletions, in the SDHCI driver’s dev_sdhci.c. The symptom: enabling SDHCI on qemu-virt64-aarch64 with RT_NAME_MAX set to 64 causes a data abort during boot, fault addr 0x228.

The root cause is a hardcoded 32-byte local buffer: char dev_name[32], while sdio_host_set_name() writes up to RT_NAME_MAX characters per kernel object naming rules; once the name fills 32 bytes, the following two lines rt_sprintf(&dev_name[len], "-timer") and -data-timer keep writing past the end, overflowing onto the stack. Once the name length exceeds 32, the overflow goes from “possible” to “guaranteed.”

The fix changes the buffer to char dev_name[RT_NAME_MAX] and adds a dev_name[sizeof(dev_name) - 1] = '\0' after sdio_host_set_name() returns before recomputing the length, and switches both suffix concatenations from rt_sprintf to rt_snprintf with a remaining-length argument. This way, even if RT_NAME_MAX is set to 64 or 128, the combined name and suffix length is bounded by the buffer itself.

This pattern is not rare in RT-Thread: the kernel allows RT_NAME_MAX to be configured, but many drivers hardcode small buffers. This one surfaced when a contest entry’s board reached SD card initialization under QEMU, showing that combinations with non-default RT_NAME_MAX are not tested in normal practice.

Date: 2026-11-02 18:08 (merge time)　Source: PR #11965, Issue #6128

13 insertions, 1 deletion, changing only src/klibc/SConscript, with no C source changes.

rt_memset(), rt_memcpy(), and rt_memmove() in kstring.c all end with byte-by-byte loops. GCC with -O2 and -Os enables -ftree-loop-distribute-patterns, which recognizes such loops as standard library calls and rewrites them into references to memset and memcpy. If the target platform has no C library, these symbols do not exist, and the firmware fails at link time with a string of undefined references that give no hint of a connection to the string implementation.

The author reproduced this with arm-none-eabi-gcc 10.3.1 at -Os on the QEMU vexpress-a9 board project: before the fix, klibc’s kstring.o contained U memset, and two bl 0 <memset> calls landed inside rt_memset() itself—the kernel’s own memset calling a nonexistent memset. Issue #6128 was opened on June 30, 2022; the original report only said aarch64-gcc had a problem compiling rt_memset.

The fix appends -fno-tree-loop-distribute-patterns to the Libc group, and only when CROSS_TOOL == 'gcc', so Keil and IAR builds are unaffected. The cost is that these loops are no longer vectorized or folded, but these klibc functions are not on hot paths anyway. This lesson is broadly applicable to teams doing bare-metal ports: self-implemented string functions have an implicit contract with compiler optimization options, and toolchain upgrades are where it most easily breaks.

1.4 tiny vsnprintf Treats long long as long, Printing INT64_MAX as -1 (11-02)

Date: 2026-11-02 16:25 (merge time)　Source: PR #11600

20 insertions, 3 deletions, changing rt_vsnprintf_tiny.c and the corresponding tests. To save space, the tiny version merged the ll length modifier of %lld and %lli into the long path, so 64-bit integers were truncated to 32 bits and sign determination was misaligned—most visibly, INT64_MAX printed as -1.

The fix splits the internal signed branches for L (representing ll) and l: ll fetches its argument as long long and determines sign over the 64-bit range, while l keeps the long path. It also adds boundary-value regression cases for rt_sprintf covering INT32_MIN, UINT32_MAX, INT64_MIN, and INT64_MAX.

The verification configuration was qemu-vexpress-a9 with the tiny version’s long long support option (VSNPRINTF_LONGLONG, with standard vsnprintf disabled). The PR was opened on July 9, 2026 and sat in the queue for nearly four months. The tiny version is the default choice for many resource-constrained projects, and this kind of silent truncation is hard to spot when printing logs or formatting timestamps.

1.5 SCMI Reset Controller Uses Wrong Container; Driver Registration Order Also Moved to Subsystem Init (11-02)

Date: 2026-11-02 18:20 (merge time)　Source: PR #11946

22 insertions, 7 deletions, changing reset-scmi.c and pm-domain-scmi.c, the last push in this window.

On the reset side, the problem is a container conversion using the wrong object. scmi_reset_reset(), assert(), deassert(), and the device tree parsing function all write raw_to_scmi_reset(rstc), treating an rt_reset_control pointer as an SCMI reset controller to derive from; the correct approach is to go through rstc->rstcer, first obtaining the reset controller and then converting. Passing the wrong pointer does not crash but reads misaligned fields, with symptoms depending on memory layout, so such errors are often only discovered when “reset doesn’t take effect” on a specific board.

On the registration side, the two drivers previously used RT_SCMI_DRIVER_EXPORT and were changed to an explicit registration function plus INIT_SUBSYS_EXPORT. The difference between the two export macros is registration timing: the drivers must register after the reset and power domain infrastructure is ready, otherwise consumers probing first will not find the provider. The PR description also mentions looking up properties using the reset domain ID parsed from the device tree, and keeping an SCMI device reference in the reset controller instance to prevent the controller’s lifetime from being shorter than the device’s.

1.6 X/Y/Z Version Rules Enter Documentation Review; QEMU Test Checklist for Z Releases Posted Alongside (11-02 ~ 11-03)

Date: 2026-11-02 15:24 (checklist) / 2026-11-03 07:23 (doc update)　Source: PR #11955, Issue #11972, PR #11974, PR #11976

The version management PR #11955 reported in the previous issue was updated again at the end of the window (11-03 07:23), and the documentation content is now concrete: the rules for determining X/Y/Z three-level version numbers, a 3-to-6-month Y release cycle, a 1-month Z release cycle, and release responsibilities and compatibility requirements at each level. Still under review, not merged.

The accompanying execution checklist was posted by CYFS3 on 11-02 15:24 as issue #11972, with a blunt title—automated CI testing for Z releases. The core idea is “replace real hardware with QEMU emulated devices”: for a microphone, for example, you only need to register a set of virtual ops to create an emulated microphone and fully test the framework interface’s inputs, without waiting for a board. The checklist itemizes the current state of utest and QEMU coverage framework by framework: SPI has loopback tests, PWM has frequency and duty cycle tests, RTC has alarm tests, audio already has an in-firmware emulated microphone and player plus DMA callbacks, framework tests for adc and dac are being added (corresponding to #11974 and #11976), while the QEMU side is essentially blank for i2c, can, watchdog, touch, usb, sdio, flash, and ethernet.

The value of this checklist is that it turns “can we ship a Z release” from a maintainer’s subjective judgment into a checkable table. It and #11955 are two halves of one thing: one sets the rules, the other provides the evidence. At press time #11972 had 6 comments, and the two utest PRs for adc and dac had been posted but not merged.

II. Security Follow-up and Merge Queue

2.1 Negative Offsets on Graphics Devices: pread and pwrite Bypass Position Validation, Enabling Arbitrary Kernel Read/Write (11-02)

Date: 2026-11-02 12:01 (report time)　Source: Defect #11969, Proposal #11970

Reported by XueDugu, with the baseline verified against that day’s master 08cad4ee. The impact scope is stated clearly: from v5.3.0 through current master, the defect was introduced by commit 5abecc1fd0c3 on 2025-12-12, and the current graphic.c blob is 14de5a6c.

_graphic_read() and _graphic_write() accept a signed device offset but check neither pos >= 0 nor pos < framebuffer_len. The remaining length is computed with rt_min_t(rt_ssize_t, plane->framebuffer_len - pos, size): when pos is negative, framebuffer_len - pos becomes a large positive number, res simply takes size, and the subsequent rt_memcpy(plane->framebuffer + pos, buffer, res) reads or writes before or after the framebuffer.

The entry points are RT-Smart’s pread64() and pwrite64(). The current rw_verify_area() only rejects negative positions when count >= -pos, so a combination such as count=8, pos=-210456 passes validation and reaches the driver. The report provides two levels of verification: qemu-virt64-aarch64 with QEMU’s built-in ramfb device, demonstrating the user-to-kernel out-of-bounds path; and a Raspberry Pi Pico 2 W (RP2350) over USB CDC, verifying the board-level kernel API primitive itself.

Fix proposal #11970 was posted 31 minutes later (12:32), authored by usualtreee, with 10 added lines touching only graphic.c: both functions check pos before computing the remaining length, returning 0 directly for negative values and for positions greater than or equal to framebuffer_len, while the front-end clipping behavior for valid reads and writes is unchanged. This is the fastest response in this window—half an hour from report to patch—but the patch has not yet been merged.

2.2 pipe Patch Lands the Same Day, Guarding by Command on the Driver Side (11-02)

Date: 2026-11-02 15:23 (proposal time)　Source: Proposal #11971, Defect #11958

The pipe FIONREAD defect reported in the previous issue has received a patch. 22 added lines, 4 deleted, touching only the file containing pipe_fops_ioctl.

The approach is to first compute the ring buffer’s data length or remaining space into an int on the stack, copy it back to the user address with lwp_put_to_user() in MMU builds, and keep the direct write in non-MMU builds—under a single address space there is no isolation to speak of, and adding this layer would instead break compatibility. It also adds null checks for pipe and pipe->fifo, and wraps the lwp_user_mm.h include in ARCH_MM_MMU.

The proposal explains why the check is not centralized in sys_ioctl(): ioctl semantics vary by driver—some take a scalar arg, others a struct pointer—so a global check easily causes false positives, and guarding by command on the driver side is more appropriate. This trade-off is worth noting: the previous issue grouped pipe, block devices, and terminals under the same root cause, but a unified entry point is not the only solution; the cost is that every driver must remember to do it itself.

2.3 Maintainer Redoes Two Old Proposals Personally: getaddrinfo and GPT Partition Table (11-03)

Date: 2026-11-03 00:08 / 07:18 (proposal time)　Source: Proposal #11977, Proposal #11978

Both were submitted by BernardXiong, and the first sentence of each proposal body reads “This is a redo of #xxxx (the original PR is conflicted and outdated).”

#11977 redoes #11454, hardening the user pointer handling in sys_getaddrinfo() (57 added lines, 17 deleted). The original implementation validated only the top-level res buffer, then wrote resolution results through res->ai_addr, a user-controllable nested pointer—equivalent to an arbitrary kernel write in Smart/MMU builds; the hints fields were still read from user memory after top-level validation, leaving a TOCTOU window. The new implementation copies res and hints into kernel temporary structs in one go with lwp_get_from_user(), so all subsequent nested pointers come from this snapshot; nested sockaddrs and the outer struct are written back uniformly with lwp_put_to_user(); it also fixes the return value check on the servname copy—the original code compared a size_t against 0, which is always false.

#11978 redoes #11275, fixing the reversed start and end in the GPT partition table (11 added lines, 5 deleted, touching only efi.c). is_pte_valid() only required that starting_lba and ending_lba both fall within the disk range, without checking ending_lba >= starting_lba; a GPT image with a valid CRC could make size = ending_lba - starting_lba + 1ULL underflow as unsigned, yielding an enormous partition size that gets registered as a logical partition. The fix adds an end < start check in the validation function and moves the start and size computation after the validity check, computing size from the validated start. This corresponds to defect #11271; the original proposal #11275 was closed on 11-03 07:20.

Viewed together, the signal matters more than the fixes themselves: once patches from external reporters become stale and conflicted, the maintainer has started redoing them himself rather than waiting for the author to rebase. This and the fast patches in 2.1 and 2.2 are two sides of the same thing—the queue is moving.

2.4 Five More Still Stuck in the Queue: cromfs Directory Names, poll Count, 9pfs Length, DHCP Pool Exhaustion, signalfd (10-21 ~ 11-03)

Date: 2026-10-21 ~ 2026-11-03 (proposal time and latest update)　Source: Proposal #11911, Proposal #11954, Proposal #11918, Proposal #11947, Proposal #11935

#11911 is the cromfs directory name read (421 added lines, 116 deleted, 7 files, still being updated as of 11-03 07:50). dfs_cromfs_getdents() takes the image’s uint16 name_size directly as the memcpy length into d_name, comparing it neither against DIRENT_NAME_MAX (256) nor checking whether the name falls within the just-loaded directory blob; the very next line then writes the NUL at the name_size position, so the original code already overruns by one byte when name_size reaches 256. The caller does not clip either—msh’s ls() puts struct dirent on the shell thread stack and requests only one entry from getdents, so an overlong directory name overwrites the shell thread stack.

#11954 is the count multiplication wraparound in poll and epoll (166 added lines, updated 11-03 07:24, nearly six times larger than recorded in the previous issue). sys_poll() uses the user-supplied count to size the kernel buffer; on 32-bit the product wraps but the original count is still used for iteration: with nfds = 0x20000001 and pollfd at 8 bytes, the product truncates to 8, validation and allocation pass on 8 bytes, yet poll() iterates over 530 million entries.

#11918 is the 9pfs client trusting the length given by the server (66 added lines, 6 deleted). The byte count returned by p9_transaction() is discarded, and parsing uses the count, stat_size, and name_len from the message directly; a crafted response with a “huge count but actually very short” body can read past the receive buffer—measured at over 8.3 MB, with ASAN reporting use-after-poison and directory information leaking as well.

#11947 is the unbounded search after DHCP address pool exhaustion (19 added lines, 5 deleted). dhcp_client_alloc() uses goto to keep searching when a candidate address is taken, with no limit on iterations; once the pool is full, a DISCOVER from a new MAC sends it into a permanent loop in the lwIP receive path, blocking all subsequent packets. The fix records the first candidate of the round and stops upon returning to the starting point, returning NULL when the pool is full.

#11935 is the listener removal in signalfd_close (91 added lines, 35 deleted). The original implementation registered notifications with a global index count, and on close neither unlinked nor freed them, leaving dangling nodes; the fix switches to a bounded lookup by the maximum number of registered slots, and on close walks the registered lwps to unlink the corresponding nodes from the notification chain and free them, while clearing the file context pointer.

The common thread across all five is still the old problem: lengths, counts, and indices come from user space or the peer, with no validation layer before entering kernel logic. The difference is that each now has a corresponding proposal, and most include reproduction steps on QEMU.

III. Official and Community Activities

3.1 Shanghai Open Source Software Application Innovation Competition Concludes; RT-Thread Is One of 12 Industry Challenge Sponsors (10-29 ~ 10-30, Official Release 11-02)

Date: 2026-11-02 (official release) / 2026-10-29 ~ 10-30 (event)　Source: Shanghai Municipal Commission of Economy and Informatization: Competition Concludes, People’s Daily Online: Driving More Open Source Results from Competition to Market

The 2026 Shanghai Open Source Software Application Innovation Competition Finals and Innovation Growth Conference were held October 29–30 at the Zhangjiang AI Innovation Town in Shanghai, organized by OSChina. Since registration opened on August 5, 766 projects signed up, with more than 40 partner enterprises and open source communities participating; 12 real industry challenges attracted 269 projects responding to them, and 30 teams advanced to the finals to compete for a prize pool worth RMB 1 million in total.

Among the issuers of the 12 challenges, RT-Thread (睿赛德) appears alongside COMAC, CSSC Haizhou, DaoCloud, Yunaxis Technology, and Mofa Technology on the side of Shanghai-based local enterprises, while the other side comprises national technology enterprises and communities such as Baidu Maps, the openKylin community, and the open-supOS community. For RT-Thread, this position means that “industrial and embedded scenarios are treated as sources of real industry problems,” rather than a sponsor’s seat.

At the October 30 awards ceremony, OSChina announced its official establishment in Shanghai, and the competition brand was upgraded to an annual event in the fields of open source and artificial intelligence in Shanghai, to be held every year starting this year; the 30 finalist teams’ projects cover industrial simulation, compute scheduling and inference acceleration, agent security governance, embodied intelligence data quality inspection, and life science computing, with teams from Shanghai universities, enterprises, and open source communities accounting for about one third.

3.2 RT-Thread and NXP User Survey Opens; NXP Adaptation Coverage Now Lists MCX A366 and A156 (11-02)

Date: 2026-11-02 17:30 (published)　Source: EET-China: RT-Thread and NXP Survey Campaign

The official RT-Thread column published a joint user survey with NXP, running from November 2 to November 23, with prizes drawn on November 24. The article opens with a very specific description of the collaboration: multiple chips have already been adapted, including MCX N947, MCX A366, and MCX A156. The survey asks respondents to fill in end devices, application scenarios, and development pain points, and welcomes suggestions for improvement regarding chip performance, peripherals, and ecosystem adaptation.

This is itself a community operations move, but the disclosed adaptation list is valuable: the MCX A series is the general-purpose MCU line NXP has been promoting heavily over the past two years, and the appearance of A366 and A156 on the adaptation list shows that RT-Thread’s coverage across NXP’s product line has expanded from NPU-equipped models like the N947 to general-purpose models. The NXP i.MX RT1180 industrial Ethernet linker script proposal (#11959) reported in the previous issue is still in the queue, and the two lines can be viewed in comparison—one is breadth on the MCU side, the other is depth on the crossover processor side.

3.3 Official News API Still Stuck at June 17; Publishing Outlet Remains the Media Column (11-03)

Date: 2026-11-03 (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 item “RT-Thread Technology Invited to Attend the 2026 Abu Dhabi Investment Forum,” and the news section on the official homepage is likewise stuck at June, with no new additions this issue. This marks the sixth consecutive month with no update to this API.

The actual publishing outlet is the media column: within this issue’s window, the official RT-Thread column on EET-China published one article (the November 2 NXP survey), while another piece, a November 1 Double 11 promotion article, was not included. On the forum side, club.rt-thread.org still returns 468 behind a front-end WAF challenge page, so lists and post bodies cannot be read directly, and community updates can only be cross-verified through GitHub and the media column.

IV. Ecosystem and Vendor Adaptation

4.1 HPMicro Pushes 12 BSP Repositories to v1.13.0 in One Batch, Opens New HPM5100EVK (11-02)

Date: 2026-11-02 11:43 ~ 11:56 (push time)　Source: Repo: rtt-bsp-hpm5100evk, Repo: rtt-bsp-hpm6800evk, Repo: rtt-bsp-hpm6e00evk

Among the 64 repositories under HPMicro’s GitHub organization, 12 RT-Thread BSP repositories were pushed in a concentrated burst between 11:43 and 11:56 on November 2: HPM6750EVK, HPM6750EVK2, HPM6750EVKMINI, HPM6E00EVK, HPM6P00EVK, HPM6800EVK, HPM6300EVK, HPM6200EVK, HPM5E00EVK, HPM5300EVK, HPM5301EVKLITE, and the newly opened HPM5100EVK.

Commit messages verified repository by repository are consistent: HPM5100EVK, HPM6800EVK, and HPM6E00EVK all read “RT-Thread BSP v1.13.0 for ", with timestamps falling within the same second-level interval—indicating a scripted batch release rather than independent development. The previous commits for HPM6800EVK and HPM6E00EVK were v1.11.0 on 2026-02-03, roughly nine months earlier, with no v1.12.0 commit in between.

HPM5100EVK is a new repository (created 11-02 10:59), and its first commit is v1.13.0. The README states it is an RT-Thread Studio BSP, with bundled examples including adc, blink_led, flashdb, mcan, pwm, spi_nor_flash_fs, timer, uart_dma, usb_device_generic_hid, and usb_host_msc_udisk. The example list reveals the board’s positioning: dual-role CAN and USB, with filesystem and FlashDB both covered by default—leaning toward industrial and data-logging scenarios.

Chip vendors splitting BSPs into standalone repositories maintained as Studio projects has been the norm in the RT-Thread ecosystem for the past two years (GigaDevice, ST, and Renesas all do this). What is worth noting is the release cadence: twelve repositories at the same version on the same day indicates HPMicro has an internal synchronization script from SDK to each board BSP, which better ensures cross-board consistency than manually merging repository by repository.

4.2 AWTK Mainline Iterates as Usual; This Period’s Commits Have No Specific RT-Thread Connection (11-02)

Date: 2026-11-02 17:42 (push time)　Source: Repo: zlgopen/awtk

ZLG’s AWTK (3,325 stars) had one push within the window, with the three most recent commit titles all reading “improve edit”—routine iteration of a general-purpose GUI framework, with no RT-Thread-specific changes observed. The repository carries the topic:rt-thread tag and has long supported RT-Thread BSPs, so it is included in ecosystem monitoring; this period it is not expanded into a full entry.

V. Industry Applications

5.1 Industrial Gateway Open Source: FreeModbus Master, LVGL Panel, 4G Cloud Connectivity, and HTTP OTA Combined into One Image (11-02)

Date: 2026-11-02 13:59 (repository creation)　Source: Repository: rtthread-industrial-gateway

A newly created personal project that implements four data paths of an industrial data gateway on a single STM32F407VGT6: the downlink uses FreeModbus as an RTU master, periodically polling the holding registers of field slaves; locally, LVGL 8.3 provides the HMI, with button control and readback sharing a single holding-register mirror table; the uplink connects via an ML307 4G module over MQTT QoS1 to ThingsBoard, supporting RPC reverse control; remote upgrades use HTTP chunked download with CRC32 verification, writing to the download partition and then having rtboot move it to the app partition before jumping.

The hardware configuration is documented in more detail than most similar repositories: FSMC 8080 parallel 16-bit TFT, xpt2046 resistive touchscreen over SPI, W25Q128 (16 MB) on SPI1 with chip select software-controlled via PG15, ML307 on uart6 using AT commands, and the Modbus slave on uart3 at 9600 8N1. The project progresses through nine stages, with the final stage merging all four paths into a single image.

The significance of this combination is that “the entire chain runs on the board”: many gateway projects offload cloud connectivity to an external module or a second MCU, whereas this project squeezes 4G, protocol conversion, HMI, and OTA onto a single M4F—at the cost of 192 KB SRAM having to simultaneously accommodate LVGL buffers, Modbus frames, and MQTT sessions. For teams selecting an industrial gateway, this repository’s directory structure and partition layout are more valuable as a reference than the finished product.

5.2 Sifli SF32LB52 Smartwatch Firmware, Putting RT-Thread on a Wearable Foundation (11-02)

Date: 2026-11-02 18:03 (push time)　Source: Repository: helios-sf32

A smartwatch firmware based on the OpenSifli SDK, targeting the LCD screen of the Sifli SF32LB52 development board, with LVGL for the UI and RT-Thread as the foundation. The repository was created on September 4, had one push within the window, and currently has 5 stars and 1 fork.

Wearables are a relatively uncommon landing spot for RT-Thread. The constraints of such products are the opposite of industrial boards: smooth screen refresh, low standby power consumption, and hot-updatable UI resources—and RT-Thread’s advantages here are its trimmable components and mature LVGL bindings. The OpenSifli SDK uses RT-Thread as its default RTOS, indicating that Sifli has chosen this foundation at the SDK level for this product line, which third-party firmware projects can directly inherit.

6.1 Trend: Six Merges in One Day, All Old Backlog; Security Queue Starts to Be Taken Over by Maintainers

In the 24-hour window of this period, the main repository merged 6 pull requests, all between 11:24 and 18:20 on November 2. The number is not large, but the structure is highly concentrated: four proposals were opened on July 1, 2026 (#11542, #11545, #11546 submitted that day, #11600 on July 9), one corresponds to defect #6128 from June 2022, and one to defect #4782 from June 2021. In other words, this day cleared backlog, not new work.

The first thread is “latent defects under configuration combinations.” The SDHCI stack overflow in #11542 only triggers when RT_NAME_MAX is set to 64; the long long truncation in #11600 only appears with tiny vsnprintf enabled; the link failure in #11965 only surfaces on target platforms without a C library. What these share is that they cannot be caught under default configurations—yet these non-default combinations are exactly the most common in real projects: swap a chip, swap a toolchain, save some Flash, and you hit them.

The second thread is that the clearing of RT-Smart and device-boundary accounts has entered its second phase. The previous period’s assessment was “many reports, few patches”; this period’s change is that patches have started to catch up and response has become faster: the graphics device negative offset went from report to proposal in 31 minutes (#11969 to #11970), the pipe patch landed the same day (#11971 corresponding to #11958 from the previous period), and the maintainer personally reworked two stale proposals on getaddrinfo and GPT (#11977, #11978). Five items remain under review in the queue, but each has reproducible steps, so review cost has already dropped.

The third thread is version governance moving from “plan” to “evidence.” #11955 documents the cadence and responsibilities of X/Y/Z in writing, and #11972 breaks down whether a Z release can ship into a per-framework checklist of QEMU virtual devices and utest, with proposals even filed for adc and dac emulated-device tests. Neither changes the kernel, but both determine the basis for judgment at every subsequent Z release—the previous period said “turn manually curated steps into checkable processes,” and what we see this period is the checklist landing.

Ecosystem-side moves are more direct: in thirteen minutes, SpacemiT pushed 12 BSP repositories to v1.13.0 and opened a new HPM5100EVK, showing that vendor-side BSP maintenance has been scripted; on the community side, an industrial gateway project has emerged that crams Modbus, LVGL, 4G, and OTA all onto a single M4F. On one side vendors ensure consistency across boards, on the other developers push component assembly to the limit—these two ends are precisely the most concrete picture of RT-Thread’s ecosystem today.

6.2 Limitations and Deduplication Notes

The forum club.rt-thread.org still returned 468 this period with a WAF challenge page in front, so thread lists and post bodies could not be read directly; the information gap on the community discussion side was filled by GitHub and media columns, without post-by-post comparison. Both the official news API and the official website news list remain stuck at June 17, so release-side information can only rely on media columns.

On Google News, the two English-language query sets returned zero hits, while three Chinese-language sets returned results: the Shanghai Open Source Competition (included), the NXP questionnaire (included), and a Zhidx article about the Arm China Jishu Community robot dog (the body did not cover specific RT-Thread technical content, so not included). There was also a Double 11 promotional piece from 11-01, which falls outside the window and is promotional content, so it was not included. HN Algolia had no RT-Thread-related hits within the window.

On the GitHub side, this period was affected by the anonymous API rate limit (60 per hour); the main repository’s commits, proposals, and defect details were all obtained. The version numbers of the 12 SpacemiT repositories were cross-checked against HTML and Atom commit feeds, with three confirmed to have commit messages of v1.13.0 and the remaining nine judged as released in the same batch based on the same timestamp range, without fetching commit bodies per repository. Items placed in the pending-review queue in the previous period—#11897 (K230D), #11892 (RISC-V Smart MMU), #11944 (RTL8125), #11943 (RK3588 display audio), #11959 (NXP RT1180 linker script)—remain in the queue this period with no merges and are not repeated as entries; #11954 and #11958 were reported last period, and this period only records updates and patch progress.

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 articles
Community article API Site fronted by WAF challenge page (HTTP 468); list and body content unreadable
Main repository commits 6 within the window, concentrated between 11-02 11:24 and 18:20
Main repository PRs 6 merged (#11542, #11545, #11546, #11600, #11965, #11946); over ten newly opened and under review, including #11970, #11971, #11974, #11976, #11977, #11978
Main repository Issues 1 newly opened (#11969 graphics negative offset); #11972 checklist posted and updated the same day
Main repository releases and tags No new items; latest remains v5.3.0 (2026-09-10)
RT-Thread org (35 repositories) Only the main repository pushed within the window; all other repositories silent
HPMicro org (64 repositories) 12 RT-Thread BSP repositories pushed v1.13.0 the same day; HPM5100EVK newly opened
GitHub repository search (rt-thread) 2 newly created within the window (industrial gateway, HPM5100EVK BSP); 4 topic pushes
Google News Chinese 3 hits, 2 included (Shanghai open source competition, NXP questionnaire)
Google News English Zero hits
HN Algolia No RT-Thread-related hits
EET-China official column 1 article within the window (11-02 NXP questionnaire), included
Shanghai Municipal Commission of Economy and Informatization website Competition summary published 11-02, included

Complete Source List