summaryrefslogtreecommitdiff
path: root/board/ti
AgeCommit message (Collapse)Author
2025-09-23Merge tag 'v2025.10-rc5' into nextTom Rini
Prepare v2025.10-rc5
2025-09-17board: ti: am57xx: Remove "ti/omap/" from name_fit_configAnurag Dutta
Commit 649f4a7d3ca7 ("board: ti: am57xx: Set fdtfile from C code instead of findfdt script") prepends "ti/omap/" to the actual name of the fdtfile whereas fit image boot needs exact dtb name. So, remove "ti/omap" from name_fit_config by substituting it with an empty string. Fixes: 649f4a7d3ca7 ("board: ti: am57xx: Set fdtfile from C code instead of findfdt script") Signed-off-by: Anurag Dutta <[email protected]> Reviewed-by: Udit Kumar <[email protected]>
2025-09-15board: ti: common: Kconfig: add CMD_MEMINFOAnshul Dalal
Add CMD_MEMINFO and CMD_MEMINFO_MAP to list of configs implied by TI_COMMON_CMD_OPTIONS. This allows users to easily view the memory configuration and the memory maps at runtime. Signed-off-by: Anshul Dalal <[email protected]>
2025-09-11board: ti: fdt_ops: make ti_set_fdt_env() const-correctBhimeswararao Matsa
Make the fdt_map parameter a pointer to const, since the function only reads the mapping table. This improves API correctness and allows maps to live in read-only data. No functional change intended Signed-off-by: Bhimeswararao Matsa <[email protected]>
2025-09-11board: ti: am65x: Overwrite get_overlay_mmcJudith Mendez
Unlike other K3 SoC's, am65 SoC has the capability to detect daughter cards and automatically generate a list of white-space separated overlays in name_overlays environment variable. When applied during boot with get_overlay_mmc, the path to overlays with default distribution is incorrect where path is currently: boot/dtb and the overlays exist in boot/dtb/ti. Fix the path in get_overlay_mmc so that overlays are automatically applied correctly during boot time. Signed-off-by: Judith Mendez <[email protected]>
2025-09-08Merge tag 'v2025.10-rc4' into nextTom Rini
Prepare v2025.10-rc4
2025-09-08board: ti: dra7xx: Set fdtfile from C code instead of findfdt scriptAnurag Dutta
We now can provide a map and have the standard fdtfile variable set from code itself. This allows for bootstd to "just work". Signed-off-by: Anurag Dutta <[email protected]>
2025-09-08board: ti: am57xx: Set fdtfile from C code instead of findfdt scriptAnurag Dutta
We now can provide a map and have the standard fdtfile variable set from code itself. This allows for bootstd to "just work". Signed-off-by: Anurag Dutta <[email protected]>
2025-09-08board: ti: am57xx: Change to using .envAnurag Dutta
Move to using .env file for setting up environment variables for am57xx and dra7xx. Signed-off-by: Anurag Dutta <[email protected]>
2025-08-20Merge patch series "Add support for Ethernet boot"Tom Rini
Chintan Vankar <[email protected]> says: This series adds bind method for CPSW to avoid explicit probing, removes explicit probing of CPSW, adds support for Ethernet boot on SK-AM68, SK-AM62P-LP, J722S, SK-AM69. Link: https://lore.kernel.org/r/[email protected]
2025-08-20board: ti: j722s: evm: Enable cache for J722sChintan Vankar
Enable cache for J722s to optimize performance of CPU to access data from memory. Reviewed-by: Alexander Sverdlin <[email protected]> Signed-off-by: Chintan Vankar <[email protected]>
2025-08-20board: ti: am62px: evm: Enable cache for AM62pAndreas Dannenberg
Enable cache for AM62p to optimize performance of CPU to access data from memory. Reviewed-by: Alexander Sverdlin <[email protected]> Signed-off-by: Andreas Dannenberg <[email protected]> Signed-off-by: Chintan Vankar <[email protected]>
2025-07-24treewide: Remove empty board_init() function from all boardsSam Protsenko
Commit 86acdce2ba88 ("common: add config for board_init() call") introduced CONFIG_BOARD_INIT option. This option can be disabled for the boards where board_init() function is not needed. Remove empty board_init() calls for all boards where it's possible, and disable CONFIG_BOARD_INIT in all related defconfigs. This cleanup was made semi-automatically using these scripts: [1]. No functional change, but the binary size for the modified boards is reduced a bit. [1] https://github.com/joe-skb7/uboot-convert-scripts/tree/master/remove-board-init Signed-off-by: Sam Protsenko <[email protected]> Tested-by: Adam Ford <[email protected]> #imx8mm_beacon Tested-by: Bryan Brattlof <[email protected]> Acked-by: Peng Fan <[email protected]> #NXP boards
2025-07-11board: ti: Clean up formatting in rm-cfg.yamlNeha Malcom Francis
Move to using the latest generated RM YAML configuration files generated by the K3 Resource Partitioning Tool which updates them to have standard formatting with respect to indentation. These files were generated from the untagged commit 41718bd5f915 ("docs: Update docs and move them to docs folder") of the K3 Resource Partitioning tool. This tool is packaged as a part of the public SDK and is not otherwise publicly available. Signed-off-by: Neha Malcom Francis <[email protected]> Reviewed-by: Udit Kumar <[email protected]>
2025-07-09Merge patch series "board: ti: am33xx: Add Ethernet support for Beaglebone ↵Tom Rini
Green Eco" Romain Gantois <[email protected]> says: This is version one of my series which enables Ethernet support on the BBGE board. This requires three main changes: - Describing the MAC<->PHY link and DP83867 PHY accurately in the device tree - Enabling the RGMII1 pinmux configuration - Enabling the DP83867 driver These changes are all applied in patch 2. Patch 1 enables excluding the DP83867 driver from SPL. This is done to avoid size issues when adding the DP83867 driver to the am335x-evm defconfig. Link: https://lore.kernel.org/r/[email protected]
2025-07-09board: ti: am33xx: Add Ethernet support for Beaglebone Green EcoRomain Gantois
Currently, the Ethernet interface of the BBGE board isn't properly supported. To support this interface, describe the MAC<->PHY RGMII link and the DP83867 PHY in the BBGE device tree. Enable the DP83867 PHY driver in U-Boot Proper and mux the relevant RGMII lines. Signed-off-by: Romain Gantois <[email protected]> Tested-by: Judith Mendez <[email protected]>
2025-06-27Revert the last two mach-k3 changesTom Rini
This reverts both commit 4628730ee6c4 ("mach-k3: add runtime memory carveouts for MMU table") as well as commit b77066d73261 ("mach-k3: add dynamic mmu fixups for SPL stage") as some feedback from previous iterations was missed. This reverts commit b77066d73261855af406422fbbe28a5d527f4dbf and commit 4628730ee6c40864dbe475e4ca91e47a92f371fe. Signed-off-by: Tom Rini <[email protected]>
2025-06-27mach-k3: add runtime memory carveouts for MMU tableAnshul Dalal
In u-boot we only provide a single MMU table for all k3 platforms, this does not scale for devices with reserved memory outside the range 0x9e780000 - 0xa0000000 or for devices with < 2GiB of memory (eg am62-SIP with 512MiB of RAM). To properly configure the MMU on various k3 platforms, the reserved-memory regions need to be queried at runtime from the device-tree and the MMU table should be updated accordingly. This patch adds the required fixups to the MMU table (during proper U-boot stage) by marking the reserved regions as non cacheable and keeping the remaining area as cacheable. For the A-core SPL, the 128MiB region starting from SPL_TEXT_BASE is marked as cacheable i.e 0x80080000 to 0x88080000. The 128MiB size is chosen to allow for future use cases such as falcon boot from the A-Core SPL which would require loading kernel image from the SPL stage. This change also ensures the reserved memory regions that all exist past 0x88080000 are non cacheable preventing speculative accesses to those addresses. Signed-off-by: Anshul Dalal <[email protected]>
2025-06-18Merge patch series "Add IPC support on MCU R5F cluster in Split Mode"Tom Rini
Beleswar Padhi <[email protected]> says: This series adds remoteproc support on MCU R5F in Split mode. During boot, ROM can bring up the boot R5F cores in either lockstep or split mode based on X509 certificate flags. If booted in lockstep mode, the MCU R5F cores will run first the R5 SPL, and then once A72 comes up, will run the Device Manager (DM) firmware. But if booted in split mode, core 0 will run DM firmware and second core sits in WFI. Shut it down so that other firmwares can later be loaded on them. The shutdown of MCU R5 Core 1 is invoked at A72 SPL init, as by that time Device Manager (DM) is up and running on R5 Core 0. The shutdown of MCU R5 Core 1 is handled by Device Manager itself. Test logs: https://gist.github.com/3V3RYONE/ee8e3cb9aa5f4c5c00b059b9c14bfa98 Link: https://lore.kernel.org/r/[email protected]
2025-06-18board: ti: j7*: Add firmware for MCU R5 core1Beleswar Padhi
Link the default firmware in the environment variable for MCU R5 core1 for all J7 platforms. Signed-off-by: Beleswar Padhi <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2025-06-12Merge patch series "ti: Add support for eCAP PWM and LCD pin mux"Tom Rini
Sukrut Bellary <[email protected]> says: This patch series adds the support for 1. In am33xx SoC[1], enhanced capture (eCAP) supports auxiliary PWM (APWM). This series adds the PWM driver support for the APWM feature for eCAP on AM33xx. AM335X_ECAP0_IN_PWM0_OUT is used to enable the backlight. 2. Fix build warning in ti-ehrpwm driver in dev_deb(). 3. Enable eCAP0 PWM and LCD pin muxing to support splash screen on AM335x EVM[2]. [1] AM335x TRM - https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf [2] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358 per discussion on the earlier patch series, https://lore.kernel.org/all/[email protected]/ dropping the device tree changes in this series due to OF_UPSTREAM conflict. As we are dropping the DT patch, started with the new series instead of V2. This series doesn't contain defconfig changes since we don't want to enable LCD, splash screen and PWM support by default. Enabling splash screen and PWM support in defconfig causes u-boot crash on AM335x based beaglebone black. This will be handled in a separate patch. Link: https://lore.kernel.org/r/[email protected]
2025-06-12board: ti: am335x: Enable eCAP0 PWM and LCD pin muxingSukrut Bellary
On AM335x EVM[1], 1. pin AM335X_ECAP0_IN_PWM0_OUT is used to enable the backlight. ECAP0 can be configured in single channel PWM mode. If CONFIG_PWM_TI_ECAP is enabled, perform eCAP0 pin muxing. 2. Pins LCD_DATA0 - LCD_DATA15, gpmc_ad8 - gpmc_ad15 and lcd_vsync, lcd_sync, lcd_ac_bias_en, lcd_pclk are used for driving LCD. If CONFIG_AM335X_LCD is enabled, perform the LCD pin muxing. This is required to enable splash screen support on AM335x EVM. [1] AM335x EVM - https://www.ti.com/tool/TMDXEVM3358 Signed-off-by: Sukrut Bellary <[email protected]>
2025-06-09Merge tag 'v2025.07-rc4' into nextTom Rini
Prepare v2025.07-rc4
2025-06-04board: ti: am62ax: env: Use default MMC related argsAndrew Davis
There are common MMC args for TI plats in include/environment/ti/mmc.env. Since we already include this, there is no need to redefine these MMC vars. Use the defaults. This seems like something that could have been done while refactoring these vars in the first place as it happened after this AM62A file was available hence the fixes tag. Reported-by: Chirag Shilwant <[email protected]> Fixes: 3709b529156e ("env: ti: mmc.env: Move mmc related args to common place") Signed-off-by: Andrew Davis <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]> Acked-by: Chirag Shilwant <[email protected]> Reviewed-by: Judith Mendez <[email protected]>
2025-06-02Merge patch series "Audit include list for include/[a-m]*.h"Tom Rini
Tom Rini <[email protected]> says: Hey all, Related to my other series I've posted recently on cleaning up some headers, this series here is the result of at least lightly auditing the #includes used in include/[a-m]*.h. This ignores subdirectories, as at least in part I think the top-level includes we've constructed are the most likely places to have some extra transitive include paths. I'm sure there's exceptions and I'll likely audit deeper once this first pass is done. This only gets as far as "include/m*.h" because I didn't want this to get too big. This also sets aside <miiphy.h> and <phy.h>. While miiphy.h does not directly need <phy.h> there are *so* many users and I think I had half of the tree just about not building when I first tried. It might be worth further investigation, but it might just be OK as-is. Link: https://lore.kernel.org/r/[email protected]
2025-06-02global: Cleanup usage of "ETH_ALEN"Tom Rini
The value of "ETH_ALEN" is defined to 6 in <linux/if_ether.h>. This file is included in <net.h>. In the places where we had ETH_ALEN but no direct include of <net.h>, add <linux/if_ether.h>. In the places where we had a custom name used, make use of ETH_ALEN instead. Signed-off-by: Tom Rini <[email protected]>
2025-05-29global: Avoid indirect inclusion of <env.h> from <net.h>Tom Rini
Now that env_get_ip() has been removed, the include file <net.h> does not need anything from <env.h>. Furthermore, include/env.h itself includes other headers which can lead to longer indirect inclusion paths. To prepare to remove <env.h> from <net.h> fix all of the remaining places which had relied on this indirect inclusion to instead include <env.h> directly. Reviewed-by: Jerome Forissier <[email protected]> # net/lwip Acked-by: Ilias Apalodimas <[email protected]> Reviewed-by: Wolfgang Wallner <[email protected]> Reviewed-by: Martyn Welch <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2025-05-09board: ti: sec-cfg.yaml: Fix OTP write_host_id orderAndrew Davis
The write_host_id is the last element here and order does matter. This may have gone unnoticed before as by default all elements are 0, but if this is updated to a different host, it will not work. Update the order so write_host_id is the last element in all current secure board configs. Reported-by: Prashant Shivhare <[email protected]> Signed-off-by: Andrew Davis <[email protected]>
2025-05-09board: ti: common: Kconfig: add CMD_CACHEAnshul Dalal
Add CMD_CACHE to list of configs implied by TI_COMMON_CMD_OPTIONS. This allows the usage of cache commands from U-Boot prompt. Signed-off-by: Anshul Dalal <[email protected]> Reviewed-by: Daniel Schultz <[email protected]>
2025-05-02Merge patch series "k3-j784s4*: Enable ESMs and related PMIC"Tom Rini
Udit Kumar <[email protected]> says: This series enables the ESMs and the associated PMIC. Programming these bits is a requirement to make the watchdog actually reset the board. Series supports WDT reset on all TI platforms based upon J784S4 SOC including cut down (J742S2). Bootlogs for reset AM69: https://gist.github.com/uditkumarti/dca2171aafd6d50c82159346f9a0102f#file-am69-L2466 J784S4: https://gist.github.com/uditkumarti/dca2171aafd6d50c82159346f9a0102f#file-j784s4-L2704 J742S2: https://gist.github.com/uditkumarti/dca2171aafd6d50c82159346f9a0102f#file-j742s2-L2614 Link: https://lore.kernel.org/r/[email protected]
2025-05-02board: ti: am33xx: Add support for BeagleBoard Green EcoKory Maincent
SeeedStudio BeagleBone Green Eco (BBGE) is a clone of the BeagleBone Green (BBG). It has minor differences from the BBG, such as a different PMIC, a different Ethernet PHY, and a larger eMMC. The PMIC is not yet supported in mainline, but the work is ongoing. Signed-off-by: Kory Maincent <[email protected]>
2025-05-02board: ti: j784s4: Initialize the ESM & PMIC ESMKeerthy
Initialize the ESM & PMIC ESM. This allows things like the watchdog to reset the board when tripped. Signed-off-by: Keerthy <[email protected]> Signed-off-by: Neha Malcom Francis <[email protected]> Signed-off-by: Andrew Halaney <[email protected]>
2025-04-24configs: am62*_evm_a53_defconfig: Add TI_COMMON_CMD_OPTIONSJudith Mendez
Add TI_COMMON_CMD_OPTIONS config options to Sitara K3 boards at a53 stage since we rely on most of the commands implied for testing and debugging purposes. Since all commands are now enabled by default, remove the redundant CMD_* options in the a53 defconfigs. Also add MMC_REG & MMC_SPEED_MODE_SET useful commands to TI_COMMON_CMD_OPTIONS. Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Bryan Brattlof <[email protected]>
2025-04-11Merge patch series "Switch to using $(PHASE_) in Makefiles"Tom Rini
Tom Rini <[email protected]> says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/[email protected]
2025-04-11Kbuild: Always use $(PHASE_)Tom Rini
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <[email protected]>
2025-04-11board: remove capsule update support in set_dfu_alt_info()Jonathan Humphreys
Now that capsule update sets the dfu_alt_info environment variable explicitly, there is no need to support it in the set_dfu_alt_info() function. Decouple SET_DFU_ALT_INFO from EFI_CAPSULE_FIRMWARE_FIT and EFI_CAPSULE_FIRMWARE_RAW. For many boards, this was the only use of set_dfu_alt_info() so remove the function entirely. Fixes: a9e6f01a941f ("efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled") Signed-off-by: Jonathan Humphreys <[email protected]> Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> # for board/libre-computer/* Reviewed-by: Ilias Apalodimas <[email protected]> Reviewed-by: Wadim Egorov <[email protected]> # for
2025-04-08Merge branch 'next'Tom Rini
Note that this undoes the changes of commit cf6d4535cc4c ("x86: emulation: Disable bloblist for now") as that was intended only for the release due to time.
2025-04-05arm: mach-k3: j721e: Split out J7200 SoC support from J721eAndrew Davis
Currently in j721e_init.c we check which firewalls to remove using the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this as J721e and J7200 have different IP and firewalls but use the same SoC definition (SOC_K3_J721E) even though they are different SoCs. The idea was they would be similar enough that they both could use the same SoC config to help with common code sharing. Board checks would then be used differentiate. This has grown far too messy to maintain any more, especially now that there is more than one board using J721e (EVM, SK, Beagle AI64). As differentiation is done based on board, every one of these boards would have to have checks added for them. Instead let's split J7200 support out from J721e like how normal new SoC support is done. This patch touches several subsystems and could not be split much better as when we add SOC_K3_J7200 we want to make use of it in all spots that once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when building for J7200 boards. Signed-off-by: Andrew Davis <[email protected]>
2025-04-03Merge patch series "Introduce J742S2 SoC and EVM"Tom Rini
Manorit Chawdhry <[email protected]> says: The series adds support for J742S2 family of SoCs. Also adds J742S2 EVM Support and re-uses most of the stuff from the superset device J784s4. This device is a subset of J784S4 and shares the same memory map and thus the code is being reused from J784S4 to avoid duplication. It initially cleans up the J784s4 and AM69 files so that they can be re-usable for j742s2 and then it introduces J742S2. The DT for the following SoC will be coming to U-boot during 6.13 Sync so the series is kept as RFC till then. Here are some of the salient features of the J742S2 automotive grade application processor: The J742S2 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications. Some changes that this devices has from J784S4 are: * 4x Cortex-A72 vs 8x Cortex-A72 * 3x C7x DSP vs 4x C7x DSP * 4 port ethernet switch vs 8 port ethernet switch * 2 DDR controller vs 4 DDR controller Test logs: https://gist.github.com/manorit2001/f7df0e8cca1e9973b4361f0559c6f53d Link: https://lore.kernel.org/r/[email protected]
2025-04-03configs: Introduce configs for J742S2Manorit Chawdhry
Based off j784s4 configs with delta changes for J742S2 [ Add AVS support for J742S2 ] Signed-off-by: Keerthy <[email protected]> Signed-off-by: Manorit Chawdhry <[email protected]>
2025-04-03arm: dts: Introduce J742S2 U-boot DTS filesManorit Chawdhry
Include the U-boot device tree files needed to boot the board. [ DDR config ] Signed-off-by: Neha Malcom Francis <[email protected]> Signed-off-by: Manorit Chawdhry <[email protected]>
2025-04-03board: ti: Introduce basic board files for the J742S2 familyManorit Chawdhry
Introduce the basic files needed to support the TI J742S2 family of SoCs. Signed-off-by: Manorit Chawdhry <[email protected]>
2025-04-03arm: dts: k3-j784s4-ddr: Refactor J784s4 ddr file to a common fileManorit Chawdhry
Refactor J784s4 ddr file to a common file which uses the superset device to allow reuse in j742s2-evm which uses the subset part. Signed-off-by: Manorit Chawdhry <[email protected]>
2025-03-30board: ti: am62px: rm-cfg: Add support for HC BCDMAVishal Mahaveer
The first 4 block copy channels and rings on AM62P support High Capacity Block Copy. These channels have approximately 3x improvement over the normal Block copy channels when doing DDR-to-DDR copy. Currently, during allocation these channels do not have a separate interface and are allocated with normal BCDMA channels. Latest TIFS and DM firmware adds support for differentiating these High Capcity resources. This update is for allocating these new resource type to different hosts with below mentioned scheme. --------------------- --------------- ------------- ---------------- Resource A53_2 MCU_R5 WKUP_R5 --------------------- --------------- ------------- ---------------- BCDMA HC CHAN [4] => 2 (Primary) 1 (Primary) 1 (Primary) BCDMA HC CHAN RING [4] => 2 (Primary) 1 (Primary) 1 (Primary) BCDMA CHAN [4] => 18 (Primary) 2 (Primary) 6 (Primary) BCDMA CHAN RING[4] => 18 (Primary) 2 (Primary) 6 (Primary) Signed-off-by: Sparsh Kumar <[email protected]> Signed-off-by: Sebin Francis <[email protected]> Signed-off-by: Vishal Mahaveer <[email protected]>
2025-03-28board: ti: am335x: Fix selection of BeagleBone GreenKory Maincent
The BeagleBone Green board is a revision of the BoneBlack board. Having BeagleBone Black devicetree listed before BeagleBone Green will select always the BeagleBone Black devicetree following the functioning of board_fit_config_name_match(). Fix it by changing the test condition and selecting BoneBlack board only if it is not a revision of this board. Signed-off-by: Kory Maincent <[email protected]>
2025-03-13board: ti: j784s4: Update Resource Management configsVaishnav Achath
Update rm-cfg.yaml and tifs-rm-cfg.yaml to account for the changes added in the K3 Resource Partitioning Tool v1.18 The change enables resource sharing between A72_2 and MAIN_0_R5_0 for the BCDMA CSI RX and TX channels, J784S4 supports upto 12 CSI cameras and 16 channels would not be enough for all such use cases for RTOS and Linux, thus sharing of resources in needed. Resource sharing between A72 and R5 for BCDMA CSI channels allow Linux to use 32 channels at a time. Signed-off-by: Vaishnav Achath <[email protected]> [[email protected]: rebased and sent on behalf] Signed-off-by: Neha Malcom Francis <[email protected]> Reviewed-by: Udit Kumar <[email protected]>
2025-02-20Merge patch series "AM62,AM62-LP,AM62A,AM62P,J722S: USB DFU and UMS"Tom Rini
Siddharth Vadapalli <[email protected]> says: This series enables USB DFU and USB Mass Storage functionality for AM62, AM62-LP, AM62A, AM62P and J722S SoCs. Link: https://lore.kernel.org/r/[email protected]
2025-02-20board: ti: j722s: env: include environment for DFUSiddharth Vadapalli
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Signed-off-by: Siddharth Vadapalli <[email protected]>
2025-02-20board: ti: am62px: env: include environment for DFU BootSiddharth Vadapalli
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Also add "usb" to the list of "boot_targets". While at it, add a newline at the end of the file. Signed-off-by: Siddharth Vadapalli <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: Roger Quadros <[email protected]>
2025-02-14board: ti: am62px: tifs-rm-cfg/rm-cfg: Update DMA resource sharing for CPSWSiddharth Vadapalli
The CPSW3G instance of CPSW on AM62PX SoC provides Ethernet functionality. Currently, Ethernet is supported on Linux which runs on the A53 core on the SoC, by allocating all of the DMA resources associated with CPSW to A53_2. In order to enable use-cases where the Ethernet traffic is sent from or consumed by various CPU cores on the SoC simultaneously, while at the same time, maintaining backward compatibility with the existing use-case of A53 being the sole entity that exchanges traffic with CPSW via DMA, update the DMA resource sharing scheme on AM62PX SoC to the following: --------------- -------------- ------------- ---------------- Resource WKUP_R5 MCU_R5 A53_2 --------------- -------------- ------------- ---------------- TX Channels [8] => 4 (Primary) 4 (Primary) 8 (Secondary) TX Rings [64] => 32 (Primary) 32 (Primary) 64 (Secondary) RX Channels [1] => 1 (Primary) 0 1 (Secondary) RX Flows [16] => 6 (Primary) 10 (Primary) 16 (Secondary) In the absence of primary owners of resources (existing use-case where A53 owns all of the CPSW DMA resources), the secondary owner can claim all of the resources as its own. For shared use-cases, the resources that are not claimed by the primary are communicated to the secondary owner allowing it to claim them. This ensures that Linux on A53_2 can continue claiming all DMA resources associated with CPSW in the absence of primary owners, while at the same time providing users the flexibility to share CPSW DMA resources across various CPU cores listed above if needed. While Linux has been mentioned as the Operating System running on A53, there is no dependency between the Operating System running on A53 and its ability to claim the CPSW DMA resources listed above. Signed-off-by: Siddharth Vadapalli <[email protected]>