Research window: 2026-10-19 08:00 ~ 2026-10-20 08:00 (Beijing time, 24 hours)

Sources: RT-Thread official news API, community forum article API, GitHub (org: RT-Thread main repo commits / PR / Issue / Releases / tags, env tool repo, packages index, rtthread-skills, smart-build, rtthread-specification, RT-Thread Studio SDK index, topic:rt-thread ecosystem search), vendor repos (SpacemiT docs-chip, ai-sdk), Google News aggregation (multiple Chinese and English queries, via proxy), HN Algolia, industry media channel verification (see appendix source list for details)

In This Issue

  • I. Kernel and Version Updates
    • 1.1 SpacemiT K1 BSP first version merged into mainline: 173 files, 54K lines, S-mode plus 4-core SMP (10-19)
    • 1.2 RISC-V atomic CAS retry defect fixed in the same batch: expected value no longer overwritten by status register (10-19)
    • 1.3 rt_null console device moved earlier to BOARD initialization: log port can be set to null at power-on (10-19)
    • 1.4 Two fixes in the device model framework: power domain proxy naming and DVFS OPP duplicate warning (10-19)
    • 1.5 netdev ping latency statistics fix: minimum latency no longer missed when count is 1 (10-19)
  • II. Security and Stability Follow-up
    • 2.1 lwp signal number validation proposal: sys_sigaction entry restricted to 1 to 64 (10-19)
    • 2.2 Depth pre-check added before OFW device tree expansion: reject directly beyond 63 levels (10-20)
    • 2.3 New tmpfs defect ticket: ftruncate(fd, 0) frees buffer but returns success (10-20)
    • 2.4 Maintainer responds to libdl dynamic module defect: partial fix possible, full isolation requires user mode (10-19)
  • III. Official and Community Activities
    • 3.1 Official news API still has no new entries, v5.4.0 has no tag or release artifacts (10-20)
    • 3.2 Community forum added 1 post within the window, a 2026 embedded competition entry (10-19)
  • IV. Ecosystem and Vendor Adaptation
    • 4.1 ESP32 C3/C6 adapted to ESP-IDF v6.1: local default configuration passes, CI static analysis pending upstream (10-19)
    • 4.2 SpacemiT completes V100 server chip documentation, AI SDK updates vision submodule (10-19)
    • 4.3 Other repos in the org silent this period, no new commits in toolchain and package index (10-20)
  • V. Industry Applications
    • 5.1 Greenhouse environment monitoring terminal: E907 single core plus LVGL four-page UI, fully offline capable (10-19)
  • VI. Summary and Trend Observations
    • 6.1 Trends this period
    • 6.2 Limitations and deduplication notes

I. Kernel and Version Updates

1.1 SpacemiT K1 BSP First Version Merged into Mainline: 173 Files, 54K Lines, S-mode with 4-core SMP (10-19)

Date: 2026-10-19 18:49 (merge time)　Source: PR #11132, K1 BSP README

The first version of the SpacemiT K1 platform BSP has been merged: 4 commits, 173 files, +53862/-12, authored by GuEe-GUI. The proposal was opened on 2026-01-11 and landed after roughly nine months of review; it is a follow-up to the Next RISC-V series (#10320). The BSP targets the 64-bit RISC-V K1 with 8 X60 cores and vector extension support, is booted by U-Boot/OpenSBI, runs in S-mode, enables the MMU and 4-core SMP by default, uses the Banana Pi BPI-F3 as the validation platform, and routes the console through UART0 (115200 8N1). Supported features include PCIe/NVMe, eMMC HS400, Ethernet with PTP, HDMI framebuffer (including cold-boot display), JPU and V2D acceleration, ES8326 audio, CPUfreq and thermal management, and AES/RNG/eFuse; SPI and QSPI are marked as ported and under validation. The driver layer is extracted separately into bsp/spacemit/dm (147 files, 49 C files, about 30 modules, including clock, audio, graphics, crypto, PCI, SDIO, serial, thermal management, etc.) for reuse by future SoCs in the same family. On the CI side, a spacemit-k1 build leg was added, and the step that previously installed only the K230 toolchain was changed to apply to all riscv64 musl BSPs.

1.2 RISC-V Atomic CAS Retry Bug Fixed in the Same Batch: Expected Value No Longer Overwritten by Status Register (10-19)

Date: 2026-10-19 18:49 (merge time)　Source: merge commit 1c801efa, atomic_riscv.c

The same batch of commits fixed a real defect in the RISC-V atomic compare-and-swap implementation. In the original code, rt_hw_atomic_compare_exchange_strong used the same variable tmp both to hold the expected value and to receive the success/failure status of the sc instruction: when sc failed, tmp was written with a non-zero value, and the retry branch then compared the lr result against it — effectively using the overwritten value as the expected value, so the loop could never exit or could make an incorrect decision. The fix moves the expected value into a read-only operand, introduces a separate status register to receive the sc result, and changes the result output to a write-only constraint. This implementation is used by atomic operations on all RISC-V boards and is shared architecture code, so its impact is broader than a single BSP.

1.3 rt_null Console Device Moved Up to BOARD Initialization: Log Port Can Be Set to null at Power-On (10-19)

Date: 2026-10-19 16:53 (merge time)　Source: PR #11884, Issue #11472

A one-line community change moves null device registration from
INIT_DEVICE_EXPORT up to INIT_BOARD_EXPORT, so that setting RT_CONSOLE_DEVICE_NAME to null takes effect at power-on, solving the problem of being unable to silence output early when the log port and a communication port share the same UART. The author validated on qemu-vexpress-a9: uart0 outputs normally; after switching to null, QEMU shows no boot banner; after restoring uart0, the msh prompt returns; and rt_null.o lands in the .rti_fn.1 section. The change is 1 file, +4/-1, and the author notes it was completed with AI assistance. The more thorough approach of splitting early and regular consoles was not implemented in this change.

1.4 Two Fixes in the Device Model Framework: Power Domain proxy Naming and DVFS OPP Duplicate Warnings (10-19)

Date: 2026-10-19 18:49 (merge time)　Source: power_domain.c, dvfs.c

The K1 BSP merge also brought two framework-level fixes, a typical case of “BSP first, framework catches up.” First, the power domain proxy object was registered under the name of the real power domain, so name-based lookup mistook the proxy for the domain itself; it now uses a proxy-specific name, so power domain references in the device tree correctly reach the proxy’s resolve callback. Second, DVFS parsed the OPP table by adding entries directly without checking for duplicates, so duplicate table entries in the device tree triggered duplicate warnings and failed to be added; it now looks up by frequency first and reuses a match. Both changes are under components/drivers, and the beneficiaries extend beyond K1.

1.5 netdev ping Latency Statistics Fix: Minimum Latency No Longer Missed When count Is 1 (10-19)

Date: 2026-10-19 16:42 (creation time)　Source: PR #11900

A community submission fixes ping statistics in the netdev layer (1 file, +5/-1). In the original logic, when the ping count was 1 and the ping succeeded, only the maximum latency was recorded and the minimum was skipped, so the minimum displayed incorrectly after a single successful probe; the fix initializes both the maximum and minimum when the first response is successfully received. The change is small but affects the visible output of a commonly used diagnostic command, and the proposal is still under review.

II. Security and Stability Follow-up

2.1 lwp signal number validation proposal: sys_sigaction entry restricted to 1–64 (10-19)

Date: 2026-10-19 08:49 (created)　Source: PR #11899, Issue #11882

Maintainer BernardXiong has opened a fix proposal (2 files, +11-0) for the defect ticket #11882 covered in the previous issue: sys_sigaction passes the signal number supplied from user space directly to lwp_signal_action, which indexes a fixed-length array by signal number minus one (_LWP_NSIG is 64). An out-of-range or negative value causes an out-of-bounds read/write on the kernel heap, and an ordinary program can trigger it with a single system call. The proposal accepts only 1 to 64 at the sys_sigaction entry, otherwise setting EINVAL and returning, and adds the same check inside lwp_signal_action to protect future callers; the repository already has valid_signo_check, and this proposal reuses that approach. The proposal has been assigned to components for review and is under review.

2.2 Depth pre-check added before OFW device tree unflattening: reject beyond 63 levels (10-20)

Date: 2026-10-20 01:12 (created)　Source: PR #11901, Issue #11879

Community member liangzhan5 has submitted a fix for #11879 (1 file, +60-0). fdt_unflatten_single uses a fixed 64-entry stack to hold the traversal path, and when nesting exceeds 64 levels there is no check before pushing, causing an out-of-bounds write and crash during boot. The proposal first traverses the device tree with its own stack to compute the maximum depth before actual unflattening, and if it exceeds 63 levels, prints an error and aborts further unflattening, avoiding leftover-tree and double-assert issues; the author says the defect was reproduced on qemu with the qemu-virt64-aarch64 configuration, the CLA is signed, and the proposal is under review.

2.3 New tmpfs defect ticket: ftruncate(fd, 0) frees the buffer but returns success (10-20)

Date: 2026-10-20 01:53 (created)　Source: Issue #11902

Contributor XueDugu has opened a new dfs_v2 defect ticket. tmpfs’s truncate function sets ENOMEM but returns 0 when rt_realloc(data, 0) returns a null pointer, while both heap backends treat a zero-length realloc as “free and return null”; thus a legitimate ftruncate(fd, 0) first frees the file buffer and then reports success to the application, leaving a dangling pointer and a stale length, and subsequent reads and writes land on freed kernel heap, potentially causing information leaks and double frees. The defect was introduced by a commit on 2023-09-20 (PR #8063), affects all versions since v5.0.2 as well as master, and has been reproduced on RT-Smart under QEMU aarch64 and on the RP2350. The ticket remains open.

2.4 Maintainer responds to libdl dynamic module defect: partial fix possible, full isolation requires user mode (10-19)

Date: 2026-10-19 08:16 (commented)　Source: Issue #11898

The libdl relocation out-of-bounds write defect ticket covered in the previous issue received a maintainer response in this window. BernardXiong confirmed the description is accurate and believes bounds checking can be fixed to some extent, while noting that a dynamic module is essentially a piece of code inserted into the kernel with full privileges, which is why the official project has not attempted more with this mechanism; achieving memory isolation would require a user-mode model. The statement sets the boundary for the scope of the fix: this round is expected to add only metadata validation, without changing the overall privilege model of module loading.

III. Official and Community Activities

3.1 Still no new items on the official news API; v5.4.0 has no tag or release artifacts (10-20)

Date: 2026-10-20 (checked)　Source: RT-Thread official news API, releases

The 5 archived items returned by the official news API (rt_org category) are still latest dated 2026-06-17, with no new items in the window, meaning updates have been stalled for over four months; the official website’s news list page is rendered dynamically on the front end, so scraping yields only a loading placeholder, and the API is the authoritative source for news data. No change on the version side: the latest tag and release are still v5.3.0 from 09-10, and v5.4.0 has only the previously merged version macro and Kconfig default values, with release notes and artifacts not yet available. Product and event information continues to be first released via the WeChat official account, community forum, and GitHub channels.

3.2 One new post in the community forum window, a 2026 embedded competition entry (10-19)

Date: 2026-10-19 09:35 (posted)　Source: Community forum article API

The community forum article API returned 5 items, with 1 new in the window: a greenhouse environment monitoring terminal for the 2026 embedded competition (technical details in 5.1). The rest are updates to previously covered entries: the pollination robot post by Renhua was edited on 10-19 15:19, and the scavenger disinfection device, the Shuheng smart-care robotic arm, and the GD32H759IM USB secondary display were updated between 10-18 and 10-19; all are from the previous issue or earlier and are not expanded again here.

IV. Ecosystem and Vendor Adaptation

4.1 ESP32 C3/C6 adapted to ESP-IDF v6.1: local default configurations pass, CI static analysis pending upstream (10-19)

Date: 2026-10-19 13:43 (comment time)　Source: PR #11870, PR #11844

The proposal to upgrade ESP32 C3/C6 to ESP-IDF v6.1 and the RISC-V toolchain to GCC 15.2 remains under review. The author replied within the window: the local default configurations for both C3 and C6 now compile successfully; on CI, static analysis for C3 is still failing and requires change No. 18 on the esp-idf side, so work has not progressed further for now. The same author’s ESP32-S3-DevKitM-1 board support (#11844) is still blocked on completing package dependencies, with the latest reply dating back to 09-29. Once both are merged, they will cover three Espressif product lines: C3/C6/S3.

4.2 SpacemiT completes V100 server chip documentation, AI SDK updates vision submodule (10-19)

Date: 2026-10-19 10:45 ~ 22:54 (commit time)　Source: V100 product overview, docs-chip commits, ai-sdk

On the same day the K1 BSP was merged, SpacemiT pushed three commits to its documentation repository, adding a product overview and download links for the V100; the chip architecture document had been added on 10-12 with proposal No. 228, and this update completes the brief. According to the documentation, the V100 is positioned as a server-class RISC-V CPU: its 46 cores consist of 6 XiangShan Kunminghu V2R2 cores and 40 X100 cores, it is RVA23-compatible, has a maximum clock of 2.4 GHz, supports Hypervisor 1.0, AIA and IOMMU virtualization, and offers 8-channel DDR5-4800 with 307 GB/s bandwidth. The AI SDK repository updated its vision submodule pointer the same day, a model-library sync. The above are vendor-side developments, not RT-Thread topic items, and serve only as background corroboration.

4.3 Other repositories in the organization silent this period, no new commits to toolchain or package index (10-20)

Date: 2026-10-20 (verification time)　Source: RT-Thread organization repositories, packages, Studio sdk-index

Organization-level check sorted by push time: within the window only the main repository had pushes (10-19 10:49); rtthread-skills and smart-build last pushed on 10-18; rtthread-specification and env last pushed on 10-17; the packages index’s latest commit is 10-14 (hpm_sdk v1.13.0); and the Studio SDK index last updated on 10-10. The toolchain, packages and Studio lines all had no new content this period, consistent with the main repository’s focus on digesting the K1 BSP.

V. Industry Applications

5.1 Greenhouse environment monitoring terminal: E907 single core plus four-page LVGL UI, fully offline (10-19)

Date: 2026-10-19 09:35 (publish time)　Source: community article

A 2026 embedded competition entry: a localized environment monitoring terminal for small and household greenhouses. The hardware uses an ArtInChip D12X-DEMO68 development board, with a DAMO XuanTie E907 (RV32, 396 MHz, single-precision FPU) as the main controller, 8 MB PSRAM, 16 MB SPI NOR and a 480×272 capacitive touchscreen (GT911); the only sensors are a DHT11 and a BH1750, with no Wi-Fi and no cloud dependency. The software is based on RT-Thread 4.1.1 and LVGL 8.3.1: 6 threads layered at priorities 12 to 26, two message queues feeding alarms and the UI respectively, a mutex protecting state snapshots and the sensor bus, and thresholds written asynchronously to LittleFS via semaphore; the UI switches between four cached pages, the curve keeps a 60-point ring buffer and the three channels do not share a vertical axis; alarms require 3 consecutive confirmations with 2°C and 2% RH hysteresis, and the buzzer is driven by PWM. It also provides 12 MSH diagnostic commands for on-site checks of sample validity bits, touch coordinates and UI timing.

VI. Summary and Trend Observations

  • High-end RISC-V platforms enter the mainline: the K1 BSP was merged in S-mode with MMU and 4-core SMP, together with PCIe/NVMe, HDMI and multimedia acceleration, marking RT-Thread’s support for application-processor-class RISC-V platforms moving from “boots” to “fully equipped peripherals.”
  • Driver layers consolidated by SoC family: bsp/spacemit/dm separates roughly 30 device-model drivers into their own layer; K1 is only the first user, and later chips in the same family can reuse it. The BSP directory structure is beginning to show a division between a “vendor layer” and a “board layer.”
  • Frameworks fixed alongside the BSP: the same batch of commits surfaced three framework and architecture fixes—power-domain proxy naming, DVFS OPP deduplication and RISC-V atomic CAS—showing that new platform integration is in turn exposing defects in common code.
  • Security debt cleanup enters the fix phase: two of the four defect tickets from last period now have fix proposals (lwp signal validation, OFW depth pre-check), and a new tmpfs truncation defect was added; the maintainer’s boundary judgment on dynamic modules is that “partial fixes are feasible, isolation requires user mode.”
  • Official channels remain silent: the news API has been inactive for over four months, v5.4.0 has only its version number out ahead of release, and external information comes mainly from GitHub and community projects.
  • Binary firmware compliance needs attention: the K1 BSP embeds RCPU firmware taken from a vendor Linux image (serving HDMI audio), and the repository notes provide checksums and advise confirming redistribution terms before merging; such vendor binaries entering the mainline with BSPs are worth tracking.

6.2 Limitations and deduplication notes

  • This period is a 24-hour window (10-19 08:00 ~ 10-20 08:00), not a Monday, so no multi-day merge is performed.
  • Deduplicated against last period: #10320 Next RISC-V refactor, the four security defect tickets (#11898, #11882, #11879, #11878), the ESP32-C6 SPI merge, the Allwinner F101 BSP, RT-Thread 1.8.4 and Env 2.0.3 were all covered last period; this period covers only new developments within the window.
  • The K1 BSP was not included last period because its proposal was merged only in this window; this period lists it as the lead item by merge time.
  • The Google News Chinese 3-day window returned only 2 items, both old articles; the English window had zero hits; the 7-day query for RT-Thread was drowned out by same-named automotive news; none produced new items. All 4 HN candidates were false matches on “threads.”
  • The official website’s news list page is client-side dynamically rendered, so scraping yields only an empty shell; news is taken from the official API.
  • SpacemiT’s V100 and AI SDK are vendor-side developments, not RT-Thread topics, and are not listed as news items, only as background; the redistribution terms of their binary firmware were not verified this round and are noted only per the repository description.

Appendix: Source Verification Table

Source Verification Result
RT-Thread official news API (rt_org) No new items; the latest of 5 archived posts is still 06-17, stalled for over four months
Official website news list page Client-side dynamic rendering; scraping only yields an empty loading shell (same data as the official API)
Community forum article API 1 new item in the window (10-19 greenhouse environment monitoring terminal), all captured
GitHub org: RT-Thread Only the main repo pushed in the window (10-19 10:49); other repos last active 10-14 to 10-18
GitHub main repo commits 2 merges in the window; the K1 BSP commit contains 4 upstream commits
GitHub main repo PRs 13 updated in the window, 3 newly opened (#11899, #11900, #11901), 2 merged (#11132, #11884)
GitHub main repo Issues 2 updated in the window, 1 newly opened (#11902 tmpfs truncation defect)
GitHub main repo releases / tags No new releases; latest is still v5.3.0 from 09-10; v5.4.0 has no tag
GitHub RT-Thread/packages No pushes in the window (most recent 10-14, hpm_sdk v1.13.0 index)
GitHub RT-Thread Studio sdk-index No pushes in the window (most recent 10-10)
GitHub topic:rt-thread ecosystem search 5 items in the past week, 2 in the window (sf8086 already captured; awtk version bump not a dedicated item)
Google News aggregation (Chinese and English, via proxy) 2 Chinese items over 3 days are old posts; zero English hits; no new entries
HN Algolia All 4 candidates are false matches on “threads”; no relevant discussion
Vendor repos (SpacemiT) docs-chip 3 pushes, ai-sdk 1 push in the window, captured as background

Full Source List