The generic SDHCI driver transfers via 32-bit SDMA or 32-bit ADMA2 descriptors, so on boards whose ram_top marks the DMA-addressable boundary, LMB must not place images above it: a later load from MMC into such a buffer could not be DMAed. Imply the limit like other drivers with the same constraint do.
The option keys off ram_top, so it only takes effect where ram_top is at or below the boundary. A board whose RAM extends past 4 GiB has to clamp ram_top first; for qemu_arm64 that is the patch linked below. Link: https://lore.kernel.org/r/20261026-upstream-u-boot_qemu_arm_b4-v1-1-223dd8060...@oss.qualcomm.com Suggested-by: Tom Rini <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]> --- Split out of the review of the qemu-arm 4 GiB fix, where Tom Rini suggested it: https://lore.kernel.org/r/20261026-upstream-u-boot_qemu_arm_b4-v1-1-223dd8060...@oss.qualcomm.com It does not depend on that patch. Tested on qemu_arm64 with -m 6144 (TF-A + OP-TEE + U-Boot, Android bootflow from an sdhci-pci eMMC) on top of it: relocaddr stays just below 4 GiB, the eMMC probes, the bootflow is found and the "lmb" listing shows all RAM above 4 GiB reserved. --- drivers/mmc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index b3731dfe4a1..6f732de8a8d 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -503,6 +503,7 @@ config MMC_SANDBOX config MMC_SDHCI bool "Secure Digital Host Controller Interface support" + imply LMB_LIMIT_DMA_BELOW_RAM_TOP help This selects the generic Secure Digital Host Controller Interface. It is used by manufacturers such as Texas Instruments(R), Ricoh(R) --- base-commit: 559080348aee1da59de83dc32aaeedf4250279e6 change-id: 20261027-upstream-mmc_sdhci_lmb_b4-5fbe2de5a4bb Best regards, -- Igor Opaniuk <[email protected]>
