Frédéric Desbiens
62e966f6bf
* Enabled BTCM and measured what it offers as a data store
BTCM was disabled because of a regression that turned out not to exist; the
claim was retracted in the previous commit. It is enabled now, and this
measures why that is worth doing: 16 KB at zero wait states, where ATCM has
one, and no cache in the path at all.
Enabling it needs three things, all of which existed for ATCM already: the
region register write at EL2, an MPU region, and an ECC preload before any read
(TRM 6.2.2). BTCM accepts 32-bit stores where ATCM needs 64-bit, which
tcm_preload already handles.
The cache benchmark now sweeps three memories rather than one, four loop
alignments each. At the alignments where the loop is not instruction-fetch
bound:
memory cold (uncached) warm (cached) gain
DRAM2 half-speed 857,540 651,436 24.0%
DRAM0 full-speed 797,824 651,297 18.3%
BTCM zero wait 694,689 651,369 6.2%
Three things follow.
Warm times are identical across all three memories, within 0.02%. Once the data
cache is working the backing store barely matters, because the working set fits
in it.
Cold times rank as the reference manual predicts: BTCM fastest, then DRAM0,
then DRAM2 at half the core frequency (S32Z2 RM 6.3.6).
BTCM still shows a 6.2% gain when the caches are enabled, and that cannot be
the data cache, because an enabled TCM is Non-cacheable Non-shareable Normal
memory whatever the MPU says. It is the instruction cache on the timing loop.
This probe has always measured both caches together; three memories side by
side is what makes that visible.
The number that matters for placing data in BTCM: uncached BTCM is within 6.6%
of the best cached case, where uncached DRAM0 is 22% off it. Data in BTCM runs
at close to cache-hit speed with no cache to miss, which is the determinism
argument stated as a measurement rather than an assertion.
DRAM2's sweep is unchanged with BTCM enabled, 0 and 0 and 240 and 240, which
independently confirms the retraction.
Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
* Put a ThreadX thread stack in BTCM
The code side of TCM was done in #630; this is the data side. One of the demo's
three thread stacks now lives in BTCM and the other two stay in DRAM0, so a run
exercises both paths and a mistake in either shows up.
link.lds gains a BTCM region and a .btcm_bss NOLOAD section, so a stack is an
ordinary C array with a section attribute and the linker checks it fits, rather
than a hardcoded address that silently overflows the bank.
entry.S preloads the whole bank at EL2, and that is not optional. ECC is enabled
on this part, so a TCM location must be written before it can be read (TRM
6.2.2), and a stack is read before the program writes it -- the first context
restore pops what tx_thread_create built into it. The preload has to happen
before any C runs, because the demo images do not run bsp_boot.c, which is where
the ATCM preload lives. 32-bit stores suffice for BTCM where ATCM needs 64-bit.
Why BTCM for a stack: 16 KB at zero wait states where ATCM has one, and never
cached whatever the MPU says about it. Measured in the previous commit, uncached
BTCM comes within 6.6% of the best cached case while uncached DRAM0 is 22% off
it, so stack access runs at close to cache-hit speed without depending on a line
being resident. That is the property a determinism argument needs.
What this commit does not claim: no thread-level timing improvement has been
measured. The case for BTCM here rests on the memory characterisation and on
removing the cache from the path, not on a measured context-switch figure. That
measurement is worth doing and has not been done.
Verified on the S32Z280-594EVB. The demo reports its stack addresses so the
placement is visible rather than implied -- sleeper at 0x30100000 in BTCM,
spinner and judge in DRAM0 -- and passes with 100 ticks, 20 sleeper wakeups and
20 preemptions, so a real thread schedules, preempts and context-switches on a
tightly-coupled-memory stack. The boot image still passes six of six probes.
Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
Eclipse ThreadX RTOS
This advanced real-time operating system (RTOS) is designed specifically for deeply embedded applications. Among the multiple benefits it provides are advanced scheduling facilities, message passing, interrupt management, and messaging services. Eclipse ThreadX RTOS has many advanced features, including picokernel architecture, preemption threshold, event chaining, and a rich set of system services.
Here are the key features and modules of ThreadX:
Getting Started
Eclipse ThreadX has been integrated to the semiconductor's SDKs and development environment. You can develop using the tools of choice from STMicroelectronics, NXP, Renesas and Microchip.
We also provide getting started guide and samples using development boards from semiconductors you can build and test with.
See Overview of Eclipse ThreadX RTOS for the high-level overview.
Repository Structure and Usage
Directory layout
.
├── cmake # CMakelist files for building the project
├── common # Core ThreadX files
├── common_modules # Core ThreadX module files
├── common_smp # Core ThreadX SMP files
├── docs # Documentation supplements
├── ports # Architecture and compiler specific files. See below for directory breakdown
│ ├── cortex_m7
│ │ ├── iar # Example IAR compiler sample project
│ │ │ ├── example build # IAR workspace and sample project files
│ │ │ ├── inc # tx_port.h for this architecture
│ │ │ └── src # Source files for this architecture
│ │ ├── ac6 # Example ac6/Keil sample project
│ │ ├── gnu # Example gnu sample project
│ │ └── ...
│ └── ...
├── ports_modules # Architecture and compiler specific files for threadX modules
├── ports_smp # Architecture and compiler specific files for threadX SMP
├── samples # demo_threadx.c
└── utility # Test cases and utilities
Branches & Releases
The master branch has the most recent code with all new features and bug fixes. It does not represent the latest General Availability (GA) release of the library. Each official release (preview or GA) will be tagged to mark the commit and push it into the Github releases tab, e.g. v6.2-rel.
When you see xx-xx-xxxx, 6.x or x.x in function header, this means the file is not officially released yet. They will be updated in the next release. See example below.
/**************************************************************************/
/* */
/* FUNCTION RELEASE */
/* */
/* _tx_initialize_low_level Cortex-M23/GNU */
/* 6.x */
/* AUTHOR */
/* */
/* Scott Larson, Microsoft Corporation */
/* */
/* DESCRIPTION */
/* */
/* This function is responsible for any low-level processor */
/* initialization, including setting up interrupt vectors, setting */
/* up a periodic timer interrupt source, saving the system stack */
/* pointer for use in ISR processing later, and finding the first */
/* available RAM memory address for tx_application_define. */
/* */
/* INPUT */
/* */
/* None */
/* */
/* OUTPUT */
/* */
/* None */
/* */
/* CALLS */
/* */
/* None */
/* */
/* CALLED BY */
/* */
/* _tx_initialize_kernel_enter ThreadX entry function */
/* */
/* RELEASE HISTORY */
/* */
/* DATE NAME DESCRIPTION */
/* */
/* 09-30-2020 Scott Larson Initial Version 6.1 */
/* xx-xx-xxxx Scott Larson Include tx_user.h, */
/* resulting in version 6.x */
/* */
/**************************************************************************/
Supported Architecture Ports
ThreadX
arc_em cortex_a12 cortex_m0 cortex_r4
arc_hs cortex_a15 cortex_m23 cortex_r5
arm11 cortex_a17 cortex_m3 cortex_r7
arm9 cortex_a34 cortex_m33
c667x cortex_a35 cortex_m4
linux cortex_a5 cortex_m55
risc-v32 cortex_a53 cortex_m7
rxv1 cortex_a55 cortex_m85
rxv2 cortex_a57
rxv3 cortex_a5x
win32 cortex_a65
xtensa cortex_a65ae
cortex_a7
cortex_a72
cortex_a73
cortex_a75
cortex_a76
cortex_a76ae
cortex_a77
cortex_a8
cortex_a9
ThreadX Modules
Eclipse ThreadX Modules component provides an infrastructure for applications to dynamically load modules that are built separately from the resident portion of the application.
cortex_a35
cortex_a35_smp
cortex_a7
cortex_m0+
cortex_m23
cortex_m3
cortex_m33
cortex_m4
cortex_m7
cortex_r4
rxv2
ThreadX SMP
Eclipse ThreadX SMP is a high-performance real-time SMP kernel designed specifically for embedded applications.
arc_hs_smp
cortex_a34_smp
cortex_a35_smp
cortex_a53_smp
cortex_a55_smp
cortex_a57_smp
cortex_a5x_smp
cortex_a5_smp
cortex_a65ae_smp
cortex_a65_smp
cortex_a72_smp
cortex_a73_smp
cortex_a75_smp
cortex_a76ae_smp
cortex_a76_smp
cortex_a77_smp
cortex_a78_smp
cortex_a7_smp
cortex_a9_smp
linux
Adaptation layer for ThreadX
ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications. To help ease application migration to ThreadX RTOS, Eclipse ThreadX provides adaption layers for various legacy RTOS APIs (FreeRTOS, POSIX, OSEK, etc.).
Component dependencies
The main components of ThreadX RTOS are each provided in their own repository, but there are dependencies between them, as shown in the following graph. This is important to understand when setting up your builds.
You will have to take the dependency graph above into account when building anything other than ThreadX itself.
Building and using the library
Instruction for building the ThreadX as static library using Arm GNU Toolchain and CMake. If you are using toolchain and IDE from semiconductor, you might follow its own instructions to use ThreadX RTOS components as explained in the Getting Started section.
-
Install the following tools:
- CMake version 3.0 or later
- Arm GNU Toolchain for arm-none-eabi
- Ninja
-
Cloning the repo
$ git clone https://github.com/eclipse-threadx/threadx.git -
Define the features and addons you need in
tx_user.hand build together with the component source code. You can refer totx_user_sample.has an example. -
Building as a static library
Each component of ThreadX RTOS comes with a composable CMake-based build system that supports many different MCUs and host systems. Integrating any of these components into your device app code is as simple as adding a git submodule and then including it in your build using the CMake
add_subdirectory().While the typical usage pattern is to include ThreadX into your device code source tree to be built & linked with your code, you can compile this project as a standalone static library to confirm your build is set up correctly.
An example of building the library for Cortex-M4:
$ cmake -Bbuild -GNinja -DCMAKE_TOOLCHAIN_FILE=cmake/cortex_m4.cmake . $ cmake --build ./build
Licensing
License terms for using Eclipse ThreadX are defined in the LICENSE.txt file of this repo. Please refer to this file for all definitive licensing information for all content, incl. the history of this repo.
Resources
The following are references to additional ThreadX RTOS resources:
- Product introduction: https://github.com/eclipse-threadx/rtos-docs
- Product issues and bugs, or feature requests: https://github.com/eclipse-threadx/threadx/issues
- TraceX Installer: https://aka.ms/azrtos-tracex-installer
You can also check previous questions or ask new ones on StackOverflow using the threadx-rtos and threadx tags.
Security
Eclipse ThreadX provides OEMs with components to secure communication and to create code and data isolation using underlying MCU/MPU hardware protection mechanisms. It is ultimately the responsibility of the device builder to ensure the device fully meets the evolving security requirements associated with its specific use case.
Contribution
Please follow the instructions provided in the CONTRIBUTING.md for the corresponding repository.