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>
Rather than having every caller set this up individually, create a common init function. This allows new fields to be added without the risk of them being left uninited. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from all "commmon/" files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
Aligning addresses and sizes causes overhead which is unnecessary when we are not loading from block devices. Remove bl_len when it is not needed. For example, on iot2050 we save 144 bytes with this patch (once the rest of this series is applied): add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-144 (-144) Function old new delta spl_load_simple_fit 920 904 -16 load_simple_fit 496 444 -52 spl_spi_load_image 384 308 -76 Total: Before=87431, After=87287, chg -0.16% We use panic() instead of BUILD_BUG_ON in spl_set_bl_len because we still need to be able to compile it for things like mmc_load_image_raw_sector, even if that function will not be used. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
This CONFIG is used but is not given a value by some boards. Use a default value of 0 explicitly, rather than relying on the 0 value provided by CONFIG_SPL_LOAD_FIT_ADDRESS This will allow us to make SPL_LOAD_FIT_ADDRESS depend on SPL_LOAD_FIT as it should. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Update my and DPs email address to match current setup. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/aba5b19b9c5a95608829e86ad5cc4671c940f1bb.1688992543.git.michal.simek@amd.com
Instead of always retuning success, return actual result of load_simple_fit_image or spl_parse_image_header, otherwise we might end up jumping on uninitialized spl_image->entry_point. Signed-off-by: Nikita Shubin <n.shubin@yadro.com> Reviewed-by: Stefan Roese <sr@denx.de>
We ask for CONFIG_SPL_LOAD_FIT_ADDRESS in Kconfig, so we cannot define it in C as a fall-back. However, this option previously was buried under "if ... endif" Kconfig logic. Rework a number of config options to now have more robust dependency lines so that we can ask this address when needed. With that done, we can remove the fallback in spl_ram.c. Signed-off-by: Tom Rini <trini@konsulko.com>