https://e2e.ti.com/support/processors-group/processors/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693668/am62a7-am62a-isp-compatibility-with-os04a10-120-db-hdr-sensor/6525572Thu, 29 Oct 2026 22:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9eea5528-cce7-4fa9-92b4-c0cde64631e2Jianzhong XuHello, Thanks for your inquiry. Below are my answers to your questions. 1. AM62A ISP can do HDR combine up to 3 images, but we prefer to have the combine (merging) done in the sensor. 2. Assuming DCG/PWL-compressed mode outputs one image per frame, this is the preferred mode. 3. HDR merging and PWL decoding are supported directly by the AM62A VISS. 4. No. 5. No, the HDR combination has not be validated for 4MP at 30fps. Regards, Jianzhonghttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686713/am6411-am64xx-synchronization-of-timers/6525563Thu, 29 Oct 2026 22:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:41d4cf83-0db4-4d97-b696-3ba05da2e4aaAnastas YordanovHi Andrea, I actually found that the AM64x PRU-ICSSG subsystem peripheral modules - IEP0 and IEP1 may have such a capability - just a single 64-bit timer shared between several digital event capture inputs. As there might be some hardware limitations depending on the requirements for your project, would you please clarify some details of your SITARA software architecture - is it possible to directly use the PRU-ICSS subsystem core(s) as a host that processes the digital input capture events as interrupts, or you would like to use other CPU cores - A53, DM R5 or M4 as interrupt processing hosts. How frequently do the sensor output synchronization events occur - 10 MHz, higher frequency ? Does capture logic need to react only on rising edges or falling edges or on both events (toggle detection). Do you use TI Linux SDK or MCU PLUS SDK ? Which version of SDK ? Let me know if the IEP (Industrial Ethernet Peripheral 64-bit Timer) option is still interesting for you and if we shall continue to assess the feasibility of your system with the AM6411 processor. Thank you ! Best Regards, Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693935/am2434-is-errata-i2499-from-am263x-am261x-also-present-on-am243x/6525557Thu, 29 Oct 2026 22:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:44288f28-4962-4213-bb41-b4e27e5cbf5aJames PairHi Anber, I&#39;m going to find appropriate person to reroute your inquiry too. It was classified as Failure Analysis, Customer Returns but I do not believe that is what you are seeking to pursue. -Jameshttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1683019/am6442-confirmation-of-mitigation-requirements-for-am6442-silicon-revision-2-0-errata-i2196-i2207-i2259-i2232-i2138/6525509Thu, 29 Oct 2026 21:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:63bbb0d6-3463-4172-b14e-2d341f2eff12Anastas YordanovHi Tsuchiya-san, Are you ok with the provided answers ? Let us know if we shall close the thread. Thank you ! Best Regards, Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693935/am2434-is-errata-i2499-from-am263x-am261x-also-present-on-am243xThu, 29 Oct 2026 21:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bd676058-99c2-4e89-a102-db69c3bc0adeAnBerPart Number: AM2434 Team, Errata i2499 was recently added in www.ti.com/.../sprz488 for AM263xP. Does a comparable errata exist for AM243x? See also https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers---internal/f/arm-based-microcontrollers---internal-forum/1693934/am263p4-silicon-errata-sprz488g-i2499-inconsistancy-in-revision-numbering Thanks in advance, AnberIndustrial AutomationAM2434https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693145/am6442-issues-setting-up-main_gpiomux_introuter/6525450Thu, 29 Oct 2026 20:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1c269eda-7e90-4129-bf0e-1badd8ec5aecNick SaulnierSummary of what I can confirm vs. what I can&#39;t Three concrete problems are visible in the code/config; the firewall-zone question and the exact meaning of -19 are not covered by the documentation I retrieved — flagged at the end. 1. The source index is wrong in both calls GPIO1_GPIO_OUT_57 is wired to MAIN_GPIOMUX_INTROUTER0_IN_IN_147 1 , confirmed independently by the input-side interrupt table 2 . Raw call uses src_index = 80+57 = 137 → wrong. It must be 147 . Non-raw call ( src_id = TISCI_DEV_GPIO1, src_index = 57 ) is the abstracted form and should be correct for the source side, so its failure points at the destination/ownership side (item 2). Note the customer&#39;s own direct register write used 0x00010093 (= input 147), i.e. the register-level value was right while the TISCI src_index was not. An existing E2E case with this exact -19 symptom was resolved by correcting the GPIO source index in the raw route parameters 3 . 2. Output 46 ownership / reachability Two independent checks are required and both must pass: Check What to verify Output physically reaches ICSSG1 MAIN_GPIOMUX_INTROUTER0 outputs fan out to DMSC, GICSS, R5F cores, DMASS and PRU-ICSSG destinations — confirm from the output map that out_46 is the line landing on ICSSG1 event 46+64, not an output wired elsewhere 4 RM allocation The router output must be allocated in the RM board config to the host involved in the route; the documented failure mode is exactly &quot;requesting core is not assigned the selected MAIN_GPIOMUX_INTROUTER0 output,&quot; fixed by reassigning the output and rebuilding the board config + SBL 5 Additional ownership traps that produce the same rejection: Routing is one-to-one . If that router input/output is already consumed by another destination, the request is refused 6 . SYSFW will not re-allocate an already-allocated resource without a reset 7 . Confirm the SBL actually carries the edited rm-cfg. A board-config/SBL mismatch is a known cause of this failure, because the flashed RM config assigns the router input to a different core than the application expects 8 . Editing rm-cfg.yaml alone has no effect until rebuilt and reflashed. R5FSS0-0 is not categorically barred from this router — the stock SDK config grants it outputs 0–7, and anything beyond that needs explicit reallocation 9 . I cannot verify the type: 192 / host_id: 51 values in the rm-cfg entry against any retrieved source. Please confirm those against the SDK&#39;s resource-type and host-ID headers for the SDK version in use — if host_id names the wrong host (caller vs. ICSSG1 destination), the allocation exists but does not apply to this request. 3. &quot;Does rmIrqSetRaw bypass the rm-cfg check?&quot; — No That inference does not hold. What the evidence supports: MAIN_GPIOMUX routing is a resource-managed path: SYSFW validates the requested output against board-configured host ownership and rejects unallocated/conflicting requests, regardless of raw vs. abstracted API 3 , 5 . TIMESYNC_INTRTR0 is a separate, dedicated time-sync event router (42 inputs / 41 outputs, 6-bit MUX_CNTL) 10 , 11 , distinct from GPIOMUX_INTRTR0 (54 outputs, 8-bit MUX_CNTL) 12 , and the two feed different DMSS L2G interrupt-input ranges 13 . So the asymmetry is a per-router resource-management policy difference , not a property of rmIrqSetRaw . The TIMESYNC route succeeding without an rm-cfg entry tells you nothing about GPIOMUX. Gap: no retrieved source states the SYSFW rule that exempts TIMESYNC outputs from RM allocation. I cannot give the authoritative reason. Also: a successful Sciclient_rmIrqSetRaw ack does not mean the interrupt will fire — the destination core&#39;s interrupt line must be registered and enabled separately. The cited GPIO case only worked after fixing that 3 . 4. The data abort on the direct register write Expected. MAIN_GPIOMUX interrupt-router outputs are configured only through SYSFW/TISCI; direct register writes are not a supported path 3 . Reading PID succeeding while output-register writes abort is consistent with access being arbitrated outside the CBASS firewall region the customer inspected. Gap: the documentation I retrieved does not describe the firewall programming or write-protection mechanism for MAIN_GPIOMUX_INTROUTER0, so I cannot explain why ID34/region 8 behaves differently for this router vs. TIMESYNC and CMP event routers. That specific question needs a SYSFW/security-config answer. Recommended sequence Change raw src_index from 137 → 147 . Confirm out_46 is the ICSSG1-connected output in the output map 4 . Validate type and host_id in the rm-cfg entry against the SDK headers; the host must be the one SYSFW checks for this route. Rebuild and reflash the SBL so the modified rm-cfg is actually active, then retest. Separately register/enable the interrupt at the ICSSG1 destination. When changing mux control, disable the interrupt first and re-enable after, to avoid spurious asynchronous output toggles 14 . Note one unresolved discrepancy worth checking in the TRM: one table lists GPIO1 outputs mapping into router inputs 99–131 15 , while the GPIO1_GPIO_OUT_57 → IN_147 mapping comes from two other tables 1 , 2 . Confirm which table covers direct (non-banked) outputs before finalizing the index. Follow up: Would it help to pull the specific SDK board-config documentation for rm-cfg.yaml resource types and host IDs so the type: 192 / host_id: 51 entry can be validated directly? AM64x TRM — GPIO1_GPIO_OUT_57 to router input mapping AM64x TRM — MAIN_GPIOMUX_INTROUTER0 input interrupt table E2E: AM6442 — How to config the GPIO MUX interrupt router AM64x TRM — MAIN_GPIOMUX_INTROUTER0 output destinations E2E FAQ: AM64x — How to run MCU SDK GPIO interrupt example on Linux E2E FAQ: AM64x — Routing the same GPIO bank interrupts to different destination cores E2E: AM6442 — Triggering DMA for PRU IO data capture E2E FAQ: AM6442 — GPIO input interrupt Sciclient config failed in MCU+ SDK 6.0 above E2E: AM6442 — Sciclient_gpioIrqSet fails on R5FSS0-0 AM64x TRM — TIMESYNC_INTRTR0 overview AM64x TRM — TIMESYNC router MUX_CNTL registers AM64x TRM — GPIOMUX router MUX_CNTL registers AM64x TRM — DMSS L2G interrupt input ranges AM64x TRM — Interrupt router programming guidance AM64x TRM — GPIO1 interrupts into router inputs 99–131https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693145/am6442-issues-setting-up-main_gpiomux_introuter/6525445Thu, 29 Oct 2026 20:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ebcd1d61-637d-40bc-bfcc-dbea27b34e31Nick SaulnierHello, If latency is not an issue, then your design is probably fine. I am going to send your thread over to my team member now. Initial AI-assisted thoughts While we are waiting for my team member to comment, I&#39;ll attach some input from one of my AI tools. Perhaps it will be useful. Regards, Nickhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525441Thu, 29 Oct 2026 19:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:15b1f598-a2a4-4e14-b8c8-2730dbfcb66fJim ZhangOK, SBL also runs on the MCU1_0 core itself, it loads the MCU1_0 application and starts it. No question on this part. Is there SBL running on MCU2_0 and starts mcu2_0 app at the end of its execution? At that time if the SBL and system firmware execution completed, and app started. If I stop the app, and reload a new version of app, and restart the app and debugging. That should be the same procedure like you debug from CCS: you power on the board, and let bootloader botting the board, and run to application; then you stop the app, and load new version of app to ram, and you should be able to debug, right? I am doing the same like CCS, let SBL and system firmware run, and let it run to app, stop and replace app, and debughttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525416Thu, 29 Oct 2026 19:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:26086bad-7627-404a-a573-142f28d59479Suman AnnaHi Jim, [quote userid=&quot;346969&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525142&quot;]My understanding is MCU2_0 will be out of reset by bootloader, which is running on A72, not by the mcu2_0 application itself. [/quote] Yes, correct. MCU2_0 has to be loaded and booted by an loader entity, which can be the R5 SBL or the BootApp on MCU1_0 or the U-Boot or Linux kernel on the A72 core. The core itself will just run its application firmware. This really depends on your boot flow for your product. [quote userid=&quot;346969&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525385&quot;]I understood your point now: reloading a new firmware to a core that already booted by bootloader is not supported [/quote] Indeed. [quote userid=&quot;346969&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525385&quot;]1: for core mcu1_0, SBL will do the same[/quote] Yes, SBL also runs on the MCU1_0 core itself, but it is not the MCU1_0 application. The SBL loads a MCU1_0 application firmware at the end of its execution, and does a self reset to launch the MCU1_0 Application. This is a mandatory step, because MCU1_0 firmware needs to have the Device Management functionality. [quote userid=&quot;346969&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525385&quot;]2: for other cores like mcu2_o, only do the core initialization, don&#39;t load and run the mcu2_0 firmware/app, delay this part till kernel is booting up, and load and run fw/app[/quote] MCU2_0 can be booted by the SBL itself as part of the MultiCore AppImage, or if left alone, then a subsequent component like the A72 U-Boot can load it. You already have a bootloader for your board, so you should already have an established boot flow for your board by now. regards Sumanhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525414Thu, 29 Oct 2026 19:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9c24bf03-661e-4774-92f2-e34a7383f684Jim Zhang[quote userid=&quot;35368&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6524269&quot;]the Boot Flow Options on TDA4 Devices Application Note[/quote] The SBL in this app note is very confusing. Is it the u-boot/bootloader that runs on A72 side ? or is it a bootloader that runs on R5 core ? The first part sounds like u-boot on linux side; the J721e example talks more about SBL for R5 corehttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1689839/am62p-sk-am62p-lp-powervr-bxs-4-64-ddk-25-2-vulkan-compute-pipeline-barrier-cpu-cost-ddr-qos-for-the-gpu-and-queue-global-priority/6525409Thu, 29 Oct 2026 19:24:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e85c4c2d-55e8-4050-bb3e-342aa59d8b32Shriya SurtiHi Markus, Thanks for the update. Regards, Shriyahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525385Thu, 29 Oct 2026 18:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d4355af9-8200-48f0-bb5c-f9d9a8d17532Jim ZhangI understood your point now: reloading a new firmware to a core that already booted by bootloader is not supported We probably need customize the bootloader to make our deployment strategy work: 1: for core mcu1_0, SBL will do the same 2: for other cores like mcu2_o, only do the core initialization, don&#39;t load and run the mcu2_0 firmware/app, delay this part till kernel is booting up, and load and run fw/apphttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1687520/j784s4xevm-j784s4xevm-wave5-vpu-driver-crash-when-using-cma-pool-larger-than-4gb/6525375Thu, 29 Oct 2026 18:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:913a9980-dba8-48ca-936d-3f3ce234683eSarabesh SrinivasanOk thanks for the clarification. I&#39;ll get back to you on this. Thanks, sarabesh S.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1561031/j784s4xevm-pcie-ep-rc-transfer-speed-performance-slow-in-sdk-11/6525347Thu, 29 Oct 2026 18:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:570e378d-71d4-42b9-beea-19ad5f10f5d5Takuma FujiwaraGoing through old open threads, unlocking, and updating. Will link new FAQ for PCIe performance optimization in case issue still open, and also for other that may find this thread with same issue: [FAQ] How to optimize performance of PCIe on Jacinto TDA4 device? Regards, Takumahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1527926/trdx-3p-aquila-am69-using-dp-at-4k-60fps-resolution/6525344Thu, 29 Oct 2026 18:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0dca7889-d248-4936-ac1c-fc022ac1ac60Takuma FujiwaraGoing through old E2E threads left open, unlocking, and updating. There was a in-depth analysis for the 4K 60FPS with a resulting application note for ways to fix: https://www.ti.com/lit/an/sprads6a/sprads6a.pdf?ts=1793298360531&amp;ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTDA4VH-Q1 Linking above in case issue open and for others that may find this thread. Regards, Takumahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693900/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-debugfsThu, 29 Oct 2026 16:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2fd0ec47-0a08-44b9-a93b-0164d007ce74Kaloyan DimitrovPart 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: &amp;am33xx_pinmux { pinctrl-names = &quot;default&quot;; pinctrl-0 = ; board_pins: board_pins { pinctrl-single,pins = ; }; }; 3) I boot into a BusyBox rootfs and try exporting the GPIO pin and toggling it like that: echo 562 &gt; /sys/class/gpio/export &amp;&amp; echo out &gt; /sys/class/gpio/gpio562/direction &amp;&amp; echo 1 &gt; /sys/class/gpio/gpio562/value But the level doesn&#39;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, Kalbuilding automationAM3358https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1687254/tda4al-q1-support-required-for-running-c7x-vision-apps-on-custom-yocto-sdk/6525232Thu, 29 Oct 2026 16:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8580b2ed-8e96-4689-b480-8906e918a08eJared McArthurHi jayadeva sm , Are you able to access git.ti.com in general? Is the issue currently persisting? Best, Jaredhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1693496/dra821u-how-to-change-uboot-to-boot-a-different-os/6525199Thu, 29 Oct 2026 16:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0e4104ac-0354-4d7a-b974-c6c567cc6618Eric PatriziI cannot change the bootcmd in uboot as the saveenv command is not available, so it would not be persistent. If you mean change the bootcmd in uboot source and rebuild uboot, I could do that, but should not have to just to use the board. I do not have any security or trusted boot requirements. At some point I found a ‘setenv verify no’ command that disables the signature checking. I was able to use uEnv.txt to set this and configure a new boot target and change the boot_targets environment variable to call it. This does boot my image and does not require any signatures. This is probably the solution I was looking for. It seems pretty straight forward and bypasses the signature issue. Thanks for the help, Erichttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1453685/faq-am625-am623-am620-q1-am62ax-am62px-am62d-q1-am62l-am64x-am243x-design-recommendations-custom-board-hardware-design---drive-strength-configuration-for-dual-voltage-lvcmos-and-sdio-io-buffers-and-fixed-1-8v-1p8-lvcmos-buffe/6525159Thu, 29 Oct 2026 15:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fdd96021-200a-41dc-b410-a83a9c681d95Kallikuppa SreenivasaHi Board designers, FYI only. (4) [FAQ] TDA4VM-Q1: TDA4 Drive Strength Controls - Processors forum - Processors - TI E2E support forums Regards, Sreenivasahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1686320/tda4vh-q1-main-r5-peripheral-access/6525142Thu, 29 Oct 2026 15:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bca277c1-665c-4b0b-9a75-f4fb2c02994aJim ZhangMy understanding is MCU2_0 will be out of reset by bootloader, which is running on A72, not by the mcu2_0 application itself. Imaging that mcu2_0 app is a baremetal application, it does not have firmware to bring the core out of reset