Processors forum - Recent Threads

TDA4VH-Q1: TDA4VH-Q1: LPDDR4 configuration inquiries for LT->HT temperature cycle test (ZQ, MR18/MR19, SREF)

HSUAN CHEN CHIU — Fri, 25 Sep 2026 15:59:06 GMT

Part Number: TDA4VH-Q1

Hi Experts,

We are planning to perform an LPDDR4 low temp to high temp cycle test on the TDA4VH-Q1 platform. To isolate variables and observe signal behavior during the continuous temperature transition, we would like to test specific configurations.

Could you please share whether the TDA4VH-Q1 SDK or SysConfig supports the following configurations and how to apply them?

Boot-up ZQ Calibration: We understand that the initial ZQ calibration during boot-up follows JEDEC specifications. However, for our specific test case, is there a switch or register setting to bypass or disable this boot-up ZQ calibration?
Periodic DQS2DQ compensation(MR18/MR19): Is there a switch to Enable/Disable this periodic compensation during normal operation? If it can be enabled, how do we configure its interval (tDQS2DQ period)?
Self-Refresh (SREF): To isolate variables related to power state transitions during the test, we would like to control the SREF behavior. Is there a configuration switch (Enable/Disable) in SysConfig to toggle Self-Refresh?

Best Regards!

HSUAN CHEN CHIU

English 简体中文繁體中文 Deutsch 日本語 한국어 Español

USD

RE: TDA4VH-Q1: TDA4VH-Q1: LPDDR4 configuration inquiries for LT->HT temperature cycle test (ZQ, MR18/MR19, SREF)

HSUAN CHEN CHIU — Sat, 07 Nov 2026 03:04:53 GMT

Hi Kevin,

Just following up on my previous message. We've learned that the TI Developer Zone might be under maintenance, which could be why the DDR Margin Analysis Tool link is returning a 404 error.

Could you kindly let us know the estimated completion time for this maintenance? We are eager to proceed with setting up the tool environment.

Thank you for your time and assistance.

Best Regards, Alvin Chiu.

RE: AM2752-Q1: Access to C7x DSP manuals concerning Instruction Set, Matrix Multiply Accelerator and Corepac technical reference

Kallikuppa Sreenivasa — Sat, 07 Nov 2026 02:45:21 GMT

Hello Davide De Caro.

Thank you for checking. I have not heard from. Let me check internally and comeback by mid of the week.

Regards,

Sreenivasa

AM2752-Q1: Access to C7x DSP manuals concerning Instruction Set, Matrix Multiply Accelerator and Corepac technical reference

Davide De Caro — Thu, 08 Oct 2026 06:45:24 GMT

Part Number: AM2752-Q1

Dear Sirs,

I'm a professor at the University of Napoli Federico II, Italy. With my research team we would like to develop a research project aimed to verify the performances of optimized audio processing algorithms on C7x DSP in comparison to previous TI DSPs (e.g. C674x or C66x). The reference SoC is TI AM275x.

I would like to ask whether it is possible to have access to the following documents and, in the case, which is the procedure to follow:

SPRUIU4 - C7x Instruction Guide
SPRUIP0 - C71x DSP CPU, Instruction Set, and Matrix Multiply Accelerator Technical Reference Manual
SPRUIQ3 - C71x DSP Corepac Technical Reference Manual

I hope for a positive response to my request.

Best regards,

Davide De Caro.

AM67A: Can VPAC VISS access the DMABUF allocated in the lower 4GB region?

Danxuan Zhu — Fri, 06 Nov 2026 13:22:00 GMT

Part Number: AM67A

Hi,

We are using the AM67-SOC with 4GB-RAM (instead of the j722s-EVM with 8GB-RAM) and mapped the "vision_apps_shared-memories" region in the lower 4GB region (0x08a0000000-0x80FFFFFFFF), instead of in the upper 4GB region (starting from 0x0900000000) on the j722s-EVM. We are wondering if VPAC VISS is permitted to access the DMABUF allocated in the lower 4GB region?

Thanks in advance!

Best regards

Danxuan

RE: AM67A: Can VPAC VISS access the DMABUF allocated in the lower 4GB region?

Anastas Yordanov — Fri, 06 Nov 2026 23:58:27 GMT

Hello Danxuan Zhu,

Thank you for your query !

As I analyze your inputs of the AM67A DDR address range:

[quote userid="610039" url="~/support/processors-group/processors/f/processors-forum/1696001/am67a-can-vpac-viss-access-the-dmabuf-allocated-in-the-lower-4gb-region"]We are using the AM67-SOC with 4GB-RAM (instead of the j722s-EVM with 8GB-RAM) and mapped the "vision_apps_shared-memories" region in the lower 4GB region (0x08a0000000-0x80FFFFFFFF), instead of in the upper 4GB region (starting from 0x0900000000) on the j722s-EVM.[/quote]

I am not sure to understand which is the exact area you are referring to as the target lower 4GB region. If we refer to the AM67A MAIN Memory Map in the TRM:

The mentioned lower 4GB physical region address sub-range within the 0x8_a000_0000-0x80_FFFF_FFFF, as per my understanding starts at 0x8_a000_0000 and spans over the next DDR32SS0 area to the 0x9_9FFF_0000. So the mentioned start address 0x9_0000_0000 of the upper 4GB region means the upper region overlaps with the lower target region.

Also the 0x10_0000_0000 _ 0x80_FFFF_FFFF is outside the J722S/ AM67/AM67A/TDA4VEN/TDA4AEN physically addressable memory map, therefore non-existent.

I am also referring the following AM67A "vision_apps_shared-memories" region related thread which may be helpful for you:

AM67A: Vision_Apps on Custom AM67A board with 4GB DDR - Processors forum - Processors - TI E2E support forums

Please clarify the physical address ranges.

Looking forward to your feedback !

Best Regards,

Anastas Yordanov

RE: AM625: AM62x: MCU_MCAN firewall support and configuration

Hong Guan64 — Fri, 06 Nov 2026 23:12:17 GMT

Hi Dixit,
Let me look into your inquiry, and get back to you next week.
Best,
-Hong

AM625: AM62x: MCU_MCAN firewall support and configuration

Dixit Shah — Wed, 04 Nov 2026 10:30:18 GMT

Part Number: AM625

Hi TI technical support team,

We’re working on firewall protection for MCU_MCAN0 and MCU_MCAN1 on AM62x using PSDK (11.01.05.03) based SDK and System Firmware Firewall Extension (OID 1.3.6.1.4.1.294.1.37).

We couldn’t find MCU_MCAN entries in Section 3.8.3.1 of TRM. However, AM62x MCU+SDK’s csl_soc_firewalls.h defines both MCU_MCAN firewall ID and address range under CSL_STD_FW_MCU_MCAN0_ and CSL_STD_FW_MCU_MCAN1_ prefix.

For example, it lists firewall ID 65 and the address range for MCU_MCAN0_CFG:

#define CSL_STD_FW_MCU_MCAN0_MCAN_WRAP_MCAN_CFG_VBP_MCAN_REGS_ID                (65U)
#define CSL_STD_FW_MCU_MCAN0_MCAN_WRAP_MCAN_CFG_VBP_MCAN_REGS_CFG_START  (0x00000004e08000U)
#define CSL_STD_FW_MCU_MCAN0_MCAN_WRAP_MCAN_CFG_VBP_MCAN_REGS_CFG_END     (0x00000004e081ffU)

We also found TI processor forum AM625 GPIO firewall example which confirms that some FWL IDs were missed from region based firewalls table. This raised a question for us: are MCU_MCAN entries missing from the TRM, or is firewall protection for these peripherals unsupported?

Since SDK defines MCU_MCAN firewall entries that we couldn’t find in TRM, we’re trying to understand whether the TRM entry is missing and how to configure these firewalls.

Could you please clarify:

1. Is MCU_MCAN firewall protection supported on AM62x? If so, are the MCU_MCAN entries missing from the TRM?
2. Is firewall ID 65 and the following region mapping correct?

   firewall-65-0: MCU_MCAN0_ECC_AGGR     (0x04701000 - 0x047013ff)
   firewall-65-1: MCU_MCAN0_MSGMEM_RAM   (0x04e00000 - 0x04e07fff)
   firewall-65-2: MCU_MCAN0_CFG          (0x04e08000 - 0x04e081ff)
   firewall-65-3: MCU_MCAN0_SS           (0x04e09000 - 0x04e090ff)
   firewall-65-4: MCU_MCAN1_ECC_AGGR     (0x04702000 - 0x047023ff)
   firewall-65-5: MCU_MCAN1_MSGMEM_RAM   (0x04e10000 - 0x04e17fff)
   firewall-65-6: MCU_MCAN1_CFG          (0x04e18000 - 0x04e181ff)
   firewall-65-7: MCU_MCAN1_SS           (0x04e19000 - 0x04e190ff)

3. Where should we place the firewall DTS nodes in binman: under &binman > ti-spl > fit > images > tee > ti-secure or &binman > ti-spl > fit > images > aft > ti-secure?

&binman {
    firewall_m4f_mcan0_cfg: firewall-m4f-mcan0-cfg {
        control = <(FWCTRL_EN | FWCTRL_LOCK | FWCTRL_CACHE)>;
        permissions = <((FWPRIVID_M4F << FWPRIVID_SHIFT) |
                        FWPERM_NON_SECURE_PRIV_RWCD)>;

        start_address = <0x00 0x04e08000>;
        end_address = <0x00 0x04e081ff>;
    };

    ti-spl {
        fit {
            images {
                tee {        /* <--- Where should we place the firewall DTS nodes in binman: TEE or ATF? */
                    ti-secure {
                        firewall-65-2 {
                            insert-template = <&firewall_m4f_mcan0_cfg>;
                            id = <65>;
                            region = <2>;
...

4. Could you share a configuration example for MCU_MCAN to allow access from the M4F core only?

Thanks for your help.

AM62L-EVSE-DEV-EVM: AM62-LP SK: ISSI Nand detection issue (PROC143E2)

Selvan Krishnan — Fri, 30 Oct 2026 06:29:38 GMT

Part Number: AM62L-EVSE-DEV-EVM

Hello team,

Initially, we faced difficulties establishing communication with the NAND device in PROC143E2 daughtercard . With the support of Vinu (TI), we were able to establish communication and successfully detect the Micron NAND device. However, we are still unable to detect the ISSI NAND device.

Previous discussion thread::

AM62L: SK-AM62-LP: Parallel NAND (PROC143E2) not detected (nand: No NAND device found) - Processors forum - Processors - TI E2E support forums

Micron NAND:[MT29F8G08ADAFAH4-AAT ]
[ 13.971951] nand: Enter into nand_detect
[ 13.976960] nand: nand_reset success
[ 13.980656] nand: Success Case : Manufacturer ID: 0x2c, DEvice ID: 0xd3
[ 13.987705] Could not find a valid ONFI parameter page, trying bit-wise majority to recover it
[ 13.996556] ONFI parameter recovery failed, aborting
[ 14.001676] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xd3
[ 14.008873] nand: Micron NAND 1GiB 3,3V 8-bit
[ 14.013448] nand: 1024 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 128
[ 14.021423] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
[ 14.043591] 7 fixed-partitions partitions found on MTD device omap2-nand.0

We have two additional daughter cards featuring ISSI NAND (IS35ML08G088-BLA2), but we are encountering different errors with them.

Card1:
[ 14.128534] nand: Enter into nand_detect
[ 14.132995] nand: nand_reset success
[ 14.136797] nand: Success Case : Manufacturer ID: 0x9d, DEvice ID: 0x23
[ 14.143558] nand: second ID read did not match 9d,23 against bf,bf
[ 14.149882] nand: No NAND device found
Card2:
[ 13.907573] nand: Enter into nand_detect
[ 13.914162] nand: nand_reset success
[ 13.918021] nand: Success Case : Manufacturer ID: 0x00, DEvice ID: 0x00
[ 13.924889] nand: No NAND device found

Our observations and investigation:

The Micron NAND device is detected successfully using the same board and GPMC interface.

For ISSI NAND Card 1, the first NAND ID read is successful (0x9D, 0x23), but the subsequent ID read returns a different value (0xBF, 0xBF).

For ISSI NAND Card 2, the NAND ID read returns 0x00, 0x00.

We suspect that the issue could be related to GPMC timing or NAND interface configuration.

We have tried adjusting the GPMC timing parameters, but the issue still persists.

We have also added the ISSI NAND device entry in nand_ids.c.

Could you please clarify the following points?

Are there any known compatibility issues or additional configuration requirements for the ISSI IS35ML08G088-BLA2 NAND device with the AM62LP SK GPMC controller?
Could the different NAND ID read results (0x9D, 0x23, 0xBF, 0xBF, and 0x00, 0x00) indicate a GPMC timing issue? If so, could you recommend the appropriate GPMC timing parameters for this ISSI NAND device?
Are there any specific GPMC configuration requirements, such as read/write access timing, chip-select timing, bus turnaround timing, or wait-state configuration, that we should verify?
Is there any difference in the NAND reset, ID-read sequence, or ONFI detection procedure that needs to be considered for ISSI NAND compared to Micron NAND?
Could you please suggest any additional debugging steps or recommended register configurations to identify whether this is a hardware interface issue or a software configuration issue?

We would appreciate your guidance on identifying the root cause and successfully detecting the ISSI NAND device using the SK-AM62-LP platform and PROC143E2 daughter card.

Thanks for your support.

Best Regards,

Selvan.K

RE: AM62L-EVSE-DEV-EVM: AM62-LP SK: ISSI Nand detection issue (PROC143E2)

Hong Guan64 — Fri, 06 Nov 2026 22:30:59 GMT

Hi Selvan,

1/. SoC under testing? AM62L or AM62x?
2/. EVM/board used? TI reference board or a customer board?
3/. Linux SDK version?
4/. ISSI nand datasheet?

Best,
-Hong

AM6442: TI Clang Compiler V5.1.1.0

Antonio Pannone — Fri, 06 Nov 2026 13:57:04 GMT

Part Number: AM6442

# TI Support Ticket: Extremely Slow Linking Time with tiarmlnk

## Environment

- **TI ARM Clang Version:** 5.1.1.0
- **Linker:** tiarmlnk.exe
- **Host OS:** Windows
- **Target:** AM64x Cortex-R5F (FreeRTOS)
- **Build System:** CMake + Ninja
- **Hardware:** Intel Core i7-14700K (20 Cores, 3400 MHz), 32 GB RAM

## Problem Description

We are experiencing extremely slow linking times with tiarmlnk when building a large embedded project for the AM64x Cortex-R5F target.

**Build Statistics:**
- Compilation of 225 static libraries: ~6 minutes (3600 compile steps, parallelized with Ninja)
- **Final 4 build steps: ~25 minutes** (sequential, single-threaded)
- Final ELF file size: ~250 MB
- Map file size: ~137 MB
- **Linker memory usage (observed in Task Manager): ~4.8 GB at end of linking**

**The final 4 build steps are:**
1. `DeviceManager.map` - Map file generation
2. `DeviceManager_ram.PIC_EVAL` - Intermediate linker output
3. `DeviceManager_ram.PIC_EVAL.elf` - Final ELF file
4. `PIC_EVAL_AM64X_Clang_flashimage.bin` - Flash image (binary)

These final steps take approximately 4x longer than compiling the entire project (225 libraries), which significantly impacts our development workflow. The compilation fully utilizes all 20 CPU cores, while the linker appears to run single-threaded.

## Project Details

- ~225 static libraries (.a files)
- ~226 unique library entries after deduplication
- Debug build with `-g` flag (required for debugging)
- Single monolithic ELF output

## Attempted Optimizations (No Significant Improvement)

1. **Replaced `--reread_libs` with `--start-group`/`--end-group`**
- Expected more efficient circular dependency resolution
- Result: No significant improvement

3. **Added `--compress_dwarf`**
- Result: No improvement

4. **Build without debug symbols (removed `-g` flag)**
- Result: Link time reduced from ~25 min to ~16 min (~36% faster)
- Conclusion: Debug symbols account for ~9 min, but 16 min is still too long

## Linker Command Structure

```
tiarmlnk.exe -I<lib_path> -o <output.elf> \
-mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 \
--diag_suppress=16004 \
--compress_dwarf \
<linker_script.ld> \
--map_file=<output.map> \
<objects_and_libraries.cmd>
```

The command file contains:
- 226 static libraries (.a) wrapped in `--start-group`/`--end-group`
- System libraries (libc.a, libc++.a, libunwind.a, libclang_rt.builtins.a)

## Questions

1. Is there a way to enable **parallel/multi-threaded linking** in tiarmlnk?

2. Are there any **linker flags** that could significantly reduce linking time for large projects with debug symbols?

3. Is the **map file generation** a significant contributor to the linking time? Can it be optimized?

4. Would using the **ARM GNU linker (arm-none-eabi-ld)** with TI Clang compiled object files be a supported/recommended alternative?

5. Are there any **known performance improvements** in newer versions of TI ARM Clang that address large project linking times?

## Expected Behavior

We would expect linking times to be proportional to the project size, ideally in the range of 2-5 minutes for a project of this size, similar to what we observe with other toolchains (e.g., GCC).

## Additional Information

We are happy to provide:
- Sample linker command file
- Map file excerpt
- Build logs
- Any other diagnostic information requested

Thank you for your support.

RE: AM6442: TI Clang Compiler V5.1.1.0

James Nagurne — Fri, 06 Nov 2026 22:13:08 GMT

Hi Antonio,

We're not currently tracking any link-time degradation at this time.

I understand that your project is prohibitively large. However, we will be unable to assist effectively without something to work with.

Let me know if you can submit a linker test case using the direction at this link.

1. Our linker is not currently capable of parallel execution.

2. I'll get back to you on this as soon as I research possibilities, but I do not believe so.

3. Map file generation is generally IO bound, and Windows is known to be quite slow in this regard, especially on machines that utilize real-time security scans. I'm actually concerned that the mapfile is so large. An excerpt might help, but the full mapfile would be much more desirable if possible.

4. This is not supported, so do so at your own risk

5. There is a fixed defect in the next major release which impacts builds that utilize link-time optimization (-flto). Is this something that you're using?

AM3358: Kernel v6.12 and later the new GPIO framework, working side-by-side with the legacy sysfs one - export GPIO and toggle it, devicetree, kernel driver, debugfs

Kaloyan Dimitrov — Thu, 29 Oct 2026 16:54:15 GMT

Part Number: AM3358

Hi guys,

I am working on a project to update support for a AM3358 Soc based board from a really old kernel 4.9 to a new 6.12 and later - target is v6.18.

The current issue that I am looking into is supporting the GPIO pinmuxing proper declaration in the devicetree building a kernel with legacy support enabled side-by-side with the new GPIO framwork booting into a rootfs and then exporting the porper pin/s and successfully controlling them using the /sys/class/gpio/export sysfs interface the legacy approach - export a pin declared in the devicetree and toggling.

What am I doing:

1) I build a kernel with the SYSFS legacy enabled:

CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_SYSFS_LEGACY=y

2) Devicetree entry for just a single pin to be toggled later:

&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&clkout2_pin>;

board_pins: board_pins {
pinctrl-single,pins = <

AM33XX_IOPAD(0x848, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (U14) gpmc_a2.gpio1[18] */

>;
};

};

3) I boot into a BusyBox rootfs and try exporting the GPIO pin and toggling it like that:

echo 562 > /sys/class/gpio/export && echo out > /sys/class/gpio/gpio562/direction && echo 1 > /sys/class/gpio/gpio562/value

But the level doesn't change !

I am aware of the fact that the legacy system is deprecated and general advice is abandon the old way of doing things - which is fair enough but I have a good reason for sticking with the sysfs way. That being said my quiestion is first and foremost - is what I am trying to do acheavable, and by that I mean runnig the two GPIO framworks in tandem and exporting and controlling pins using the sysfs ?

Are there any gotchans or pitfals that I am not awere in gereral or anything in particular specific for the AM335x that I have to follow ?

Am I doing something wrong, missing something ?

Any directions on how to properly test and fix my setup will be appreciated !

Thanks,

Kal

RE: AM3358: Kernel v6.12 and later the new GPIO framework, working side-by-side with the legacy sysfs one - export GPIO and toggle it, devicetree, kernel driver, debugfs

Rohit Singh — Fri, 06 Nov 2026 21:43:40 GMT

Hi Kal,

Shriya is out of office, returning November 20th. Please expect a delayed response, thank you for your patience.

AM6442: XDP Zero Copy for CPSW

Artur Toews — Tue, 28 Apr 2026 12:03:58 GMT

Part Number: AM6442

Hallo,

I have noticed, hat you recently implemented XDP ZC for the am65-cpsw-nuss driver.
FROMLIST: net: ethernet: ti: am65-cpsw: Fix clearing of irq_disabled … · TexasInstruments/ti-linux-kernel@5baabe2

I also read the 3.6.3.5. PRU_ICSSG XDP — Processor SDK AM64X Documentation and found some Requirements.

For zero-copy to function properly with PRU_ICSSG, ensure:

Driver Support: Verify the PRU_ICSSG driver is loaded with zero-copy support enabled

Memory Alignment: Buffer addresses must be properly aligned to page boundaries

UMEM Configuration: The UMEM area must be correctly configured: - Properly aligned memory allocation - Sufficient number of packet buffers - Appropriate buffer sizes

Hugepages: Using hugepages for UMEM allocation is recommended for optimal performance

I assume the requirements are the same when using the CPSW with XDP zero copy.

What exactly do we have to consinder in our yocto project to get XDP ZC working?

My current project include "meta-ti:11.02.13", but unfortunately my device crashes as soon as I try to load my bpfprog.o with libxdp. After the crash I cannot do anything, even my serial console is frozen.

Can you imagin what is going wrong?

BR
Artur

RE: AM6442: XDP Zero Copy for CPSW

Daolin Qiu — Fri, 06 Nov 2026 21:41:38 GMT

Hi Artur,

No problem thanks for the feedback. We've tried for the past few days to get the pn slave working but at this point I think it would be better if you can send us a Profinet slave (if possible) for this debug.

Jan may be setting up a 3-way meeting with you, CODESYS, and I next week to align on the specific issue here as I'm still not sure if the issue CODESYS recreated with EtherCAT is the same as the issue you are currently facing related to "DHT expire"

Thanks,

Daolin

AM67A: M67A (HS-FS) custom board, USB DFU boot: ATF/OP-TEE get no TI-SCI responses after R5 SPL hand-off — DM firmware appears not to run

Carson Bay — Fri, 06 Nov 2026 21:33:13 GMT

Part Number: AM67A

We are bringing up a custom board with the AM67A74AKGHIAMWR (HS-FS, SoC ID block reports `j7aen` / `HSFS`), 1 GiB LPDDR4

(2 ch x16, single rank), SPI-NAND boot (W25N04KV) with USB DFU as the backup boot mode (BOOTMODE / DEVSTAT = 0x0483).

The NAND is blank, so the ROM falls back to USB DFU, and we boot over DFU: tiboot3.bin -> R5 SPL (USB DFU) -> tispl.bin.

Software: ti-u-boot 11.00.10 (tag 70667128cb5b), ti-linux-firmware 11.00.10 (TIFS 11.0.9, DM

`ipc_echo_testb_mcu1_0_release_strip.xer5f` v11.00.09), TF-A 2.12.0 (11.00.09), OP-TEE 4.5.0. Board config YAMLs

(board-cfg / pm-cfg / rm-cfg / sec-cfg / tifs-rm-cfg) are the unmodified j722s ones.

**What works**

- ROM DFU; R5 SPL (our board target) runs: banner, `SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.9--v11.00.09+ (Fancy Rat)')`,

DDR init, USB DFU gadget for tispl.bin.

- tispl.bin over DFU: "Authentication passed" x5, "Starting ATF on ARM64 core...", BL31 starts.

- DDR configuration generated with TI's DDR Config tool (TDA4x/DRA8x/AM67x-AM69x DDR Config 0.12.00, SysConfig 1.28.1) for

our part: J722S defaults at 3733 MT/s with density 4 Gbit/channel, 1 rank, x32, JEDEC refresh timings for 4 Gbit/channel.

- DDR checked from the R5 SPL over DFU RAM slots: 112 MiB across the 1 GiB (32 MiB at 0x90000000, the DM's 16 MiB at

0xa0000000, 32 MiB at 0xb0000000, 32 MiB up to 0xc0000000), random data and its bit-inverse, all read back identical, no

aliasing. The failure below is the same with this configuration and with a BeagleY-AI-derived one.

**What fails** (UART0):

```

NOTICE: BL31: v2.12.0(release):11.00.09-dirty

ERROR: Timeout waiting for thread SP_RESPONSE to fill

ERROR: Thread SP_RESPONSE verification failed (-60)

ERROR: Failed to get response (-60)

ERROR: Transfer send failed (-60)

ERROR: Unable to query firmware capabilities (-60)

E/TC:0 0 ti_sci_init:480 Unable to communicate with control firmware (-65523)

E/TC:0 0 sa2ul_init:106 Could not change TRNG firewall owner

E/TC:0 0 tee_otp_get_hw_unique_key:104 Could not get HUK

E/TC:0 0 Core data-abort at address 0x14 (translation fault)

E/TC:0 0 Panic 'unhandled pageable abort'

```

On another run (same images) BL31 printed no error and the A53 SPL stopped right after its `SYSFW ABI` line.

Nothing appears on WKUP_UART0 (where we expected the DM's "Sciserver ..." banner).

**Compared / ruled out**

- The same TIFS/DM/ATF/OP-TEE binaries boot to Linux on a BeagleY-AI (AM67A) from SD.

- R5 SPL Kconfig for K3/DM (K3_DM_FW, SPL_REMOTEPROC, ...) identical to j722s_evm_r5_defconfig; R5 DT TI-SCI nodes

(dm-tifs, sysctrler, mailboxes) identical to k3-j722s-r5-evm; our board does not enable LFXOSC (no 32 kHz crystal) — the

BeagleY-AI has LFXOSC disabled as well.

- The ROM's USB DFU path rejects a tiboot3 with a ~407 KB payload (accepts ~374 KB and below): we use an R5 SPL without

SPI-NAND/FIT-signature for DFU. Is there a documented maximum tiboot3 size for J722S ROM boot (DFU and xSPI-NAND)?

**Questions**

1. Is USB DFU boot of the full chain (R5 SPL -> DM firmware on the WKUP R5) supported on J722S / AM67A HS-FS with SDK 11.0,

and is anything required in the R5 SPL for the DM to start in that boot mode?

2. What would make the DM not service TI-SCI (no banner on WKUP_UART0) after `jump_to_image_no_args()` jumps to its entry?

3. For JTAG: what is the J722S power-AP / debug power-up sequence needed before the APB-AP (AP 1) is accessible (OpenOCD;

TAP 0x0bba002f)?

Logs and configs available on request. Thank you!

AM6422: Stability and Long-Term Availability of AM64x Peripheral Revision Identifiers

Jun Tu — Thu, 05 Nov 2026 16:38:48 GMT

Part Number: AM6422

As part of our avionics software verification and configuration-management process, we need to establish the stability and long-term availability of the hardware revision identifiers used by our firmware.

Our current implementation performs peripheral revision checks, for example:

"if (bIsModuleRevAtLeast(pCfg, 2U, 2U, 0U) == (bool)true)" at line753 of csl_udmap.c at sdk version 12_01_00_13.

The firmware reads revision or identification registers from several AM64x peripherals, including BCDMA, PKTDMA, INTAGGR, Ring Accelerator, Secure Proxy, GPMC, CBASS, ESM, and other modules.

for instance:

BCDMA BCDMA_GCFG_REVISION 0x485C0100 32
PKTDMA PKTDMA_GCFG_REVISION 0x485C0000 32
INTAGGR INTAGGR_CFG_REVISION 0x48110000 64
Ring Accelerator RINGACC_GCFG_REVISION 0x48240000 32
Secure Proxy SEC_PROXY_PID 0x48250000 32
OSPI OSPI_CFG_PID 0x0FC44000 32
GPMC GPMC_REVISION 0x3B000000 32
CBASS0 CBASS_ERR_PID 0x3A000000 32
MCU CBASS CBASS_ERR_PID 0x45B02000 32
ESM MAIN ESM_PID 0x00420000 32
ESM MCU ESM_PID 0x04100000 32
GTC GTC_CFG0_PID 0x00A80000 32
CPTS CPTS_IDVER_REG 0x39000000 32
Main security MMR MAIN_SEC_MMR_CFG0_PID 0x45A00000 32

Our current processor part number is AM6422BSDFHAALVR.

We would like clarification on the following two questions:

1. Stability of peripheral revision identifiers

If we continue using the exact same processor part number, AM6422BSDFHAALVR, can we expect the revision and identification register values for these peripherals to remain unchanged throughout the product's manufacturing lifetime?

In particular:

Can the peripheral revision values change between production lots while the full processor part number remains unchanged?

Could TI introduce an internal silicon revision, die revision, or peripheral IP revision without changing the orderable part number?

Are these register values guaranteed by TI to remain constant for this exact part number, or should our firmware account for possible variations?

2. Long-term product availability and component substitution

For an avionics product with a long service life, we must consider future procurement and hardware continuity.

If AM6422BSDFHAALVR becomes unavailable due to supply constraints, product discontinuation, or other lifecycle changes, what alternatives would TI provide?

For example, if we need to procure an additional 10,000 units ten years from now:

Can TI guarantee long-term availability of this exact part number?

If the exact part number is no longer available, could TI offer a replacement or equivalent device?

If a replacement device is supplied, could its peripheral revision and identification register values differ, even if the device is functionally equivalent?

Avionics software impact

These questions are important because our firmware uses peripheral revision checks to determine whether certain hardware features or configurations are supported. An unexpected change in a revision identifier, or a replacement device with different revision values, could affect software behavior and require additional verification and certification activities.

We would therefore appreciate TI's clarification on the applicable silicon revision policy, the stability of these register values, and the long-term product lifecycle and substitution policy for AM6422BSDFHAALVR.

RE: AM6422: Stability and Long-Term Availability of AM64x Peripheral Revision Identifiers

Kathryn Kalouf — Fri, 06 Nov 2026 21:05:33 GMT

Hi Jun,

Thanks for your questions. Please see below answers:

1. The peripheral values would remain unchanged between production lots. If we were to introduce an internal silicon revision, die revision, or peripheral IP revision, that would be subject to an OPN change. If there is a revision change such as this, we would notify our customer base, but we do not foresee this to be the case on the AM64 family

2. We understand that avionics applications have a long life cycle. In fact, many of our industrial applications do, so we make sure to support our products for 10+ years and adhere to the following policy: https://www.ti.com/en-us/quality-reliability/quality/product-life-cycle. We are investing in the AM64's roadmap, so we would definitely have an equivalent device down the line, but this could potentially have a different peripheral revision where we will support with it's own SDK

Best,

Kathryn

TMS570LS3137: TMS570LS3137 Bricked After Software Load

Hugh Shane — Fri, 06 Nov 2026 20:31:20 GMT

Part Number: TMS570LS3137

We have several instances of prototype custom circuit boards that incorporate the TMS570LS3137. We use the XDS110 USB Debug Probe to program the devices and debug our code and have done so successfully for years. However, two units recently failed to program at around the same time during software test and debug sessions. We're not certain that the previously loaded software was the cause of the failures but the coincidence is suspicous.

Upon closer examination the failure symptoms are not quite the same. We've used Code Composer Studio (CCS) and UniFlash (UNI) to troubleshoot. Here are the diagnostics for two units, serial numbers 113 and 108:

S/N 113

(CCS) attempt to program:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0 CortexR4: Trouble Reading Memory Block at 0xf008015c on Page 0 of Length 0x4: (Error -1205 @ 0xF008015C) Device memory bus has an error and may be hung. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.10.0.00080)
CortexR4: Error initializing flash programming: Target failed to read 0xF008015C
CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.
CortexR4: Trouble Reading Memory Block at 0x0 on Page 0 of Length 0x4: (Error -1205 @ 0x0) Device memory bus has an error and may be hung. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.10.0.00080)
CortexR4: File Loader: Verification failed: Target failed to read 0x00000000

(UNI) read target device: block read from 0x0 OK

(UNI) attempt to program:

[WARNING] CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

[ERROR] CortexR4: File Loader: Verification failed: Values at address 0x00000001 do not match Please verify target memory and memory map.

S/N 108

(CCS) attempt to program:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0 CortexR4: Failed CPU Reset: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.10.0.00080)
CortexR4: GEL: Error while executing GEL_Reset(): Reset failed: retcode=-1
at GEL_Reset()
CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.
CortexR4: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
CortexR4: GEL: File: C:\dev\central-computer\flight_app\DEVBOARD\cc-flight-app-software.out: a data verification error occurred, file load failed.

(UNI) read target device: no response, application indicates "loading"

(UNI) attempt to program: "Error! Target is not connected"

As one can see, the failures are similar but not identical. Is there any way this sort of behavior could be caused by a program that we loaded previously? Are there any steps we can take to recover the devices? Any suggestions for further troubleshooting are appreciated.

-- Hugh

TDA4AL-Q1: Support Required for Running C7x/Vision Apps on Custom Yocto SDK

jayadeva sm — Tue, 06 Oct 2026 05:51:16 GMT

Part Number: TDA4AL-Q1

Hi Team,

I am using a customized SDK based on Yocto layers. I am trying to run the C7x/Vision Apps example on our board.

However, in our customized SDK:

The /opt directory is not available.
The Vision Apps package is not present.
I am unable to set up the required environment to build and run the example.

This activity is a high-priority project requirement, and we need urgent support. Could you please guide me on:

How to configure the environment in a customized Yocto SDK.
How to obtain and integrate the required Vision Apps components.
The steps required to build and run the C7x TI example on our platform.

Please let me know if any additional information is required.

Thank you for your support.

Previous Thread Reference:

TDA4AL-Q1: Enable the C7x core for the thermal load TI example - Processors forum - Processors - TI E2E support forums

Regards,
Jayadeva
Technical Leader
Aptiv

RE: TDA4AL-Q1: Support Required for Running C7x/Vision Apps on Custom Yocto SDK

Jared McArthur — Fri, 06 Nov 2026 20:15:19 GMT

Hi jayadeva sm,

I will let you know when the issue is fixed.

Best,
Jared

RE: AM3358: Kernel v6.12 and later the new GPIO framework, working side-by-side with the legacy sysfs one - export GPIO and toggle it, devicetree, kernel driver, debugfs

Kaloyan Dimitrov — Fri, 06 Nov 2026 20:03:17 GMT

Hi Shriya,

Thanks for the pointer and the link. It turned out it was indeed the GPIO numbering issue. Looks like for the new kernels(v.6.12, v.6.18) the HW gpioX port and /sys/class/gpio/gpiochipX nodes have changed old kernels link the one that I am using v.4.9 use one to one direct correspondence gpioX --> gpiochipX and the GPIO offsets are from base 0, as for new kernels it is :

gpio1 --> gpiochip0

gpio2 --> gpiochip1

gpio3 --> gpiochip2

gpio0 --> gpiochip3

And the enumeration for the GPIO pins starts not from zero but from 512 in my particular case, so exporting Pin 50 form v.4.9 kernel which corresponds to is translated to exporting GPIO 530 not 562.

That being said I have two questions:

What is the recommended way( if there is such ) so that one can do an overlay or remapping so that if there is an application running in userspace and it uses an old kernel v.4.9 GPIO pin exports a developer to be able to implement a translation/glue layer in the board Devicetree or somewhere else so that the running application can use the same exported pins with no modifications - if say pins 3, 50, 80, 111 are used by userspace dirver with an old kernel, the same pins to be used transparently in the new kernel v.6.12/v.6.18 ? The same question was explored in this URL: AM3352: Setting GPIO values in kernel 6.1.46 - Processors forum - Processors - TI E2E support forums but I didn't see an actual resolution there.
I am not sure exactly how all that happens( gpioX -> gpiochipX matching in the kernel code and the pin enumeration ) but I am curious to learn more about that.

Looks like the gpio-omap.c is the responsible driver ( correct me if I am wrong ).

I will really appreciate it you can direct me to the best sources to learn more about: the Kernel GPIO Core, Provider Bridge(gpio_chip), the Low-Level Driver that TI provides as part of the BSP, and finally the Device Tree Entries & Subsystem Integration plus the Kernel Device Tree Bindings etc. all in the light of the TI implementation.

Regards,

Kal

RE: AM623: Suspected return-value mismatch in SDK 12.01 GP TIFS resume stub

Anshu Madwesh — Fri, 06 Nov 2026 19:59:10 GMT

Hi Chan,

I'm looking into this and will provide a response early next week.

Best Regards,

Anshu

AM623: Suspected return-value mismatch in SDK 12.01 GP TIFS resume stub

Long Chan — Fri, 06 Nov 2026 08:01:25 GMT

Part Number: AM623

Hi TI team,

Please review a suspected return-value mismatch in the SDK 12.01 GP TIFS resume stub: one routine returns 0, but a downstream check requires 0x5a before the context-segment copy. On SK-AM62 E2, RTC DeepSleep resume failed with a TIFS HardFault while R5/DM waited for SYNC_RESUME. A one-byte diagnostic change allowed the firmware handshake to complete.

FIRMWARE

File: ti-sysfw/ti-fs-stub-firmware-am62x-gp.bin (unmodified SDK 12.01.00.05.03 prebuilt raw binary, 28,672 bytes)
SHA-256: 451f273b81c35b42d64e3ddfa73271dbff9da1d93f0713ec6e69bed5e836c28d

FAILURE STATE

XDS110/OpenOCD inspection of one preserved failed-resume state:

R5/DM waiting for SYNC_RESUME: PC 0x00000ac4
TIFS HardFault handler: PC 0x0006099e; CFSR 0x00000100 (IBUSERR), HFSR 0x40000000 (FORCED)
Exception frame: PC 0x00000000, LR 0x00060f2d
TIFS registers: r1=0x00040004, r2=0x00000000
Handoff evidence: The routine at 0x00061058 loads r2 from [r1] at 0x0006105e, then executes mov pc, r2 at 0x00061060. Together with the captured state, this is consistent with an attempted branch through a zero vector read from 0x00040004.

SUSPECTED MISMATCH

(Addresses refer to the raw stub loaded at 0x00060000. Function roles and causal interpretation are inferred from disassembly; TI source symbols were unavailable.)

The routine at 0x00060e30 appears to configure DDR RAT mapping and returns 0 on its apparent success path at 0x00060e76 (movs r0, #0).
The caller initially accepts 0 or 0x5a, but the check at 0x000609ec requires 0x5a before the context-segment copy.
On this inferred path, returning 0 skips the copy, while subsequent cleanup can still report success, leaving the resume vector unrestored.

Key Question for Firmware Team:
Should the routine at 0x00060e30 return 0x5a on success, or should the check at 0x000609ec also accept 0?

DIAGNOSTIC CHANGE

Raw stub offset 0x0e76, before GP certificate: 00 20 -> 5a 20 (movs r0, #0 -> movs r0, #0x5a).
Exactly one raw-stub byte changed; length and all other bytes are identical. The GP certificate was regenerated and the FIT rebuilt with SDK tooling.
Modified SHA-256: a39ad1d8bfd883783158311d45839f6ab49c4dce991885b90f70dc6ff4e2056e

Observation: DM received SYNC_RESUME; TIFS returned to runtime at PC 0x4a1e4, and R5/DM executed at PC 0x9dcbd5c8. Full Linux return additionally required removing our early TF-A logging, which had caused a separate A53 stop; final tests used unmodified TF-A source. This is a diagnostic workaround, not an official fix.

Validation: Eight RTC DeepSleep/resume cycles completed across three boots (5 + 2 + 1). Each cycle retained its Linux boot ID, restored four CPUs, had taint=0 and unchanged PM failure counters, and reported wake source 0x50, mode 0x0. These were short tests on one board, without JTAG halt during accepted measurements.

ENVIRONMENT

Hardware: SK-AM62 E2, AM62X SR1.0 GP, 2 GB RAM, 16 GB eMMC.
Software: Processor SDK Linux RT 12.01.00.05.03; Buildroot 2026.05; official ti_release_am62x_sk_rt_defconfig baseline; kernel 6.18.38-rtpm2 (PREEMPT_RT, TI tag 12.01.00.05); TF-A da738d5e (K3_PM_SYSTEM_SUSPEND=1).
SYSFW banner: 12.1.2--v12.01.02, ABI 4.0; the raw hash above identifies the individual stub.

I understand TI documents RT LPM as unsupported. SUSPEND, HOTPLUG_CPU, CPU_IDLE and CPU_FREQ were locally re-enabled. Other conditions include one-time GP optee-rng unbind until reboot, an M4 PM-notifier fix with driver unload/reload, OSPI disabled, CPU isolation changes, an inactive printk diagnostic hook, and GP/eMMC/Falcon U-Boot adaptations. Stock non-RT, HS devices, other silicon revisions and other wake sources remain untested.

Trigger within that prepared environment:

echo enabled > /sys/class/rtc/rtc0/device/power/wakeup
echo deep > /sys/power/mem_sleep
rtcwake -u -d /dev/rtc0 -m mem -s 20

REQUESTS

Please route this to the TIFS/GP stub team to verify the return-value contract and advise whether it is already tracked, with a shareable reference if available.
If confirmed, please identify the official firmware fix and intended release or backport.

Technical logs, patches and configurations are available on request.

Thank you,
Chan