summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-02-20lib: uuid: support more efi protocols in uuid_guid_get_str()Vincent Stehlé
Add more EFI protocols GUIDs to the translation table used by uuid_guid_get_str(). Signed-off-by: Vincent Stehlé <[email protected]> Cc: Tom Rini <[email protected]>
2025-02-20configs: starfive: use LwIP network stack and enable wget commandE Shattow
Use LwIP network stack and enable wget HTTP command. The tftpput command is not currently supported by LwIP network stack so remove it. Signed-off-by: E Shattow <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2025-02-20board: starfive: Update the maintainer file for VisionFive 2 boardHal Feng
Update the maintainer file and mark jh7110 / visionfive2 related files with N: patterns. Signed-off-by: Hal Feng <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2025-02-20configs: microchip_mpfs_icicle: set DEFAULT_FDT_FILEHeinrich Schuchardt
Variable $fdtfile needs to be set for automatically loading a device-tree from the ESP or boot partition. * Set CONFIG_DEFAULT_FDT_FILE in the defconfig. * Add $fdtfile to the default environment. Signed-off-by: Heinrich Schuchardt <[email protected]> Reviewed-by: Leo Yu-Chi Liang <[email protected]>
2025-02-19Merge patch series "bloblist: refactor xferlist and bloblist"Tom Rini
Tom Rini <[email protected]> says: This small series separates "bloblist" and "standard passage" to allow for these similar concepts to explore solutions to problems without introduces breaking changes to the other. Link: https://lore.kernel.org/r/[email protected]
2025-02-19bloblist: kconfig for mandatory incoming standard passageRaymond Mao
In previous commit, incoming standard passage is used by default when initializing the bloblist, so explicitly BLOBLIST_PASSAGE is no more needed. Rename it as BLOBLIST_PASSAGE_MANDATORY to determine the behaviors when an incoming transfer list does not exist or is invalid. When it is selected, incoming standard passage is mandatory and U-Boot will report an error when a valid incoming transfer list is missing. Signed-off-by: Raymond Mao <[email protected]>
2025-02-19bloblist: refactor xferlist and bloblistRaymond Mao
Refactor the xferlist to remove the relocating when bloblist passed from the boot args. Refactor bloblist init to use incoming standard passage by default if a valid transfer list exists in the boot args. For bloblist relocation, use the actual total size if it has a smaller BLOBLIST_SIZE_RELOC. Signed-off-by: Raymond Mao <[email protected]> Suggested-by: Ilias Apalodimas <[email protected]>
2025-02-19arm64: dts: rockchip: Fix sdmmc access on rk3308-rock-s0 v1.1 boardsJonas Karlman
BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF. Similarly U-Boot also set PRWEN high before accessing mmc. However, HW revision prior to v1.2 must pull GPIO4_D6 low to access sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact. Model an always-on active low fixed regulator using GPIO4_D6 to fix use of sdmmc on older HW revisions of the board. Fixes: adeb5d2a4ba4 ("arm64: dts: rockchip: Add Radxa ROCK S0") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> [ upstream commit: 26c100232b09ced0857306ac9831a4fa9c9aa231 ] (cherry picked from commit ca8e0bedbc790b19b11efc223677d178b8eeb74e) Signed-off-by: Jonas Karlman <[email protected]>
2025-02-19net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK3588Jonas Karlman
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX and/or TX delay. Currently RX/TX delay is configured as enabled using zero as delay value for the rgmii-rxid/txid/id modes. Change to disable RX and/or TX delay and using zero as delay value. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19net: dwc_eth_qos_rockchip: Fix disable of RX/TX delay for RK356xJonas Karlman
When rgmii-rxid/txid/id phy-mode is used the MAC should not add RX and/or TX delay. Currently RX/TX delay is configured as enabled using zero as delay value for the rgmii-rxid/txid/id modes. Change to disable RX and/or TX delay and using zero as delay value. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19pinctrl: rockchip: rk3328: Fix pinmux for GPIO2-B and GPIO3-B pinsJonas Karlman
The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width, correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is recalculated so it remain unchanged. Add missing GPIO3-B1 to GPIO3-B7 pinmux data to rk3328_mux_recalced_data as mux register offset for these pins does not follow rockchip convention. This matches changes in following Linux commits: - e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins") - 5ef6914e0bf5 ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins") - 128f71fe014f ("pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins") Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: rk3288: Use rk3288-cru.h from dts/upstreamJonas Karlman
clock/rk3288-cru.h in include/dt-bindings is almost identical to the version in dts/upstream, remove the copy from include/dt-bindings to only use the version from dts/upstream. One clk, SCLK_MAC_PLL, is not part of the upstream bindings, this clk is not used by upstream, in-tree or vendor DTs and can safely be dropped. No functional change to board DTs is intended with this removal. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: use OF_UPSTREAM for rk3036Johan Jonker
The device tree for rk3036 combined is now available in the /dts/upstream directory. Use imply OF_UPSTREAM to migrate all rk3036 boards. Reviewed-by: Kever Yang <[email protected]> Signed-off-by: Johan Jonker <[email protected]>
2025-02-19rockchip: sdram: Ensure ram_base is correct in SPLJonas Karlman
Most Rockchip SoCs use 0x0 as DRAM base address, however some SoCs use 0x60000000 and RK3576 use 0x40000000 as DRAM base address. CFG_SYS_SDRAM_BASE is defined with correct address for each SoC and U-Boot proper use this to set correct gd->ram_base in setup_dest_addr(). SPL never assign any value to gd->ram_base and instead use the default, 0x0. Set correct gd->ram_base in dram_init() to ensure its correctness in SPL. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: sdram: Limit usable ram_top to max 4GJonas Karlman
U-Boot only works correctly when it uses RAM below the 4G address boundary on Rockchip SoCs. Limit usable gd->ram_top to max 4G. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: sdram: Allow the first bank to extend beyond 4 GiBJonas Karlman
Allow the first bank to extend beyond 4 GiB when the blob of space for peripheral is located before start of DRAM, e.g. when start of DRAM is 0x40000000 and continue beyond the 4 GiB mark. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: rk3399: grf: Fix enum typos for UART2Chen-Yu Tsai
In the GRF header file, some instances of UART2 pinmux are prefixed with "GRF_UART2DBG" while others have "GRF_UART2DGB". Since UART2 is the default console UART and used for debugging, it is more likely the name should be UART2DBG. Fix the ones that are wrong. Fixes: a2c08df3813b ("pinctrl: add driver for rk3399") Fixes: fa72de10452c ("rockchip: arm64: rk3399: move grf register definitions to grf_rk3399.h") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Reviewed-by: Paul Kocialkowski <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19Revert "rockchip: rk3399: Fix TPL build of bob and kevin"Jonas Karlman
These power rails must be on very early for the U-Boos TPL banner to be show over debug UART. This reverts commit 4576e65a5d6b10fd207c3a44061676ce0220d794. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19rockchip: rk3399-gru: Enable TPL_GPIO for bob and kevinJonas Karlman
The PP1500 and PP3000 power rails must be on very early for the U-Boot TPL banner to be shown on debug UART. Enable TPL_GPIO Kconfig option for bob and kevin to allow use of spl_gpio.h functions in TPL. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19Revert "rockchip: rk3399: Drop unneeded bob and kevin board specific code"Jonas Karlman
These power rails must be on very early for the U-Boos SPL banner to be show over debug UART. This reverts commit af518a1dfe637cb4dc486d7a832585e4a48bc970. Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Kever Yang <[email protected]>
2025-02-19board: verdin-am62: add dram_init_banksizeStefan Eichenberger
Add the dram_init_banksize function to the board file to properly set DRAM memory sizes during boot. The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") relocated the dram_init_banksize function from architecture specific initialization to the TI board initialization code. As a result, boards relying on the previous setup now require this function to be defined within their board file to handle DRAM sizing correctly. Without this function defined the following error appears during boot: ERROR: Failed to allocate 0x1000 bytes below 0x0. Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <[email protected]> Acked-by: Francesco Dolcini <[email protected]>
2025-02-18gpio: pca953x: support pcal6408 and pcal6416Emanuele Ghidoli
Add support to NXP GPIO expanders pcal6408, documented at [1], and pcal6416, documented at [2]. [1] https://www.nxp.com/docs/en/data-sheet/PCAL6408A.pdf [2] https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf Signed-off-by: Emanuele Ghidoli <[email protected]> Signed-off-by: Francesco Dolcini <[email protected]>
2025-02-18net: designware: Add npcm8xx sgmii pcs supportJim Liu
The PCS exists only in GMAC1 and relates to SGMII interface and is used to control the SGMII PHY. Signed-off-by: Jim Liu <[email protected]> [trini: Adjust slightly for white space and to move 'start' to within if block]
2025-02-18board: verdin-am62: add dram_init_banksizeStefan Eichenberger
Add the dram_init_banksize function to the board file to properly set DRAM memory sizes during boot. The commit bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") relocated the dram_init_banksize function from architecture specific initialization to the TI board initialization code. As a result, boards relying on the previous setup now require this function to be defined within their board file to handle DRAM sizing correctly. Without this function defined the following error appears during boot: ERROR: Failed to allocate 0x1000 bytes below 0x0. Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled") Signed-off-by: Stefan Eichenberger <[email protected]> Acked-by: Francesco Dolcini <[email protected]>
2025-02-18board: nuvoton: use an event to replace last_stage_init()Michael Chang
Add a new event which handles this function refer to commit ("91caa3bb89b1 event: Use an event to replace last_stage_init()") Signed-off-by: Michael Chang <[email protected]> Reviewed-by: Tom Rini <[email protected]>
2025-02-18tools: Fix potential null-deref with result of strtok_rMaks Mishin
Return value of a function 'strtok_r' is dereferenced at kwbimage.c:1655 without checking for NULL, but it is usually checked for this function. Signed-off-by: Maks Mishin <[email protected]>
2025-02-18u-boot-initial-env: Add missing dependenciesTom Rini
When performing a build consisting of only a defconfig target and then this tool, we were missing two dependencies. Add them. Signed-off-by: Tom Rini <[email protected]>
2025-02-18fs/erofs: fix an integer overflow in symlink resolutionGao Xiang
See the original report [1], otherwise len + 1 will be overflowed. Note that EROFS archive can record arbitary symlink sizes in principle, so we don't assume a short number like 4096. [1] https://lore.kernel.org/r/20250210164151.GN1233568@bill-the-cat Fixes: 830613f8f5bb ("fs/erofs: add erofs filesystem support") Signed-off-by: Gao Xiang <[email protected]>
2025-02-18led: fix coverity scan errorHeiko Schocher
The following was reported by Covervity scan: *** CID 541279: (TAINTED_SCALAR) /drivers/led/led-uclass.c: 284 in led_get_function_name() 278 if (!ret) { 279 snprintf(uc_plat->name, LED_MAX_NAME_SIZE, 280 "%s:%s-%d", 281 cp ? "" : led_colors[color], 282 func ? func : "", enumerator); 283 } else { >>> CID 541279: (TAINTED_SCALAR) >>> Using tainted variable "color" as an index into an array "led_colors". Fix it. Addresses-Coverity-ID: 541279 (TAINTED_SCALAR) Link: https://lists.denx.de/pipermail/u-boot/2025-February/580250.html Signed-off-by: Heiko Schocher <[email protected]>
2025-02-18tools: use cryptographically safe RNGHeinrich Schuchardt
The PRNG implementing the random() function only has 2^31 states and therefore is unsafe to use for cryptography. Use arc4random() instead. Fixes: cc34f04efd63 ("tools: image-host.c: use random instead of rand") Addresses-Coverity-ID: 312953 Calling risky function Signed-off-by: Heinrich Schuchardt <[email protected]>
2025-02-18power: regulator: tps65941: Fix voltage calculation for ldoUdit Kumar
As per TRM[0] Section 8.7.1 "TPS6594-Q1 Registers", LDOx_Vout bit 6-1, define the NVM voltage settings. Along side table 8-4 of above TRM, shows voltage to value mapping. Driver wrongly using bits 5-1 to calculate voltage, and to convert voltage to value driver was using buck's calculation. So fix those calculation. [0]: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf Fixes: 5d7dbd22cf7d ("power: regulator: tps65941: use function callbacks for conversion ops") Signed-off-by: Udit Kumar <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2025-02-18tpm: unconstify tpm_tis_chip_dataIlias Apalodimas
The struct contains an iomem pointer that we later remap and update. Remove const from the struct definition. Signed-off-by: Ilias Apalodimas <[email protected]>
2025-02-18Merge tag 'u-boot-at91-2025.07-a' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-at91 into next First set of u-boot-at91 features for the 2025.07 cycle: This feature set includes improvements on the atmel-quadspi driver, a fix for the nand driver, and improvements on the pinctrl driver to be able to use the Linux DT (also sync on the DT side as well).
2025-02-17u_boot_pylib: Move gitutil into the librarySimon Glass
Move this file into U-Boot's Python library, so that it is no-longer part of patman. This makes a start on: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/35 Signed-off-by: Simon Glass <[email protected]>
2025-02-17Gitlab: Add missing symlink for qemu_arm64_lwip boardenv fileTom Rini
When adding the symlink for the conf file so qemu_arm64_lwip uses qemu_arm64 configuration information, the symlink for the boardenv file was missed in Gitlab (but not Azure). Add that in now. Fixes: fd10d156db3f ("CI: add qemu_arm64_lwip to the test matrix") Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2025-02-16board: acer: picasso: add Acer Iconia Tab A500 supportSvyatoslav Ryhel
The Acer Iconia A500 is a tablet computer designed, developed and marketed by Acer Inc. It is powered by 1 GHz Nvidia Tegra 2 processor and 1GB DDR2 RAM. The A500 is sold with 64 GB, although both 16 GB and 32 GB models are available. Signed-off-by: Svyatoslav Ryhel <[email protected]>
2025-02-15Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-shTom Rini
Add empty weak assembler function armv8_switch_to_el2_prep() which is jumped to just before U-Boot determines which EL it is running in and decides which path to take to boot the Linux kernel. Add IH_TYPE_TFA_BL31 into supported images type, to allow implementation of board specific U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, ...) TFA BL31 loadable handler for fitImages. This PR contains common hooks which are noop, R-Car Gen4 board specific implementation using these hooks is coming in next PR.
2025-02-15image: Add support for starting TFA BL31 as fitImage loadablesMarek Vasut
Add support for starting TFA from U-Boot running in EL3 as part of fitImage boot, so the user can start U-Boot in the highest privilege level on the platform, bundle TFA, Linux, DT into a single fitImage and boot such a bundle as a whole. There are two main benefits of this approach. First is the ability to run U-Boot in EL3, where it has unrestricted access to the entire system and can act as a useful debug tool, as it was always intended to be used. Second is the ability to easily and safely update of any component in the fitImage, be it TFA, Linux or DT. The boot process is similar to regular Linux with DT fitImage boot process, except the TFA has to be bundled into the fitImage. For the bundling instructions, see below. The TFA is started as a 'loadables' with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep() handling implemented in board code, and performing the handoff and boot in case the TFA was loaded. The loadables handler is optional and meant to set up any sort of handoff structures used by the TFA BL31 or perform any other setup that is needed by the blob. The custom armv8_switch_to_el2_prep() has to implement the jump to TFA BL31 with return to U-Boot just before booting the Linux kernel. Example fitImage image and configuration section: /dts-v1/; / { description = "Linux kernel with FDT blob and TFA BL31"; images { kernel-1 { ... }; fdt-1 { ... }; atf-1 { /* This is the TFA BL31 image */ description = "TFA BL31"; data = /incbin/("../build/plat/release/bl31.bin"); type = "tfa-bl31"; arch = "arm64"; os = "arm-trusted-firmware"; compression = "none"; load = <0x46400000>; entry = <0x46400000>; }; }; configurations { default = "conf-1"; conf-1 { description = "Boot Linux"; kernel = "kernel-1"; fdt = "fdt-1"; loadables = "atf-1"; /* This is the TFA BL31 loadable */ }; }; }; Reviewed-by: Tom Rini <[email protected]> Signed-off-by: Marek Vasut <[email protected]>
2025-02-15arm64: Add late jump to kernel board hookMarek Vasut
Add empty weak assembler function armv8_switch_to_el2_prep() which is jumped to just before U-Boot determines which EL it is running in and decides which path to take to boot the Linux kernel. This weak function is meant to be used by architecture specific code to implement jump to a firmware blob, which then returns right past this weak function and continues execution of U-Boot code which then boots the Linux kernel. One example of such use case is when U-Boot jump tp TFA BL31, which switches from EL3 to EL2 and then returns to U-Boot code newly running in EL2 and starts the Linux kernel. The weak function is called with caches already disabled and DM shut down. Any preparatory work or even loading of more data must be done in board_prep_linux(), this hook is meant only for the final jump to the firmware and return to U-Boot before booting Linux. Reviewed-by: Tom Rini <[email protected]> Signed-off-by: Marek Vasut <[email protected]>
2025-02-14spi: soft_spi: Add support for SPI_3WIREHironori KIKUCHI
When 3-wire mode is claimed on the bus, use the MOSI (output) pin to receive data. In this mode, since the transfer can only be either TX or RX, return -EINVAL if both are required at the same time. Signed-off-by: Hironori KIKUCHI <[email protected]>
2025-02-14Merge patch series "Rework requirements.txt files"Tom Rini
Tom Rini <[email protected]> says: A challenge we've run in to is making it easier for more people to use various python tools that we include in the tree. Part of the problem is that when we have a requirements.txt file, aside from the doc one we share with the kernel, I created it using "pip freeze". And while this might have been a best (or at least OK) practice at the time, that's no longer the case and is why our files have so many things in them. What this series does is create multiple files, one per project/tool and then has CI install them as needed. There's a few places here where this means that we update the requirements as well, but we keep a few big things where they are currently. This is because updating them introduces problems of their own and delaing with that would best be a follow up series. I've put this through GitLab and Azure to make sure everything is still going fine on both platforms. Link: https://lore.kernel.org/r/[email protected]
2025-02-14Dockerfile: Update for having more requirements.txt filesTom Rini
Now that we have more requirements.txt files we need to grab all of them for creating our cache. Also, we do longer should install python3-pyelftools on the host as it's not used. Signed-off-by: Tom Rini <[email protected]>
2025-02-14python: Recreate test/py and tools/buildman requirements.txt filesTom Rini
Use the "pipreqs" tool to re-create these files, with a few manual corrections. We still need to include pytest-xdist which the tool does not detect. We also for now don't upgrade most of the required tools as that creates problems with various tests, which should be resolved independently. Signed-off-by: Tom Rini <[email protected]>
2025-02-14CI: Invoke pip once rather than multiple timesTom Rini
We can invoke pip once to install the various requirements.txt files that we need rather than invoking the tool multiple times. Signed-off-by: Tom Rini <[email protected]>
2025-02-14CI: Consistently install our requirements.txt filesTom Rini
We should install all of our requirements.txt files after starting the virtualenv rather than ad-hoc throughout each test. Signed-off-by: Tom Rini <[email protected]>
2025-02-14CI: Be consistent in creating and starting our virtualenvTom Rini
Before we invoke pip we should always have first created and started our virtualenv. This was done most of the time, but not always. Signed-off-by: Tom Rini <[email protected]>
2025-02-14python: Create requirements.txt files for each "project"Tom Rini
Rather than have a requirements.txt file that's shared between multiple python projects within U-Boot, create one for each using "pipreqs". Signed-off-by: Tom Rini <[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]>
2025-02-14Merge patch series "Introduce K3 remoteproc driver for M4 subsystem"Tom Rini
Judith Mendez <[email protected]> says: Some K3 devices like am62x and am64x have a M4 processor in the MCU voltage domain. This patch series introduces remoteproc M4 driver which will be used to load firmware into and start the M4 remote core. This series also adds support for R5F cores on am64x SoCs in patch 2 and sets up environment to load FW in remote cores in patch 3,4,5. This patch series also enables remoteproc drivers by default as per what remoteproc sybsystem is supported per SoC, thus all remoteproc options are now deleted in configs/* since they are no longer required. This patch series was tested on am64x EVM, am62x SK, am62ax SK, am62px SK boards. Any additional tested by's are welcome since I was not able to test any additional boards. Tested by running the following commands in u-boot prompt: => setenv dorprocboot 1 => run boot_rprocs Link: https://lore.kernel.org/r/[email protected]
2025-02-14configs: am6*/j7*: Remove remoteproc configsJudith Mendez
Now that remoteproc configs are enabled by default in Kconfig files, remove these configs which are no longer needed to be defined here in configs/. Signed-off-by: Judith Mendez <[email protected]> Reviewed-by: Andrew Davis <[email protected]>