ssekar15 opened a new pull request, #21504:
URL: https://github.com/apache/nuttx/pull/21504

   ## Summary
   
   The TriCore interrupt path depends on the Infineon iLLD. The interrupt
   vector comes from the iLLD IFX_INTERRUPT_INTERNAL macro on GCC and from
   the compiler __interrupt/__vector_table keywords on TASKING, and both
   build it for CPU0 only. tricore_irq.c programs the service request
   control (SRC) registers through IfxSrc and IfxCpu, and TRICORE_SRC2IRQ
   takes the SRC base from the iLLD MODULE_SRC.
   
   This series adds the SRC register addresses and bit fields for TC3xx and
   TC4xx, writes the SRC registers directly in tricore_irq.c, and replaces the
   interrupt vector with a native one per core next to the trap vectors, in
   GNU and TASKING assembly. tricore_doirq becomes a plain function entered
   with jli. tricore_irq.c and tricore_doirq.c are now free of the iLLD, and
   IfxSrc.c is no longer built. interrupt nesting (#21308) can build on top of 
it.
   
   ## Dependency
   
   Depends on #21496.
   
   ## Impact
   
   TriCore only (arch/tricore and the TC397/TC4x9 linker scripts).
   - The linker scripts select the native interrupt vector of the configured
     core (.intvec_cpuN); its address is unchanged (INTTAB + 0x1FE0).
   - IfxSrc.c is dropped from the make and cmake builds, and the TC4xx
     SRC_CPU_CPU0_SB/SRC_GPSR00 alias defines are removed.
   - No functional change intended: the SRC register values after boot are
     the same as before.
   
   No Kconfig, board defconfig or documentation changes.
   
   ## Testing
   
   I confirm that changes are verified on local setup and works as intended:
   
   * Build Host(s): Linux x86_64, Debian GNU/Linux 12 (bookworm)
   * Toolchains: AURIX GCC 11.3.1 (tricore-elf-gcc), TASKING VX-toolset v6.4r1
     (TC3x), TASKING SmartCode v10.4r1 (TC4x)
   * Build systems: make, cmake (Ninja)
   * Target(s): a2g-tc397-5v-tft:nsh, triboard_tc4x9_com:nsh
   * Hardware: TriBoard TC397 V2.0; TriBoard TC4x7 COM V3.0 for the
     triboard_tc4x9_com image
   * Each commit passes tools/checkpatch.sh. The GCC warning from the iLLD
     interrupt macro in tricore_doirq.c (-Wstrict-prototypes) is gone.
   
   Build results (tip):
   
   | Board | GCC make | GCC cmake | TASKING make | TASKING cmake |
   |---|---|---|---|---|
   | a2g-tc397-5v-tft:nsh | pass | pass | pass | - |
   | triboard_tc4x9_com:nsh | pass | - | pass | pass |
   
   The interrupt vector is at 0x80001fe0 in all four images.
   
   Runtime, ostest:
   
   | Board | GCC | TASKING |
   |---|---|---|
   | TriBoard TC397 (a2g-tc397-5v-tft:nsh) | pass | pass |
   | TriBoard TC4x7 (triboard_tc4x9_com:nsh) | pass | wqueue assert, also on 
master |
   
   ostest ran with the code of the vector commit (before it was committed,
   hence -dirty); the tip, which only drops IfxSrc.c from the build, was boot
   tested:
   
   ```
   nsh> uname -a
   NuttX 10.4.0 294043dd767-dirty Nov  5 2026 22:09:37 tricore a2g-tc397-5v-tft
   nsh> ostest
   ...
   user_main: Exiting
   ostest_main: Exiting with status 0
   
   nsh> uname -a
   NuttX 10.4.0 843fff5ed24 Nov  5 2026 22:26:25 tricore a2g-tc397-5v-tft
   ```
   
   SRC registers read back from the boards after boot, before and after
   this series (ASCLIN0 RX, STM, GPSR0 to GPSR5/6 SR0):
   
   ```
   TC397        before     after
   0xf0038054:  00110408   00110408
   0xf0038300:  000e0407   000e0407
   0xf0038990:  001b0001   001b0001
   ...
   0xf0038a30:  00050006   00050006
   
   TC4x7        before     after
   0xf44322b4:  00800009   00800009
   0xf4433460:  00000001   00000001
   ...
   0xf4433520:  00000007   00000007
   ```
   
   All values match, except that the STM SRC on TC4x7 showed a pending
   request (SRR) at the moment it was read, which is timing, not setup.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to