Introduces support for Device Firmware Upgrade (DFU) over PCIe in U-Boot. Traditionally, the DFU protocol is used over USB, where a device enters DFU mode and allows a host to upload firmware or binary images directly via the USB interface. This is a widely adopted and convenient method for updating firmware. In the context of Texas Instruments (TI) SoCs, PCIe can be used as a boot interface in a manner that differs from the conventional "PCIe Boot" process, which typically refers to booting an OS or firmware image from an NVMe SSD or other PCIe-attached storage devices. Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a connected PCIe Root Complex (host) to transfer images directly into the device’s memory over the PCIe bus for boot purposes. This mechanism is analogous to DFU over USB, but leverages the high-speed PCIe link and does not depend on traditional storage devices. By extending the DFU framework in U-Boot to support PCIe, it will be possible to flash images over PCIe. While this implementation is motivated by TI SoC use cases, the framework is generic and can be adopted by everyone for platforms that support PCIe Endpoint mode. Platforms with hardware support for PCIe-based memory loading can use this to implement PCIe as a boot mode, as well as to enable flashing and recovery scenarios similar to DFU over USB. In summary, enable support for: - DFU-style flashing of firmware/images over PCIe, analogous to existing USB DFU workflows - PCIe as a boot mode where a host can load images directly into device memory using DFU over PCIe Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Add new i3c driver to U-Boot drivers. Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
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 <trini@konsulko.com>
Add config required to build mmio-mux driver and dependencies. Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass <sjg@chromium.org>
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <sjg@chromium.org>
What model of Radxa ZERO 3W/3E board can be identified using ADC at runtime, add a Kconfig symbol to allow use of ADC in SPL. This will be used to identify board model in SPL to allow loading correct FIT configuration and FDT for U-Boot proper at SPL phase. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add SPL variant of DM_RNG so that the DM_RNG can be disabled in SPL if necessary. This may be necessary due to e.g. size constraints of the SPL. Signed-off-by: Marek Vasut <marex@denx.de>
The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the same DRAM initialisation code. Make use of prior art here and lift some code from awboot[1], which carried init code based on earlier decompilation efforts, but with a GPL2 license tag. This code has been heavily reworked and cleaned up, to match previous DRAM routines for other SoCs, and also to be closer to U-Boot's coding style and support routines. The actual DRAM chip timing parameters are included in the main file, since they cover all DRAM types, and are protected by a new Kconfig CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only the relevant settings, at build time. The relevant DRAM chips/board specific configuration parameters are delivered via Kconfig, so this code here should work for all supported SoCs and DRAM chips combinations. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Sam Edwards <CFSworks@gmail.com>