summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-12-18mmc: snps_sdhci: Add sdhci driver support for TH1520 SoCMaksim Kiselev
Add support for DesignWare SDHCI host controller on Alibaba TH1520 SoC Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-12-18riscv: cpu: jh7110: Sort the list of imply statementsHal Feng
The imply statements should be sorted in the sequence of appearance in .config. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18board: starfive: spl: Support multiple DTBs for JH7110 based boardsHal Feng
Get product ID and the other information from EEPROM, use them to select the correct DTB. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18board: starfive: spl: Fix the wrong use of CONFIG_IS_ENABLED()Hal Feng
The prefix "SPL_" is not needed when using CONFIG_IS_ENABLED(). Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Fixes: 5ecf9b0b8a75 ("board: starfive: add StarFive VisionFive v2 board support") Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18riscv: dts: jh7110: Support multiple DTBs in a Fit imageHal Feng
Support multiple DTBs for JH7110 based boards, so they can select the correct DT at runtime. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: E Shattow <lucent@gmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18configs: visionfive2: Enable MULTI_DTB_FIT for JH7110 based board DTHal Feng
So JH7110 based boards can select their own DT at runtime. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: E Shattow <lucent@gmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18board: starfive: spl: Drop the unneeded DT modification codeHal Feng
As OF_UPSTREAM is implemented, these code are redundant. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18riscv: dts: jh7110: Add u-boot device tree for JH7110 based boardsHal Feng
To support the other JH7110 based boards, add u-boot device tree for them. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: E Shattow <lucent@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: H Bell <dmoo_dv@protonmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18riscv: dts: jh7110: Move common code to the new jh7110-common-u-boot.dtsiHal Feng
To support JH7110 based boards besides v1.3B, add a common dtsi and add common code to it. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: E Shattow <lucent@gmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18pcie: starfive: Make the driver compatible with upstream DTHal Feng
There are difference between upstream DT and the old DT in terms of reg base, reset gpio and syscon. Make the driver compatible with upstream DT. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18mmc: dw_mmc: Add "starfive, jh7110-mmc" compatible to match upstream DTHal Feng
Make the U-Boot JH7110 MMC driver compatible with upstream DT. Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18riscv: dts: jh7110: Make u-boot device trees adapting to upstream DTHal Feng
Add u-boot features to the U-Boot device tree. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Reviewed-by: E Shattow <lucent@gmail.com> Acked-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18dts: starfive: Switch to using upstream DTHal Feng
Enable OF_UPSTREAM to use upstream DT and add starfive/ prefix to the DEFAULT_DEVICE_TREE. Rename jh7110-starfive-visionfive-2-u-boot.dtsi to jh7110-starfive-visionfive-2-v1.3b-u-boot.dtsi and set the v1.3b device tree as the default device tree. Drop redundant DT files from arch/riscv/dts/ and redundant clock and reset definitions from include/dt-bindings/. Since the old clock definitions is a little different from those in upstream Linux, update the clock definitions in clock drivers accordingly. Tested-by: Anand Moon <linux.amoon@gmail.com> Tested-by: E Shattow <lucent@gmail.com> Acked-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
2024-12-18board: add support for LicheeRV NanoThomas Bonnefille
The LicheeRV Nano is a small SBC using the Sophgo SG2002 RISCV SoC. Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
2024-12-18riscv: dts: sophgo: add device tree for LicheeRV NanoThomas Bonnefille
Import a slightly modified version of the LicheeRV Nano and SG2002 device trees from the Linux Kernel. The current supported IPs are UART, MMC, Timer, PLIC and CLINT. Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com>
2024-12-18doc: add LicheeRV Nano and SG2002 SoCThomas Bonnefille
Provide a page describing the usage of U-Boot on the LicheeRV Nano and a description of the board. Signed-off-by: Thomas Bonnefille <thomas.bonnefille@bootlin.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2024-12-15smbios: address build warningPeng Fan
include display_options.h to address build warning: lib/smbios.c: In function ‘smbios_update_version’: lib/smbios.c:305:9: warning: implicit declaration of function ‘print_buffer’ [-Wimplicit-function-declaration] print_buffer((ulong)ptr, ptr, 1, old_len + 1, 0); ^~~~~~~~~~~~ Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-12-15arm: mach-k3: fix typo in devstat macro namePrasanth Babu Mantena
Fix spelling mistake in the board init files of j721e and j721s2. s/WKUP_DEVSTAT_MCU_OMLY_MASK/WKUP_DEVSTAT_MCU_ONLY_MASK Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
2024-12-15bios_emulator: fix incorrect printing of address in "jump near immediate"Yuri Zaporozhets
In the x86emuOp_jump_call_near_IMM() function the target address is printed incorrectly when jumping backwards. For example instead of "jmp 0xe8bc" the string "jmp ffffe8bc" is printed. That's because of the following macro: DECODE_PRINTF2("%04x\n", ip); while it should be DECODE_PRINTF2("%04x\n", (u16)ip); Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
2024-12-15bios_emulator: fix incorrect printing of address in "call near immediate"Yuri Zaporozhets
In the x86emuOp_call_near_IMM() function the address of CALL is printed incorrectly when jumping backwards. For example, the correct disassemble of the bytes below would be: 0000E8DE E8DBFF call 0xe8bc (verified by ndisasm). But instead the address is printed as "ffffe8bc". That's because of the following macro: DECODE_PRINTF2("%04x\n", ip); while it should be DECODE_PRINTF2("%04x\n", (u16)ip); Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
2024-12-15bios_emulator: fix garbled printing of disassembled SET* instructionsYuri Zaporozhets
When DEBUG_DECODE_F is enabled in bios_emulator, the printing of SET{O,NO,B,NB,Z,NZ,BE,NBE,S,NS,P,TP,L,NL,LE,NLE} instructions is not followed by newline and is, therefore, immediately followed by the printed address of a new instruction. This garbles the output and makes it very difficult to read. This patch adds missing DECODE_PRINTF("\n") calls to print newlines. Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
2024-12-15bios_emulator: fix garbled printing of disassembled BSF instructionYuri Zaporozhets
When DEBUG_DECODE_F is enabled in bios_emulator, the printing of BSF instructions is garbled because the '\n' symbol is used instead of the correct '\t'. Fix that. Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
2024-12-14Merge patch series "Hyperflash Boot fixes for J7200/J721E"Tom Rini
Anurag Dutta <a-dutta@ti.com> says: Hi All, In u-boot, hbmc is broken and has been removed from j7200 configs. This series re-enables the hbmc driver and introduces a series of hyperflash boot fixes. At present, in u-boot, the parent device (fss) gets registered as a syscon device. This is done because the MMIO mux driver in u-boot did not support the mux functionality when the parent device is not a syscon. In this series, we make relevant changes in the hbmc driver as well as dts' so that we can use the reg-mux driver for selecting the appropriate state of the mux. Test logs: 1) j721e-idk-gw hyperflash boot test: https://gist.github.com/anuragdutta731/50aae6fec707a3ffad6d985de6757fe4 2) j7200-evm hyperflash boot test: https://gist.github.com/anuragdutta731/c3a4d60f8bfd9c425d6c44b36eb7322b Link: https://lore.kernel.org/r/20241129113136.383277-1-a-dutta@ti.com
2024-12-14mtd: Kconfig: Change HBMC driver's dependency to MULTIPLEXER and MUX_MMIOAnurag Dutta
The HBMC_AM654 driver was dependent on SYSCON because syscon APIs were being used to select the multiplexer state. Change the dependency to MULTIPLEXER and MUX_MMIO because mux APIs are now being used to select mux state. Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14configs: j7200_evm_*_defconfig: Add configs for Hyperflash bootVaishnav Achath
Kernel commit dbb124cf6888 ("configs: j7200: Remove HBMC_AM654 config") removed the HBMC_AM654 config because hbmc was broken in u-boot. Hence, add the missing configs necessary to re-enable Hyperflash boot. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14include: configs: j721e_evm: Increase memory offset for tiboot3.bin in ↵Aswath Govindraju
HyperFlash The size of J7200 tiboot3.bin is 516KB but the memory reserved for it in HyperFlash was 512KB. This led to overlap of tiboot3.bin over tispl.bin region and break in HyperFlash boot mode. Therefore, fix this by increasing the memory allocated for tiboot3.bin to 1MB for J7200. Fixes: cf1d6867f774 ("board: ti: j7200: Introduce support for j7200 build targets") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14configs: j721e_evm_*_defconfig: Add configs for Hyperflash bootVaishnav Achath
Kernel commit 5b2671594b80 ("configs: j721e: Remove HBMC_AM654 config") removed the HBMC_AM654 config because hbmc was broken in u-boot. Hence, add the missing configs necessary to re-enable Hyperflash boot. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14arm: dts: k3-j721e-r5-common: Add HBMC overrides for R5 SPLVaishnav Achath
Add 32-bit address overrides for Hyper Bus Memory Controller for Hyperflash to be functional in R5 SPL. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14arm: dts: k3-j7200-r5-common: Add HBMC overrides for R5 SPLVaishnav Achath
Add 32-bit address overrides for Hyper Bus Memory Controller for Hyperflash to be functional in R5 SPL. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14mtd: HBMC-AM654: Changed syscon API to mux APIsAnurag Dutta
The syscon APIs were used for selecting the state of the mux device because the mmio-mux driver in u-boot did not support the mux functionality when the parent device is not a syscon. Change to mux APIs which utilizes the reg-mux driver to select the state of the multiplexer. Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14mux: Makefile: Add config for mux driversAnurag Dutta
Add config required to build mmio-mux driver and dependencies. Signed-off-by: Anurag Dutta <a-dutta@ti.com>
2024-12-14Merge patch series "configs: Enable CMD_NFS by default"Tom Rini
Neha Malcom Francis <n-francis@ti.com> says: Enable the NFS command across all platforms to allow network booting via the NFS. Clean up the J7 configs to use TI_COMMON_CMD_OPTIONS. Link: https://lore.kernel.org/r/20241129110333.444270-1-n-francis@ti.com
2024-12-14configs: j7*: Enable TI_COMMON_CMD_OPTIONSNeha Malcom Francis
Instead of bloating the defconfig with CONFIG_CMD_*, move J7 devices to start using TI_COMMON_CMD_OPTIONS. Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
2024-12-14board: ti: common: Kconfig: Add CMD_NFSNeha Malcom Francis
Add CMD_NFS to list of configs implied by CONFIG_TI_COMMON_CMD_OPTIONS. This allows network booting via the NFS protocol from the U-Boot prompt. Fixes: 10de12570799 ("disable NFS support by default") Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
2024-12-14Merge patch series "UART support for higher baudrate"Tom Rini
Gokul Praveen <g-praveen@ti.com> says: The OMAP specific UART driver is changed from a generic implementation of certain ops functions to an OMAP specific implementation of it to add support for higher baudrates for OMAP devices. Hence to support the above change, static functionality of ops functions in generic ns16550 UART U-Boot driver is removed and also migrated certain macros to its header file for usage in device-specific drivers. Boot logs link : https://gist.github.com/GOKU-THUG/8b90117c963e5da5c1b6caeee427c82c Link: https://lore.kernel.org/r/20241126105131.43359-1-g-praveen@ti.com
2024-12-14drivers: serial: serial_omap: Fix TI OMAP UART U-Boot driver to support ↵Gokul Praveen
higher baudrates Move to OMAP specific implementation of certain ops functions as the UART prints on the serial console fail for baudrates greater than 460800. The MDR1 register is responsible for determining the speed mode at which the UART should operate for OMAP specific devices. The baud divisor is used to set the UART_DLL register which is used for generation of the baud clock in the baud rate generator. The implementation logic is similar to how it is implemented in omap_8250_get_divisor function of 8250_omap UART linux driver. Signed-off-by: Gokul Praveen <g-praveen@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-12-14serial: ns16550: Increase scope of ops functionsGokul Praveen
Increase scope of ops functions and do some clean up for usage in device -specific UART drivers. Remove the static functionality of ops functions and migrate certain macros to header file for usage in device-specific drivers. Signed-off-by: Gokul Praveen <g-praveen@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-12-13Merge patch series "Add phyCORE AM62Ax"Tom Rini
Garrett Giordano <ggiordano@phytec.com> says: This patch set adds the phyCORE AM62Ax board support and documenation to u-boot. The phyCORE-AM62Ax is a SoM (System on Module) featuring TI's AM62Ax SoC. It can be used in combination with different carrier boards. This module can come with different sizes and models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM62x family. A development Kit, called phyBOARD-Lyra is used as a carrier board reference design around the AM62x SoM. This series depends on the following two patches: - [PATCH v2] arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPL https://lists.denx.de/pipermail/u-boot/2024-October/570156.html - [PATCH] board: phytec: common: Introduce CONFIG_PHYTEC_K3_DDR_PATCH https://lists.denx.de/pipermail/u-boot/2024-November/571543.html Link: https://lore.kernel.org/r/20241118231606.3161665-1-ggiordano@phytec.com [trini: Fix warning in board/phytec/common/k3/board.c when CONFIG_EFI_HAVE_CAPSULE_SUPPORT is not enabled] Signed-off-by: Tom Rini <trini@konsulko.com>
2024-12-13arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPLsGarrett Giordano
Introduce get_boot_device() to obtain the booting device. Make it also available for non SPL builds so u-boot can also know the device it is booting from. Signed-off-by: Garrett Giordano <ggiordano@phytec.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
2024-12-13toradex: tdx-cfg-block: rework modules pid4 handlingVitor Soares
The module pid4 currently corresponds to the index of the toradex_module array. If a new pid4 is introduced that does not follow the sequence of the previous entries, it will create a gap in the array. To address this, embed pid4 within the toradex_som structure and implement a function to retrieve the index corresponding to pid4. Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
2024-12-13doc: board: phytec: Add phyCORE-AM62axGarrett Giordano
Add documentation for PHYTEC phyCORE-AM62ax SoM. Signed-off-by: Garrett Giordano <ggiordano@phytec.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Dhruva Gole <d-gole@ti.com>
2024-12-13board: phytec: am62a7: Add PHYTEC phyCORE-AM62A7 SoMGarrett Giordano
Add support for PHYTEC phyCORE-AM62A7 SoM. Supported features: - 2GB LPDDR4 RAM - eMMC - External SD - Ethernet - debug UART Signed-off-by: Garrett Giordano <ggiordano@phytec.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Bryan Brattlof <bb@ti.com>
2024-12-13Merge patch series "Enable EFI capsule updates for PHYTEC K3 SoMs"Tom Rini
Wadim Egorov <w.egorov@phytec.de> says: This implements capsule updates for all our K3 SoMs for eMMC, OSPI NOR and uSD cards. We can use capsule updates to update the bootloader on all our supported flash devices. Link: https://lore.kernel.org/r/20241127121736.1525948-1-w.egorov@phytec.de
2024-12-13configs: phycore_am6*_a53_defconfig: Enable capsule updateWadim Egorov
Enable raw & on disk capsule updates and provide configs required for updating MTD devices. Also resync after savedefconfig. Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
2024-12-13board: phytec: k3: Add EFI capsule update supportWadim Egorov
Implement EFI capsule update functionality for PHYTEC K3-based SoMs. These SoMs feature various flash device options, including eMMC, OSPI NOR, and uSD card at the board level. This update provides the necessary logic to enable EFI capsule updates across all three flash devices, ensuring flexible and robust firmware upgrade capabilities. The GUID is dynamically generated for the board, to get it: efidebug capsule esrt ======================================== ESRT: fw_resource_count=3 ESRT: fw_resource_count_max=3 ESRT: fw_resource_version=1 [entry 0]============================== ESRT: fw_class=C7D64D6D-10B2-54BC-A3BF-06A9DC3653D9 ESRT: fw_type=unknown ESRT: fw_version=0 ESRT: lowest_supported_fw_version=0 ESRT: capsule_flags=0 ESRT: last_attempt_version=0 ESRT: last_attempt_status=success [entry 1]============================== ESRT: fw_class=09841C3F-F177-5D57-B1F6-754D92879205 ESRT: fw_type=unknown ESRT: fw_version=0 ESRT: lowest_supported_fw_version=0 ESRT: capsule_flags=0 ESRT: last_attempt_version=0 ESRT: last_attempt_status=success [entry 2]============================== ESRT: fw_class=D11A9016-515E-503A-8872-3FF65384D0C4 ESRT: fw_type=unknown ESRT: fw_version=0 ESRT: lowest_supported_fw_version=0 ESRT: capsule_flags=0 ESRT: last_attempt_version=0 ESRT: last_attempt_status=success ======================================== On the board (from uSD card containing capsule binaries at boot): load mmc 1:1 $loadaddr tiboot3-capsule.bin efidebug capsule update $loadaddr load mmc 1:1 $loadaddr tispl-capsule.bin efidebug capsule update $loadaddr load mmc 1:1 $loadaddr uboot-capsule.bin efidebug capsule update $loadaddr The binaries will be flashed to the flash device you are booted from. Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
2024-12-13arm: dts: k3-am642-phycore-som-binman: Provide capsule nodesWadim Egorov
Fill in phycore-am64x capsule GUID properties of the base binman capsule nodes. Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
2024-12-13arm: dts: k3-am625-phycore-som-binman: Provide capsule nodesWadim Egorov
Fill in phycore-am62x capsule GUID properties of the base binman capsule nodes. Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
2024-12-13Merge patch series "AM62A DWC3: Add support for USB DFU boot in OTG mode"Tom Rini
Siddharth Vadapalli <s-vadapalli@ti.com> says: Hello, This series adds support for USB DFU boot on TI's AM62A SoC which has two instances of DWC3 USB Controllers namely USB0 and USB1. The USB0 instance of the USB Controller supports USB DFU boot: ROM => tiboot3.bin => tispl.bin => u-boot.img USB DFU Boot requires the USB Controller to be configured for Gadget mode of operation. Since the USB0 instance of the DWC3 USB Controller supports both Host and Gadget modes of operation via the Type-C interface on the AM62A7-SK board, the device-tree specifies the "dr_mode" as "OTG". However, there is currently no support for dynamically switching the "mode" from Host to Gadget and vice-versa with the help of a state-machine. The OTG mode is treated as a separate mode in itself rather than being treated as an intermediate stage before assuming the Host/Gadget mode. Due to this, USB DFU boot via the Type-C interface doesn't work as the USB Controller hasn't been appropriately configured for Device/Gadget mode of operation. One option is to change the device-tree to specify "dr_mode" as "peripheral" and force the controller to assume the Device role. This will imply that the U-Boot device-tree for AM62A diverges from its Linux counterpart. Therefore, with the intent of keeping the device-tree uniform across Linux and U-Boot, and at the same time, in order to enable USB DFU boot in "OTG" mode with the DWC3 Controller, the first patch in this series sets the "mode" on the basis of the caller function, rather than using the "dr_mode" property in the device-tree. There are only two callers of "dwc3_generic_probe()", each of which clearly specify the expected mode of configuration. This will enable both Host and Device mode of operation based on the command executed by the user, thereby truly supporting "OTG" functionality when the USB Controller supports it. The second patch in this series adds USB DFU environment for AM62A, enabling USB DFU Boot and USB DFU flash on AM62A. In addition to the patches in this series, the following device-tree changes will be required to test USB DFU on AM62A (bootph-all property to be added to ensure that USB Controller is present at all stages for DFU Boot): https://gist.github.com/Siddharth-Vadapalli-at-TI/53ba02cb0ff4a09c47e920d08247065f The above device-tree changes will be made to the Linux device-tree, which shall ensure that the same shall be a part of U-Boot device-tree eventually. The USB DFU config fragments for AM62x have been used for enabling USB DFU boot on AM62a as follows: R5 => am62ax_evm_r5_defconfig + am62x_r5_usbdfu.config A53 => am62ax_evm_a53_defconfig + am62x_a53_usbdfu.config Logs validating USB DFU boot with this series: https://gist.github.com/Siddharth-Vadapalli-at-TI/daa71da1b0e478a51afea42605fb2d2c Link: https://lore.kernel.org/r/20241126120322.1760862-1-s-vadapalli@ti.com
2024-12-13board: ti: am62ax: env: include environment for DFUSiddharth Vadapalli
Include the TI K3 DFU environment to support DFU Boot and DFU Flash. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org>
2024-12-13usb: dwc3-generic: set "mode" based on caller of dwc3_generic_probe()Siddharth Vadapalli
There are only two callers of "dwc3_generic_probe()", namely: 1. dwc3_generic_peripheral_probe() 2. dwc3_generic_host_probe() Currently, the "mode" is set based on the device-tree node of the platform device. Also, the DWC3 core doesn't support updating the "mode" dynamically at runtime if it is set to "OTG", i.e. "OTG" is treated as a separate mode in itself, rather than being treated as a mode which should eventually lead to "host"/"peripheral". Given that the callers of "dwc3_generic_probe()" clarify the expected "mode" of the USB Controller, use that "mode" instead of the one specified in the device-tree. This shall allow the USB Controller to function both as a "Host" and as a "Peripheral" when the "mode" is "otg" in the device-tree, based on the caller of "dwc3_generic_probe()". Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Roger Quadros <rogerq@kernel.org>