arch: add TriCore architecture and Infineon AURIX platform support by parthitce · Pull Request #19041 · apache/nuttx

parthitce · 2026-06-04T16:37:11Z

Summary

This PR adds support for the TriCore architecture used in the Infineon AURIX TC3X (TC1.6P core) and TC4X (TC1.8P core) SoC families. It also adds support for two evaluation boards, the AURIX Lite Kit TC375 and the AURIX Lite Kit TC4D7.

The TriCore code that was in apache/nuttx before this change depends on the iLLD vendor SDK that has to be downloaded at build time. That arrangement does not fit an upstream tree and breaks any offline build. The chip-per-name directory layout under arch/tricore/src and boards/tricore was built around that iLLD path and only ever held two boards that do not build on current master and are not in CI.

This PR removes the iLLD path along with those legacy directories and replaces them with a family-first layout under arch/tricore/src: common, aurix (shared peripherals), tc3x and tc4x. The new port uses direct SFR access and works with both GNU GCC (tricore-elf-gcc) and the HighTec LLVM compiler.

Impact

Users: a new architecture port. Two boards are available: a2g-tc375-lite and a3g-tc4d7-lite. Each board has an nsh defconfig for GCC and an nsh-llvm defconfig for HighTec LLVM.
Build: adds Make and CMake support for tricore-elf-gcc and for the HighTec clang toolchain. No other architecture is touched.
Hardware: only UART is wired in this initial port. GPIO pinmuxing is available for follow-up drivers. Other peripherals (SPI, MCAN, QSPI, and so on) will follow in upcoming series.
Documentation: Documentation/platforms/tricore is refreshed to match the new layout, toolchains and drivers.
Security: no security-relevant changes outside the new arch.
Compatibility: the iLLD-based TriCore configurations are removed. The two boards that lived under the old layout (KIT_A2G_TC397_5V_TFT and TRIBOARD_TC4X9_COM) do not build on current master and have no test list entry, so no working user is affected.

Testing

Host machine: Linux x86_64.

Toolchains:

GNU GCC: tricore-elf-gcc 11.3.1
HighTec LLVM: clang 10.2.0 (uses a HighTec license through $RLM_LICENSE)
OpenOCD: tricore-openocd with the Infineon AURIX patches, used for flashing real hardware

Boards used on real hardware:

AURIX Lite Kit TC375 (a2g-tc375-lite)
AURIX Lite Kit TC4D7 (a3g-tc4d7-lite)

Hardware boot and NSH:

Both boards flashed through OpenOCD one-shot.
NSH banner reached on the on-board USB serial console (ASCLIN0 at 115200, 8N1).
uname -a returns the correct build identifier and board name on both boards.

ostest with CONFIG_TESTING_OSTEST=y and CONFIG_TESTING_OSTEST_LOOPS=2:

TC375 Lite Kit: PASSED 6, FAILED 0, no panic or assert, clean user_main exit.
TC4D7 Lite Kit: PASSED 6, FAILED 0, no panic or assert, clean user_main exit.

Subtests exercised by ostest include mutex_test, sched_lock, cond_test, cancel_test (pthread_join against a cancelled thread), robust_test (robust mutexes), the round-robin scheduler test with two get_primes threads, and task_restart. The thread-heavy workload exercises the CSA allocator on every task and thread creation.

Style and compliance:

tools/checkpatch.sh -g -m on the 12-commit range: All checks pass.

Full boot and ostest logs from both boards are kept in the local test output directory.
All the downstream efforts are tracked at https://gitlab.com/linumiz/infineon/release

Signed-off-by: Saravanan Sekar saravanan@linumiz.com
Signed-off-by: Parthiban Nallathambi parthiban@linumiz.com

The iLLD path requires an external SDK download at build time. An upstream tree cannot depend on a build-time network fetch, and the requirement also prevents any offline build. The chip-per-name directories under arch/tricore/src and boards/tricore were built around that iLLD path. Removing them together with the SDK lets the following commits introduce a family-based layout against a clean slate. Co-Authored-By: Saravanan Sekar <saravanan@linumiz.com> Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

The arch code introduced in the following commits is organized by family: arch/tricore/src/tc3x and arch/tricore/src/tc4x hold the code shared across the TC3X and TC4X chip variants respectively. On AURIX all chips in a family share their ISA and peripherals, so the family-shared code is the bulk of the port. Restructure Kconfig to match: the user selects a family first (ARCH_CHIP_FAMILY_TC3X or ARCH_CHIP_FAMILY_TC4X) and then picks a chip inside it. The selectors then mirror the directory layout. Only the TC1.8 ISA has its own Kconfig symbol (TRICORE_TC18), which TC4X selects; TC3X runs as the !TRICORE_TC18 fallback in assembly. Co-Authored-By: Parthiban Nallathambi <parthiban@linumiz.com> Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

GCC and HighTec clang are the two toolchains that build the TriCore port today. GCC (tricore-elf-gcc, AURIX GCC) is the open toolchain published by Infineon. HighTec clang is the only LLVM build that currently targets TriCore and consumes a HighTec license at runtime. Wire each with a Kconfig selector and a matching dispatcher under Toolchain.defs and Toolchain.cmake so a board picks its toolchain once at configure time. The earlier Tasking dispatcher is removed in the same commit because the upstream port does not include a configuration that builds under Tasking. Co-Authored-By: Saravanan Sekar <saravanan@linumiz.com> Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

Add TriCore architecture port supporting the TC1.6P core (AURIX TC3X family) and the TC1.8P core (AURIX TC4X family) from Infineon. Includes reset vector, context switching using TriCore upper and lower context save areas (CSA), interrupt management with the BIV vector table, trap and exception handling with the BTV vector table, syscall interface, and linker scripts for both GCC and HighTec clang. The TC3X and TC4X families share the same trap and interrupt model, so the core paths sit under arch/tricore/src/common and serve both families. Watchdog disable diverges between the families (ENDINIT password rotation on TC3X, CCU on TC4X) and lives in small per-family helpers under tc3x/ and tc4x/. Co-Authored-By: Parthiban Nallathambi <parthiban@linumiz.com> Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

A tick source is required to drive the scheduler and any sleep or timeout primitive. The System Timer (STM) is always present on both AURIX families, runs from the SCU clock and has the resolution and range the scheduler expects, so it is the natural tick source for the port. Use the oneshot lower-half binding so the same driver serves tickless and periodic configurations without a second timer. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

The SCU PLL has to be brought up at boot so peripherals run at their intended rate. UART baud, STM tick interval and every other timed peripheral derive from the SCU clock tree, so the port configures the PLL before any driver starts. The TC3X SCU registers that select the PLL source and dividers are write-protected by the SCU watchdog ENDINIT bit, which is itself guarded by a per-watchdog password. Without rotating the password and clearing ENDINIT, the clock writes are silently dropped and the PLL never reaches the requested frequency. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

The SCU PLL has to be brought up at boot so peripherals run at their intended rate. TC4X configures the PLL and clock tree through the Clock Control Unit (CCU). Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

Peripherals need their input and output pads muxed to the right alternate function before they can move signals. Add GPIO pinmux helpers for both AURIX families so peripheral drivers added later in the series can call aurix_config_gpio() at init time and then talk to the line. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

Generic UART interface driver for the ASCLIN serial peripheral on the AURIX family. A single driver serves both TC3X and TC4X. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

TC375 Lite Kit board support for the AURIX TC3X family. Only UART is supported; NSH defconfigs provided for both GCC and HighTec clang toolchains. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

TC4D7 Lite Kit board support for the AURIX TC4X family. Only UART is supported; NSH defconfigs provided for both GCC and HighTec clang toolchains. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

Cover the feature matrix per AURIX family, architecture notes (CSA context switching, interrupt and trap dispatch), toolchain options (GCC and HighTec LLVM), source layout under arch/tricore/src, and the supported drivers (ASCLIN UART, GPIO, STM). Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

xiaoxiang781216 · 2026-06-04T17:55:26Z

@@ -1,139 +0,0 @@
-# ##############################################################################
-# arch/tricore/src/cmake/ToolchainTasking.cmake


why drop Tasking toolchain support

We do not have Tasking toolchain access, we will update PR with Tasking.

xiaoxiang781216 · 2026-06-04T18:04:02Z

-#define EXTERN extern
-#endif
-
-int setjmp(jmp_buf env);


why remove setjmp/longjmp implementation

implementation is still part of libs/libc/machine/tricore/arch_setjmp.c, header file removed accidentally.

for the code which modify the original code, it's better to keep the new implementation and removed one in the same patch (one patch modify one standalone function), so the reviewer can compare the implementation side by side to ensure the new implementation doesn't lose the functionality or introduce the break change.

xiaoxiang781216 · 2026-06-04T18:04:58Z

@@ -0,0 +1,147 @@
+/****************************************************************************
+ * arch/tricore/src/common/tricore-llvm.ld


why add board/chip specific ld in arch common code

current NuttX follows the ld file in board directory which is more of duplicated, idea is to keep common ld file specific to SoC and difference/fragments shall be kept in board. IMHO moving ld to aurix is valid, suggest.

xiaoxiang781216 · 2026-06-04T18:05:15Z

@@ -1,524 +0,0 @@
-/****************************************************************************
- * arch/tricore/src/common/tricore_cache.c


why remove the cache code

removed as iLLD reference. Current PR holds without cache support, will be added in follow-up PR.

see the similar reply here: #19041 (comment).

xiaoxiang781216 · 2026-06-04T18:06:01Z

@@ -1,412 +0,0 @@
-/****************************************************************************
- * arch/tricore/src/common/tricore_hwdebug.c


why remove hwdebug code

ditto, removed as iLLD reference.

xiaoxiang781216 · 2026-06-04T18:06:17Z

@@ -1,1244 +0,0 @@
-/****************************************************************************
- * arch/tricore/src/common/tricore_mpu.c


why remove mpu code

ditto, removed as iLLD reference.

xiaoxiang781216 · 2026-06-04T18:13:16Z

@parthitce your pr removes many functionality (cache, mpu, hwdebug, perf, setjmp/longjmp, tasking compiler), please organize your patch that any change to the origin code need split to the small but self-contained patch and describe the reason you make this change clearly.

linguini1

This is great news! But same comments as Xiang; could you please split this change into multiple PRs?

Also for your test section, please link directly to the test logs :)

zyfeier · 2026-06-05T01:50:34Z

 ############################################################################

-ifeq ($(CONFIG_TRICORE_TOOLCHAIN_TASKING),y)
-  include $(TOPDIR)/arch/tricore/src/common/ToolchainTasking.defs


Why was the TASKING toolchain removed?

We do not have Tasking toolchain access, we will update PR with Tasking.

parthitce · 2026-06-05T08:35:49Z

@parthitce your pr removes many functionality (cache, mpu, hwdebug, perf, setjmp/longjmp, tasking compiler),

@xiaoxiang781216 Thanks for the quick review.

Tasking: Regarding the tasking support, we should be enable them back. This was mainly because of missing licensed access to it.
setjmp/longjmp: IMO we should be revert and use the existing libs/libc/machine/tricore/arch_setjmp.c , probably .S
cache, mpu, hwdebug, perf: All of the existing implementation are dependent on iLLD. The main aim of this PR is to prepare working version of the TriCore Aurix without any dependency. So the followup series will add as independent implementation. Clubbing all in the first level PR will increase the size.

please organize your patch that any change to the origin code need split to the small but self-contained patch and describe the reason you make this change clearly.

Currently commits are logically grouped. Let us know if this needs spliting.

parthitce · 2026-06-05T08:38:36Z

This is great news! But same comments as Xiang; could you please split this change into multiple PRs?

@linguini1 This is the base architecture changes and the commits are logically grouped. Splitting into multiple PR's isn't possible as the current scope is to have a working TriCore + SoC + Board.

Also for your test section, please link directly to the test logs :)

otest and other basic test coverages are done. Which specific logs needs to be attached? Console or general test reports?

xiaoxiang781216 · 2026-06-05T09:00:18Z

@parthitce your pr removes many functionality (cache, mpu, hwdebug, perf, setjmp/longjmp, tasking compiler),

@xiaoxiang781216 Thanks for the quick review.

Tasking: Regarding the tasking support, we should be enable them back. This was mainly because of missing licensed access to it. setjmp/longjmp: IMO we should be revert and use the existing libs/libc/machine/tricore/arch_setjmp.c , probably .S cache, mpu, hwdebug, perf: All of the existing implementation are dependent on iLLD. The main aim of this PR is to prepare working version of the TriCore Aurix without any dependency. So the followup series will add as independent implementation. Clubbing all in the first level PR will increase the size.

please organize your patch that any change to the origin code need split to the small but self-contained patch and describe the reason you make this change clearly.

Currently commits are logically grouped. Let us know if this needs spliting.

Yes, you need split the big patch which modify the current code base into small one like this:

one patch just rename tc397 to tc3x, tc4da to tc4x:
one path just move setjmp/longjmp from arch/tricore to libc/machine/tricore
one patch replace iLLD based MPU implementation by the register based one
...

and ensure the build and boot still work after applying each patch.
For the pure new code, it's fine to do the change in a big patch if you want.

linguini1 · 2026-06-05T13:47:59Z

@linguini1 This is the base architecture changes and the commits are logically grouped. Splitting into multiple PR's isn't possible as the current scope is to have a working TriCore + SoC + Board.

Each commit must pass the CI builds and not break anything as an atomic unit. So in theory if your commits follow that, each one could be a separate PR, which is much easier to review :)

otest and other basic test coverages are done. Which specific logs needs to be attached? Console or general test reports?

Those logs are fine! I just wasn't able to find them quickly via your link. It's best if you attach them as files to the PR and/or copy paste them as text. Probably the former is best.

parthitce and others added 12 commits June 4, 2026 21:57

arch/tc4x: clock support

dd78527

The SCU PLL has to be brought up at boot so peripherals run at their intended rate. TC4X configures the PLL and clock tree through the Clock Control Unit (CCU). Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

arch/aurix: ASCLIN UART driver

a3ae643

Generic UART interface driver for the ASCLIN serial peripheral on the AURIX family. A single driver serves both TC3X and TC4X. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

boards/tc3x: AURIX Lite Kit (TC375)

ce795cd

TC375 Lite Kit board support for the AURIX TC3X family. Only UART is supported; NSH defconfigs provided for both GCC and HighTec clang toolchains. Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>

boards/tc4x: AURIX Lite Kit (TC4D7)

24ab6f2

TC4D7 Lite Kit board support for the AURIX TC4X family. Only UART is supported; NSH defconfigs provided for both GCC and HighTec clang toolchains. Signed-off-by: Saravanan Sekar <saravanan@linumiz.com>

parthitce requested review from acassis, anchao, jerpelea, raiden00pl and wangchdo as code owners June 4, 2026 16:37

xiaoxiang781216 reviewed Jun 4, 2026

View reviewed changes

xiaoxiang781216 requested changes Jun 4, 2026

View reviewed changes

github-actions Bot added Area: Build system Arch: tricore Issues related to the TriCore architecture from Infineon Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces. Board: tricore labels Jun 4, 2026

linguini1 requested changes Jun 4, 2026

View reviewed changes

zyfeier reviewed Jun 5, 2026

View reviewed changes

		@@ -1,139 +0,0 @@
		# ##############################################################################
		# arch/tricore/src/cmake/ToolchainTasking.cmake

		@@ -0,0 +1,147 @@
		/****************************************************************************
		* arch/tricore/src/common/tricore-llvm.ld

		@@ -1,524 +0,0 @@
		/****************************************************************************
		* arch/tricore/src/common/tricore_cache.c

		@@ -1,412 +0,0 @@
		/****************************************************************************
		* arch/tricore/src/common/tricore_hwdebug.c

		@@ -1,1244 +0,0 @@
		/****************************************************************************
		* arch/tricore/src/common/tricore_mpu.c

Conversation

parthitce commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Impact

Testing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ssekar15 Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xiaoxiang781216 commented Jun 4, 2026

Uh oh!

linguini1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

parthitce commented Jun 5, 2026

Uh oh!

parthitce commented Jun 5, 2026

Uh oh!

xiaoxiang781216 commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linguini1 commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

parthitce commented Jun 4, 2026 •

edited

Loading

ssekar15 Jun 5, 2026 •

edited

Loading

xiaoxiang781216 commented Jun 5, 2026 •

edited

Loading