Research window: 2026-10-23 08:00 ~ 2026-10-26 08:00 (Beijing time, 72 hours, including the weekend)

Sources: RT-Thread official news API, community forum article API, GitHub (main repository commits / PR / Issue / Releases / tags, RT-Thread/sdk and toolchains-ci, repositories under the RT-Thread-packages organization, pkgs-test, topic:rt-thread ecosystem search), Google News aggregation (multiple Chinese and English query sets, via proxy), HN Algolia, industry media (Electronic Engineering Album RT-Thread column), and vendor channel verification (see the appendix source list for details)

This Issue’s Index

  • I. Kernel and Version Updates
    • Mainline sees only two commits in 72 hours: lwIP loopback netdev merged, clang-format rules refined with thread.c example (10-25)
    • qemu-virt64 enables RT-Thread Smart: riscv64 disables SMP, ext4 and elm mount block devices, ptyfs and procfs mounted (10-25)
    • lwp_syscall.c split from eleven thousand lines: 165 syscall entry points divided into files by subsystem, behavior unchanged (10-25)
  • II. Security and Stability Follow-up
    • Time subsystem reports four issues in one night: settimeofday narrowing, gmtime_r negative timestamps, timer_gettime truncation, plus an A-to-F work item investigation (10-23/10-24)
    • sys_poll wraparound on 32-bit RT-Smart: 8-byte heap block traversed as 0x20000001 entries, kernel heap out-of-bounds read/write (10-24)
    • The ESP-IDF v6.1 adaptation merged in the previous issue breaks C3/C6 builds on master; include-order fix submitted (10-25)
    • Status review of existing defect proposals: NVMe leak, 9PFS length, tmpfs UAF, dlmodule globals, FDT depth all pending merge (10-25)
  • III. Official and Community Activities
    • Systems-software perspective report on the six RISC-V China Summits published: the RISC-V bottleneck is shifting from cores to system software (10-24)
    • GDR: brings RT-Thread kernel object inspection into GDB, QEMU closed loop covers 3.1.x/4.0.x/4.1.x (10-25)
    • Two community long-reads: Env tool v2.0.3 custom installation, and a full investigation of Studio’s 24 implicit declaration warnings (10-25)
    • Live stream on the evening of 10-26: RT-Thread and an edge-AI hand rehabilitation exoskeleton (10-25)
    • Three embedded competition entries: on-device Agent multi-sensor fusion, ART-Pi2 USB enumeration diagnostics, OpenMV suspect tracking (10-24/10-25)
  • IV. Ecosystem and Vendor Adaptation
    • TriCore (AURIX) enters Env SDK: tricore-gcc 13.4.1 and qemu-tricore packages merged, covering TC2xx/TC3xx/TC4xx (10-26)
    • ai/Agent package adds speech transcription endpoint, default backend switched from SiliconFlow to the official DeepSeek API (10-23)
    • Allwinner F101 and H616 BSP proposal with 172 files; ESP32-S3-DevKitM-1 board support also completed (10-24/10-26)
    • Drivers and CI: OSPI octal Flash, I2C control transaction serialization, STM32 package test concurrency lock (10-23/10-25)
  • V. Summary and Trend Observations
    • Trends in this issue
    • Limitations and deduplication notes

I. Kernel and Version Dynamics

1.1 Mainline sees only two commits in 72 hours: lwIP loopback netdev merged, clang-format rules refined with thread.c example (10-25)

Date: 2026-10-23 17:09 and 2026-10-25 19:26 (merge times)　Source: PR #11859, PR #11893, main repository commit log

Over the three-day weekend window, master received only these two commits, consistent with the previous issue’s assessment of “a burst of wrap-up work after three days of zero commits”: both merges landed outside working hours (Friday 17:09, Sunday 19:26), and review itself never stopped—there was simply no new code from the development side.

The first is the wrap-up of clang-format rules, 2 files +83/-77, touching only .clang-format and src/thread.c. The branch name carries the discussion thread style/clang-format-discussion-11653, both commit dates are 10-09, and the substance is refinement of “alignment, brace wrapping, and spacing rules”; the second commit reformats src/thread.c wholesale under the new rules as an example. In other words, this is the close-out of a review that dragged on for two weeks, not new work. The proposal also records a tooling fact: constructs like index++ are left as-is by both clang-format 18.1.8 and 23.1.3, with no configuration option to force a rewrite, and validation uses --dry-run --Werror.

The second brings the lwIP loopback device into the netdev framework, 3 files +54/-0. Previously the lwIP loopback interface was not registered as a netdev, causing two classes of problems: toolchains going through 127.0.0.1 could not run; and network namespaces without a physical link had no default usable interface. The change adds the RT_LWIP_USING_LOOPBACK config option, registers lo／lo0 as a netdev and sets it link up, selects loopback as the default interface when none is specified, and enlarges the RAW receive mailbox to accommodate loopback echo. The validation configuration given is qemu-virt64-riscv, and the proposal states “not compiled locally, build verified by CI”—consistent with the release criteria of several proposals last month: merging is conditioned on a passing build, with on-board follow-up separately.

The version side remains quiet: the latest release artifact and tag are still v5.3.0 from 09-10, and the v5.4.0 version macro from the 10-17 commit still has no release notes, binaries, or pre-release tag.

1.2 qemu-virt64 enables RT-Thread Smart: riscv64 disables SMP, ext4 and elm mount block devices, ptyfs and procfs mounted (10-25)

Date: 2026-10-25 19:50 (last updated)　Source: PR #11896

This proposal, 14 files +1263/-1075, turns on RT_USING_SMART for the qemu-virt64-riscv and qemu-virt64-aarch64 BSPs. Previously these two virt platforms nominally supported Smart, but the virtio block device had no standard root filesystem initialization flow and pty had no mount point, so many features simply could not be tested under QEMU.

The change breaks into four parts: on the riscv64 side, SMP is disabled to align with Smart’s single-core configuration; a new initialization flow mounts ext4 or elm on virtio-blk0; ptyfs is mounted at /dev/pts and procfs at /proc; and .config and rtconfig.h are regenerated. Build validation states that riscv64 uses the RISC-V musl generic toolchain and aarch64 uses the aarch64 musl toolchain, not run locally but verified by CI.

Worth noting is the dependency: this proposal explicitly depends on the just-merged #11893 (the RT_LWIP_USING_LOOPBACK config symbol), and .config was generated on top of #11893; the author states they will rebase and regenerate the configuration once the dependency merges. Such cross-proposal configuration coupling is common in qemu platform rework, and it explains why the loopback interface had to land before Smart enablement—without loopback, a large number of tests under Smart that rely on the local address cannot run.

1.3 lwp_syscall.c split at eleven thousand lines: 165 syscall entry points divided into files by subsystem, behavior unchanged (10-25)

Date: 2026-10-25 19:50 (last updated)　Source: PR #11894

The single file components/lwp/lwp_syscall.c exceeds eleven thousand lines, piling six categories of syscalls—memory, filesystem, socket, process, IPC, and time—into one place, making review and search difficult. The proposal splits it into the components/lwp/syscall/ directory, divided by subsystem, adds a shared syscall dispatch table and internal header, and registers the new directory in the LWP build script.

In scale this is the largest change of the window: 22 files +12223/-11638, almost entirely moves and renames. The proposal describes itself as a “mechanical refactor, no functional change” and stresses that the 165 syscall entry points and behavior remain completely unchanged. Validation is likewise “not compiled locally, CI verified”, with configuration CONFIG_RT_USING_SMART=y.

From an engineering standpoint, this kind of split produces no new capability by itself, but it determines whether subsequent lwp defects (such as the sys_poll wraparound in section 2.2 of this issue) can be located in a readable file. The 9PFS length-convergence proposal recorded in the previous issue belongs to the same thread: the Smart-side code is shifting from “works” toward “maintainable.”

II. Security and Stability Follow-up

2.1 Time Subsystem Reports Four Issues in One Night: settimeofday Narrowing, gmtime_r Negative Timestamps, timer_gettime Truncation, Plus an A-to-F Work Item Investigation (10-23/10-24)

Date: 2026-10-23 21:04 and 2026-10-24 20:25 (creation time)　Source: Issue #11922, Issue #11923, Issue #11924, Issue #11927

On the evening of 10-23, the same researcher filed three issues in a row against the libc time source ctime.c (under components/libc), plus an investigation issue the next day, laying out the time subsystem’s semantic problems all at once. All three issues are based on master a59e72fb5c, all reproduced in source-level isolation, none on hardware.

The first issue is type narrowing in settimeofday(): validation first casts (long)tv->tv_sec, and under the time64/long32 32-bit ARM ABI (time_t is 64-bit signed, long is 32-bit), a valid positive timestamp is converted to a negative number, so the function returns -1 and sets EINVAL before ever calling the RTC driver. The author used GNU Arm Embedded 10.3-2021.10 to verify type sizes and narrowing behavior in isolation.

The second issue is gmtime_r() handling of negative timestamps: the function returns non-NULL, but the fields are invalid. The four comparison values given are telling—-1 yields 1970-01-01 00:00:-1, -86400 yields 1970-01-00 00:00:00 (yday is -1), -31536000 produces a year field of 1970-01--364, and -2208988800, which should be 1900-01-01, yields 1970-01--25566. The root cause is that both division and modulo use C’s truncate-toward-zero semantics, so the remainder is negative for negative inputs, while the year loop can only move forward.

The third issue is truncation in timer_gettime(): the total remaining nanoseconds are first stored in an rt_uint32_t before being split into seconds and nanoseconds—10 seconds is 10 billion nanoseconds, and assigning that to a 32-bit variable drops the high bits outright. The affected configuration is RT_USING_POSIX_TIMER and RT_USING_CLOCK_TIME both enabled.

The fourth issue (10-24 20:25) is not a defect but an investigation: it organizes the problem of tick, clock_time, RTC, libc, and VDSO each maintaining their own time baseline into a design proposal with work items, listing ten shortcomings (inconsistent time setting, confused clockid semantics, fake soft-RTC synchronization, wraparound and overflow, hrtimer fallback, PM divergence, boot time-provisioning state, NTP version boundaries, etc.), giving six trackable work items A through F with P0-to-P2 priorities, and stating explicitly that ordinary MCUs reach a milestone endpoint after completing A through D. The issue itself declares it is static analysis, not compiled and not run on hardware.

Two companion fix proposals have been filed: #11928 makes settimeofday() validate by each field’s own type instead of uniformly casting to long; #11929 handles gmtime_r() normalization for pre-epoch timestamps. Both were submitted on 10-24 and remain unmerged.

2.2 sys_poll Wraparound on 32-bit RT-Smart: an 8-Byte Heap Block Traversed as 0x20000001 Entries, Out-of-Bounds Kernel Heap Read/Write (10-24)

Date: 2026-10-24 03:39 (creation time)　Source: Issue #11925

This defect issue was filed in the early hours of 10-24, with the problem lying between sys_poll() in components/lwp/lwp_syscall.c and poll() on the libc side. When computing the allocation size from the user-supplied nfds, nfds * sizeof(struct pollfd) is evaluated at size_t width on 32-bit targets, so exceeding roughly 179 million entries wraps to a small value—the kernel then traverses an 8-byte heap block as 0x20000001 entries, with reads and writes landing outside the heap.

Per the author’s scope: only 32-bit RT-Smart is affected; on 64-bit builds the product is promoted to 64 bits, so an oversized allocation simply fails with -ENOMEM rather than wrapping. The introducing commit is ecf2d821 (sync branch rt-smart, #6641) from 2022-12-03; the first affected version is v5.0.0, and v5.0.0 through v5.3.0 plus current master (5d1fb66d) are all in scope. Reproduction used bsp/qemu-vexpress-a9.

This differs from the previous issue’s 9PFS and NVMe family of “device- or server-controlled metadata used as a length”: here it is a user-controllable count wrapping at a narrow bit width—a classic integer boundary problem, but because the landing point is between the syscall entry and the kernel heap, the consequence is directly out-of-bounds kernel heap read/write. No fix proposal exists for this issue yet.

2.3 The ESP-IDF v6.1 Adaptation Merged Last Issue Turns C3/C6 Builds Red on master; Include-Order Fix Filed (10-25)

Date: 2026-10-25 17:49 (last update)　Source: PR #11926, PR #11870 (merged last issue)

The ESP32-C3/C6 adaptation to ESP-IDF v6.1 recorded in the previous issue was merged on 10-22, with the hardware-verification column marked “pending.” Two days later, C3/C6 builds on master turned red: per the proposal description, two CI runs on master (40043597502, 39929831359) reproduced the same phenomenon, and the RT-Thread BSP Static Build Check and MemBrowse Memory Report for all PRs turned red along with them.

The root cause is not the adaptation code itself but build ordering. The ESP-IDF package places a FreeRTOS.h scons shim under components/rtthread/scons/ that forwards via #include_next to <freertos/FreeRTOS.h>, requiring RT-Thread’s FreeRTOS-Wrapper include directory to come after the shim and before ESP-IDF’s bundled FreeRTOS V11 kernel headers. But the SConscript load order of the two packages is determined by directory traversal order and is not stable; once ESP-IDF loads first, #include_next resolves to the V11 header, all the defaults the Wrapper provides—configNUMBER_OF_CORES, configMINIMAL_STACK_SIZE, configUSE_PREEMPTION, etc.—go missing, and compiling drv_uart.c hits a direct #error.

The fix proposal touches only 3 files, pinning down the FreeRTOS include directory order. This is worth noting not for the defect itself but for the feedback chain: a merge last issue gated on “build passes” was caught by CI this issue for an ordering dependency, and a fix proposal was filed the same day.

2.4 Status Roundup of Existing Defect Proposals: NVMe Leak, 9PFS Length, tmpfs UAF, dlmodule Globals, FDT Depth All Awaiting Merge (10-25)

Date: 2026-10-25 (verification time)　Source: PR #11920, PR #11918, PR #11910, PR #11915, PR #11901

The fixes collected in the previous issue all received updates within the window but none were merged, their status stuck at “proposal filed, awaiting review”: NVMe leaking an allocation on every inactive namespace encountered (#11920, updated 10-25 00:35), 9PFS clamping the server length field to the bytes actually received (#11918, updated 10-24 17:19), tmpfs use-after-free when truncating to zero length (#11910, updated 10-23 23:31), and uninitialized globals in loadable modules (#11915, updated 10-24 17:27).

Two newly added within the window: first, a depth limit for FDT unflattening (#11901, updated 10-25 15:49)—fdt_unflatten_single() uses a fixed 64-entry stack np_stack to hold the traversal path and does not check depth before pushing, so a DTB deeper than 64 levels causes an out-of-bounds stack write; the author reproduced it on qemu-virt64-aarch64, and the fix is to compute the maximum depth beforehand with a separate manual-stack traversal and reject anything deeper than 63 levels before unflattening. Second, serial rx_indicate being cleared erroneously (#11931, updated 10-26 01:34)—after echo xxx /dev/uart0 the console stops responding; the author ruled out the old explanation of “open_flag being overwritten” (since rt_device_open() now doesn’t call the driver’s open at all when OFLAG_MASK matches) and pinned the real cause on serial_fops_close() unconditionally clearing rx_indicate while the device is still held by the console (ref_count only drops from 3 to 2).

The same batch also includes two driver-layer correctness fixes: #11891 changes TIOCGWINSZ to stop reading the terminal response via finsh_getchar() (which consumed input and only worked on the tshell thread) and skips UART reconfiguration when termios is unchanged to avoid resetting the FIFO; #11885 fixes an inverted UTIME_OMIT check in utimensat(), where a request to “not change mtime” previously overwrote mtime and ignored the caller-supplied timestamp.

III. Official and Community Activities

3.1 A System Software Perspective on Six RISC-V China Summits Published: The RISC-V Bottleneck Is Shifting from Cores to System Software (10-24)

Date: 2026-10-24 (published)　Source: EET-China: On-Device AI Becomes the New Battleground for RISC-V, RT-Thread column page

RT-Thread’s column on EET-China published a summit side report on 10-24, with the title framing it as “On-Device AI Becomes the New Battleground for RISC-V.” The report gives the summit scale as 1 main forum, 7 parallel sub-forums, plus a Member Day technical session, with topics covering AI, data centers and high-performance computing, software ecosystem, embedded and IoT, chip design and verification, and automotive electronics and robotics.

Two passages are directly relevant to RT-Thread: during the summit, RT-Thread exchanged views with several RISC-V IP and chip vendors on kernel adaptation, toolchain integration, and joint solution deployment; the industry assessment is that RISC-V already meets the conditions for scale in embedded and IoT, and the bottleneck is shifting from “cores” to system software, with operating system participation filling the gap in real-time performance, functional safety, and engineering delivery. The report does not elaborate on specific talk titles or product launches; the body is mostly images, so this issue only takes the verifiable statements above and does not fabricate details.

It should be noted that the summit itself was held in Shenzhen from 10-18 to 10-20, and the industry-side chip launches have already been covered in previous issues of the RISC-V Daily. This issue only adds the system software perspective and this RT-Thread-related piece, to avoid cross-topic duplication.

3.2 GDR: Bringing RT-Thread Kernel Object Inspection into GDB, with QEMU Closed-Loop Coverage of 3.1.x/4.0.x/4.1.x (10-25)

Date: 2026-10-25 (published)　Source: EET-China: Starting from LoRaWAN Porting Pitfalls, GDR repository

This is a rare community long-form article that treats “debugging scaffolding” as a formal engineering effort. The starting point was porting Semtech’s LoRaWAN protocol stack SWL2001 from Zephyr to a resource-constrained domestic MCU two years ago, with a trimmed RT-Thread Nano underneath; more than forty HAL interfaces were mapped one by one, and any semantic deviation only surfaced at runtime. The real difficulty was observation: once FinSH runs, the radio planner’s timing is perturbed—the act of observation changes the observed system; GDB natively only gives pointers, so inspecting a semaphore requires walking the linked list along rt_object_container, doing container_of arithmetic, and then casting—ten objects means fifty or sixty commands.

GDR’s approach is to solidify this kind of mechanical labor into GDB Python commands, providing three layers of capability: aggregate commands (rtthread threads/timers/system/semaphores/objects) output a global snapshot, with the thread table carrying two peak watermarks based on stack fill patterns, StkUsed and MaxStkUsed; convenience functions $gdr_thread("worker2") and $gdr_object(...) return native gdb.Value, with subsequent field drilling still using GDB expressions; pretty-printers collapse kernel objects into a one-line summary, for example a mutex directly showing its holder.

The essential difference from FinSH is that it is completely non-intrusive: all information is read only through GDB from symbols and target memory, without calling any function in the firmware, so it applies both to Nano scenarios with no shell at all and to post-mortem analysis after a HardFault when code can no longer execute. Several engineering decisions are worth noting: no more automatic RTOS detection (changed to explicit gdr init rtthread 4.0.5, but using symbol existence to detect configuration differences such as SMP, heap managers, and IPC components); all layout knowledge is centralized in one file marked COUPLED; QEMU is used to boot real firmware for pytest assertions, with the CI matrix covering Cortex-A9 (3.1.0 to 3.1.5, 4.x) and RV64 (4.0.4 to 4.1.1). The author also states the boundaries: he no longer does MCU development himself, the tool has only been verified in the QEMU matrix and has not yet been tested on real boards; future plans are an agent skill, a VSCode plugin, and FreeRTOS adaptation.

3.3 Two Community Long-Form Articles: Custom Installation of Env Tool v2.0.3, and a Full Investigation of 24 Implicit Declaration Warnings in Studio (10-25)

Date: 2026-10-25 18:45 to 18:46 (published)　Source: Env tool v2.0.3 usage notes, Investigation of 24 implicit declaration warnings in Studio

The community article API released two toolchain long-form articles in succession on the evening of 10-25, both of the “pitfall plus fix” type.

The first covers custom-location installation of Env 2.0.3. Env has undergone an architectural refactor since v2.0: the command entry point is unified as rt-env, with menuconfig/pkgs/scons becoming its subcommands, plus sdk, plugin, webui, system; all dependencies run in a Python virtual environment; a new plugin system and browser-side WebUI are added; and each terminal must first dot-source an activation script before use. The official install script hardcodes the location as ~/.env, so putting the toolchain inside a project directory requires manually replicating the directory structure; the article provides complete steps and a locally verified version combination (rt-env v2.0.3, SCons 4.11.1, kconfiglib 14.1.0, pyyaml 6.0.3). The article also flags a compatibility red line: Env v2.0 fully supports the master branch of RT-Thread 5.1.0 and above, while 5.1.0 and earlier continue to use v1.5.x.

The second is a full traceback of RT-Thread Studio build warnings, which corresponds exactly to mainline proposal #11930 in this issue. When a project exported by scons --dist-ide is compiled in Studio, five kernel source files report 24 -Wimplicit-function-declaration warnings (clock.c 1, ipc.c 7, thread.c 12, timer.c 1, scheduler_comm.c 3), all pointing to the rt_sched_* family of internal scheduling APIs. The author’s investigation path was: first compare the compile command lines of the two builds, finding that scons carries -D__RT_KERNEL_SOURCE__ while Studio’s make does not; then return to include/rtsched.h to find the macro guard; finally locate that the macro is injected via LOCAL_CPPDEFINES, while the Eclipse project generator before the Studio build only collects global CPPDEFINES, so LOCAL_CPPDEFINES never makes it into the generated rtconfig_preinc.h. The article specifically warns that these warnings are upgraded to errors by default starting with GCC 14, so for those using newer toolchains this is a build failure rather than noise. The corresponding proposal #11930 changes only 1 line, moving the macro to the Kernel group’s global CPPDEFINES, aligning with the msvc branch’s approach.

3.4 Live Stream on the Evening of 10-26: RT-Thread and an Edge AI Hand Rehabilitation Exoskeleton (10-25)

Date: 2026-10-25 (published)　Source: EET-China: Next Monday at 8 PM

A live stream preview published on 10-25: from 20:00 to 21:00 on 10-26, community developer Cui Junshuo shares a hand rehabilitation exoskeleton project. The work targets hand function training for people with stroke, post-hand-injury surgery, and peripheral nerve injury, building perception, recognition, assistance, interaction, and assessment into a single platform. Two highlights are described fairly concretely: the recognition chain from EMG signals to motion intent, and how the two cores on one development board divide the work.

Thematically, this aligns with the on-device Agent work in 3.5 and the ai/Agent package update in 4.2 of this issue: community content on the RT-Thread side is shifting from “blinking an LED and getting online” to complete-device solutions of “sensing plus on-device inference,” with dual-core heterogeneity and real-time task partitioning being a recurring structure.

3.5 Three Embedded Competition Projects: On-Device Agent Multi-Sensor Fusion, ART-Pi2 USB Enumeration Diagnostics, OpenMV Suspect Tracking (10-24/10-25)

Date: 2026-10-24 12:03 to 2026-10-25 10:39 (published)　Source: On-device Agent multi-sensor fusion, ART-Pi2 USB enumeration diagnostic tool, OpenMV suspect tracking

Three 2026 embedded competition projects were released in a concentrated window, with differing hardware and software orientations.

The on-device Agent piece is based on the Infineon Edgi-Talk board (PSoC E84: Cortex-M55 plus Ethos-U55 NPU, with an additional Cortex-M33 coprocessor, up to 6 MB on-chip SRAM), and the system consists of distributed sensor acquisition, MQTT aggregation, on-device multi-source fusion, intelligent recognition and decision-making, plus an LVGL dashboard. A noteworthy implementation detail: the agent package wraps MQTT subscribe, unsubscribe, and history query as “tools,” and the agent kernel schedules them according to registered tools; the UI is one thread plus a set of timers, with an 800×480 logical canvas drawn on a 480×800 portrait screen and then rotated by the GPU, and all pages are modified only in the LVGL thread. The Agent kernel’s framework documentation points to the author’s own repository.

The ART-Pi2 piece is about USB enumeration observability: using CherryUSB’s host adaptation layer to record request parameters, return status, and descriptor bytes at the start and completion of control transfers, with events going into a bounded queue, and then an RT-Thread analysis thread calling a shared C99 rule core to generate verdicts; rule conclusions retain source event and byte references, the board publishes immutable evidence snapshots, and a 4.3-inch LCD and a LAN web page display around this session, allowing tracing from a rule conclusion all the way back to the original bytes. The hardware is an ART-Pi2 (STM32H7R7) plus an ALIENTEK 4.3-inch RGB screen, with Wi-Fi provided by the onboard CYW43438.

The third is pedestrian tracking with an RA8P1 Titan Mini plus a PC host: the board runs YOLOv8n (192 input, Ethos-U55 NPU) with OpenMV firmware, sending detection results and video streams to a Python host via a custom USB CDC protocol; the operator clicks once on the image to lock onto a target, and a red box follows with motion prediction and is burned into the recording. Measured frame rates are given in detail: QVGA without detection about 25 fps, with detection 16 to 19 fps; VGA with detection about 8 fps.

IV. Ecosystem and Vendor Adaptation

4.1 TriCore (AURIX) enters the Env SDK: tricore-gcc 13.4.1 and qemu-tricore packages merged, covering TC2xx/TC3xx/TC4xx (10-26)

Date: 2026-10-26 00:10 and 07:57 (merge times)　Source: RT-Thread/sdk PR #9, RT-Thread/sdk PR #10, toolchains-ci v1.12, toolchains-ci v1.13

The most substantive item this period is not in the main repository but in the Env SDK repository: two PRs were merged in succession, adding the compile and emulation path for Infineon TriCore (AURIX), an automotive-grade architecture, to the RT-Thread toolchain system.

The first is the tricore-gcc toolchain package, 4 files +112, with one set of Kconfig and package.json each for Linux and Windows, package name tricore-gcc, version v13.4.1, switch PKG_USING_TRICORE_GCC. The upstream toolchain is NoMore201/tricore-gcc-toolchain (a downstream of EEESlab 11.3.0, with CI auto-build), composed of GCC 13.4.1, binutils 2.40, newlib, and GDB 14.0, target triple tricore-elf, covering TriCore 1.3/1.3.1/1.6/1.6.1/1.6.2/1.8, corresponding to the TC2xx, TC3xx, and TC4xx chip generations. Releases are in toolchains-ci v1.12: Linux package 251 MB, Windows package 466 MB. The Windows package adds the libwinpthread-1.dll that upstream omitted (placed in both bin/ and libexec/gcc/tricore-elf/13.4.1/); otherwise the compiler will not start on machines without MSYS2 installed.

The second is the qemu-tricore emulator package, likewise 4 files +112, switch PKG_USING_QEMU_TRICORE, version v1.0.0, releases in toolchains-ci v1.13 (Linux 5.4 MB, Windows 9.4 MB). The background is stated clearly: the QEMU 9.2.3 bundled with the tricore-gcc package only has the KIT_AURIX_TC277_TRB (TC2xx) and tricore_testboard machines and cannot emulate TC3/TC4, so a branch used on the Zephyr side was brought in separately. The source is the release/ifx/tricore-1.0 branch of linumiz/qemu-tricore (tag v1.0.0, QEMU 10.2.94); the three supported machines are KIT_AURIX_TC277_TRB, KIT_AURIX_TC397B_TRB, and KIT_A3G_TC4D7_LITE, with CPU models tc2x/tc3x/tc4x. Peripherals cover only the ASCLIN0 serial port, STM system timer, IR interrupt routing, SCU and clocks, SFR bridge, and on-chip RAM and Flash mapping; CAN, Ethernet, ADC, GPIO, and DMA are all absent—enough to run the kernel and a serial shell, not enough for peripheral driver validation. To support Windows cross-compilation, two portability issues were also fixed on the TriCore side (ENOTBLK/O_* conditional compilation and the hwaddr log format).

Two points must be stated clearly. First, this is only toolchain and emulation first: the mainline libcpu directory currently has 19 architectures (aarch64, arc, arm, avr32, blackfin, c-sky, ia32, m16c, mips, nios, ppc, risc-v, rx, sim, sparc-v8, ti-dsp, unicore32, v850, xilinx), and there is no tricore, nor is there an AURIX board-level directory under bsp; the TriCore records findable in the repository are several attempts around 2020 (#4311 architecture adaptation, #4488 and #4527 for TASKING toolchain and FinSH support), all in Closed status and never merged into mainline. Second, the Windows packages of both proposals only underwent PE import table checks and were not run on real Windows machines; the authors themselves suggest in the PRs running a compile once more before merging.

Taken together, the significance lies in the change of approach: early TriCore adaptation relied on the TASKING commercial toolchain, which had a high barrier and was hard to bring into the community; this time it switches to open-source GCC 13.4.1 plus QEMU emulation, first solving “can compile, can run, can debug”—BSP and drivers are a matter for later. For automotive scenarios (domain controllers, safety islands, where AURIX TC3xx/TC4xx are the mainstay), this is a necessary but not sufficient step.

4.2 ai/Agent package adds a speech transcription endpoint; default backend switches from SiliconFlow to the official DeepSeek API (10-23)

Date: 2026-10-23 10:12 (merge time)　Source: RT-Thread-packages PR #2046

The ai/Agent package in the package index updated its Kconfig within the window, +32/-4, touching only one file, but two default value changes are worth noting. The default model name changed from deepseek-ai/DeepSeek-V4-Pro to deepseek-flash; the default API address changed from the third-party aggregation platform’s api.siliconflow.cn to the official DeepSeek endpoint api.deepseek.com (both share the same chat/completions path)—that is, the default path switched from an aggregation platform to the vendor’s own endpoint.

What is new is a speech transcription configuration block: a toggle option (PKG_AGENT_STT_ENABLE/DISABLE, default on), plus an STT File Server string whose semantics are an HTTP file upload endpoint, with the example being a local address plus the /stt path. The description of the multimodal switch was also expanded from “image/file” to “image/file/audio”, corresponding to the STT configuration.

This can be read alongside the edge-side Agent competition entry in section 3.5 of this issue: in that entry the agent package registers MQTT operations as tools for kernel scheduling, and the Agent framework repository it references belongs to the same GitHub account as the author of this proposal; one explains usage, the other changes configuration, both pointing to the same usage pattern—treating the RTOS as the agent’s runtime and letting the model operate device capabilities through “tools”. After the default backend switches to the official API, the out-of-the-box barrier will be somewhat lower, but the cost is binding the network dependency to a single vendor, which needs to be weighed on its own in resource-constrained scenarios.

4.3 Allwinner F101 and H616 BSP proposals span 172 files; ESP32-S3-DevKitM-1 also gets board-level support (10-24/10-26)

Date: 2026-10-24 03:32 and 2026-10-26 02:05 (last updated)　Source: PR #11877, PR #11844, PR #11903

The BSP side this window is mainly proposals; the largest is the Allwinner line (#11877), 172 files +35428/-6, bringing in both F101 YuzukiNeko and H616 at once. The F101 side adds the Sun252i device model driver set: clock, reset, pinctrl, DMA, SDIO, SPI, USB, audio, temperature, RTC, PWM, ADC, NVMEM, watchdog, DVFS, G2D, and JPEG; on the display side it adds Sunxi DE0/TCON0 backends supporting RGB, LVDS, and MIPI-DSI, and provides board-level configuration and validation commands for the ST77916 QSPI screen; it also adds a glue layer for Sunxi MUSB under CherryUSB, plus a batch of shared driver framework fixes (power domains, DVFS, graphics, UART reset and register shifts, QSPI configuration, temperature work queue, input capture, device model USB integration). The H616 side is another driver set: CCU/reset, pinctrl, temperature, CPU DVFS, codec, AHUB HDMI audio, CE hardware crypto, DE33 HDMI framebuffer, TCON TOP, plus RTC, DMA, SDIO, I2C, SPI, PWM, watchdog, IR, SID NVMEM, GPIO LED, JPEG decoding, G2D, GPADC, LRADC, and newly added AXP313A regulator support.

The other item is ESP32-S3-DevKitM-1 (#11844), 52 files +7152/-29. This one requires distinguishing the core: ESP32-S3 is Xtensa, not among the RISC-V parts (only C3/C6 are). The proposal notes several practical details: the bootloader and partition table in builtin_imgs must be S3’s and cannot be replaced with C3’s; Flash is DIO, 8 MB, 80 MHz, with the application at 0x10000; three board-level shared changes (the SoC is brought into the choice with the default still C3, the S3 tick interrupt only adds tick, and sdkconfig.h is redirected to include sdkconfig_s3.h). On-board validation was done: it can enter msh, help/version/ps/free respond, the version reports 5.3.1, free shows total 76704, used 12192, available 64512, and in ps the error column for timer and main shows EINTRPT but the shell and tick work normally. GPIO, I2C, SPI, ADC, PWM, Wi-Fi, BLE, and the on-chip 8 MB PSRAM were not validated on board, and the README marks them as pending support.

There is also a small one, the D1s QEMU boot script (#11903), 4 files +145, adding qemu-d1s.sh and documentation to the allwinner d1s BSP so that this BSP can run directly on the d1s machine; the author notes that the script and documentation were AI-assisted, manually reviewed, and actually tested.

4.4 Drivers and CI: OSPI octal-line Flash, I2C control transaction serialization, STM32 package test concurrency lock (10-23/10-25)

Date: 2026-10-23 to 2026-10-25 (update and merge times)　Source: PR #11912, PR #11820, pkgs-test PR #37

The largest driver-layer item is OSPI and OctaFlash support (#11912), 32 files. Previously RT-Thread’s SPI driver layer had no native OSPI path, and octal-line Flash could only work around it. The change adds OSPI bus, device, configuration, and message definitions at the components layer, along with transfer helper functions and build options, while retaining the existing SPI and QSPI paths; it wires OSPI transfer and probing into SFUD, supporting read, write, erase, and status/control operations, and adds MX25LM51245G to the SFUD device table for validation; to make the whole path work on hardware, it also adds a generic STM32 OctoSPI driver and board-level OSPI Flash support for stm32l4r9-st-eval, enabling SFUD to access in both 1-1-1 and 8-8-8 (OPI STR/DTR) modes.

The I2C item (#11820) fixes a race between bus control and transfer: rt_i2c_control() could change controller configuration while rt_i2c_transfer() was using the bus, especially on SET_MAX_HZ. The fix has control commands take the same bus mutex and release through a unified exit, and documents in the API docs that control requires thread context. Validation used a host-side pthread mutex adapter, covering concurrent transfer and control, control and control, frequency updates, lock and callback errors, and nested transfer within control; the unpatched source fails in the same regression set.

The CI item is in pkgs-test (#37), 1 file +11/-7, explained thoroughly: STM32 package tests run multiple versions in parallel, each task has its own BSP copy, but they still share the HAL/CMSIS driver directories under bsp/stm32/libraries; the original sem_stm32 only protected compilation, not dependency updates, so one task could git pull into the same directory while another task’s dependency clone was incomplete, Git would report untracked files would be overwritten and abort, and the failure would be uniformly reported by the framework as compile failure. The test merged in the previous issue, #11870, fell victim to exactly this (failure logs are available). The fix moves the lock up into __build(), putting dependency updates and compilation in the same critical section, while removing the duplicate locking in __build_scons() to avoid self-deadlock, and uses try/finally to guarantee release on exceptions.

V. Summary and Trend Observations

  • Automotive-grade architectures are taking a “toolchain-first” path: TriCore/AURIX entered the Env SDK this time rather than the main repository—the two packages, open-source GCC 13.4.1 and qemu-tricore, first fill in compilation and emulation, while the mainline libcpu still has no tricore port and there is no AURIX board-level directory under bsp. Compared with the batch of attempts around 2020 that relied on the TASKING commercial toolchain (all of which ended as Closed), this path is more likely to land, but it is still short of “runnable on board” by a BSP and drivers.
  • The mainline is extremely quiet while the proposal side is very active: in 72 hours, master had only 2 commits, while within the window 25 PRs were updated and 6 merged (2 in the main repository, 2 in sdk, 1 in packages, 1 in pkgs-test). The merge actions clustered on Friday evening and Sunday night; review did not stop, and the development side is indeed winding down.
  • Defect research is shifting from single points to subsystems: the time subsystem produced four tickets overnight (three defects plus one investigation with work items A through F), and two fix proposals were submitted the next day, forming a short “report—analyze—fix” loop; the sys_poll wraparound in lwp separately highlights the integer boundary problem of 32-bit RT-Smart on user-space-controllable counters, complementing the previous issue’s family of defects where “device or server-side metadata is treated as a length,” indicating the kernel is still paying for historical baggage (ecf2d821 traces back to 2022).
  • Merges gated on builds are starting to backfire through CI: two days after the previous issue’s ESP-IDF v6.1 adaptation was merged, the C3/C6 builds on master turned red, affecting the static build checks of all PRs; a fix proposal was opened the same day. This chain is healthy in itself, but it also shows that the “not compiled locally, verified by CI” approach needs accompanying ordering-stability guarantees.
  • On-device AI is shifting from running models to connecting tools: the ai/Agent package adds an STT upload endpoint and switches the default backend to the official DeepSeek API; a community competition entry uses the agent package to register MQTT operations as tools for kernel scheduling; plus the 10-26 evening livestream on “dual-core plus EMG intent”—the direction is consistent: the RTOS is being treated as an agent runtime, and real-time behavior and heterogeneous division of labor are its selling points relative to general-purpose Linux.

5.2 Limitations and Deduplication Notes

  • This issue covers a 72-hour window (10-23 08:00 to 10-26 08:00), a Monday, spanning Saturday and Sunday, and connects with the previous issue (10-22 08:00 to 10-23 08:00, 24 hours) with no overlap.
  • Deduplication against the previous issue: #11920, #11918, #11910, and #11915 were already covered last issue; this issue only summarizes them collectively when their status has actually updated, without repeating the defect mechanisms; #11870 was covered last issue as “blocker resolved, on-board verification pending,” and this issue only writes about the build regression it caused on master and the new fix proposal; #11896 and #11894 were already recorded last issue, and this issue adds the latest status and change details.
  • The anonymous GitHub API rate limit was exhausted midway through collection, so subsequent work relied on web-side verification and existing search results; no organization-level full push audit was performed. The top 100 repositories by sort=pushed show 5 repositories with pushes within the window (sdk, toolchains-ci, rt-thread, pkgs-test, packages).
  • The official news API is still stuck at 2026-06-17 (5 items returned this time), and the official website’s news list page is front-end rendered, so scraping yields only an empty shell; the community article API added 5 articles this issue, all of whose titles and update times have been verified.
  • On the industry media side, the EETimes China RT-Thread column had 4 articles within the window: the 10-24 summit piece, the 10-25 GDR and exoskeleton livestream, and the 10-23 CherryUSB HID tutorial; the last was published close to the window start and is a tutorial, so it is not listed separately in this issue. When searching, note that a422289 in the same column is an old piece from the 2025 fifth summit with a similar title that is easy to confuse; this issue uses a533499 from the 10-24 column page as authoritative.
  • In the topic:rt-thread ecosystem search, 2 repositories had pushes within the window: sejtam-dev/AKP05E-Open-Firmware (ArtInChip D13x, RISC-V, third-party open-source firmware based on RT-Thread, 0 stars) and zlgopen/awtk (general-purpose embedded GUI, whose commits have no specific connection to RT-Thread); both serve as ecosystem references and are not listed as separate entries.
  • No on-board verification was performed: the Windows builds of the two TriCore packages only underwent PE import table checks; the three time subsystem tickets were reproduced in source-level isolation; the hardware verification of the OSPI proposal is based on stm32l4r9-st-eval. The relevant conclusions in the report are stated as in the original sources and are not extrapolated.

Appendix: Source Verification Table

Source Verification Result
RT-Thread official news API (organization category) No new items; still returns 5, latest stops at 06-17
Official website news list page Front-end dynamic rendering; scraping only yields an empty loading shell
Community article API (article) 5 new posts in window: Env v2.0.3 writeup, Studio 24 warning troubleshooting, three embedded competition entries
GitHub main repo commits 2 in window: #11859 clang-format rules, #11893 lwIP loopback
GitHub main repo PRs 25 updated, 2 merged
GitHub main repo Issues 5 newly opened: #11922 to #11925 and #11927, concentrated in the time subsystem and lwp
GitHub main repo releases / tags No new releases; latest remains v5.3.0 from 09-10
GitHub RT-Thread/sdk 2 merged: tricore-gcc and qemu-tricore; toolchains-ci published v1.12, v1.13
GitHub RT-Thread/packages 1 merged: STT configuration and DeepSeek default backend for ai/Agent
GitHub RT-Thread/pkgs-test 1 merged: STM32 package test concurrency lock fix
GitHub topic:rt-thread 2 repos pushed, both ecosystem references, not included
Google News aggregation (Chinese and English, via proxy) Chinese 7-day window: 1 valid item (EET-China 10-24 summit piece); English: 0
HN Algolia All four candidates were literal “threads” false matches, removed
Industry media (EET-China column) 4 in window, 3 included; 10-23 tutorial piece not listed separately
Mainline architecture directory check libcpu currently has 19 architectures, no tricore; old proposal #4311 status is Closed

Full Source List