Hi Tom, On Mon, Oct 26, 2026 at 8:18 PM Tom Rini <[email protected]> wrote: > > On Mon, Oct 26, 2026 at 07:44:50PM +0100, Igor Opaniuk wrote: > > > U-Boot relocates itself and its heap to the top of RAM. On the QEMU > > virt machine that is fine with -m 3072 and below, where RAM ends at or > > under the 4 GiB boundary, but with more memory (e.g. -m 6144) U-Boot > > ends up around 7 GiB. Every buffer it then hands to a DMA engine that > > is limited to 32-bit addresses is unreachable by the device. > > > > The generic SDHCI driver is such a consumer: it transfers via 32-bit > > SDMA or 32-bit ADMA2 descriptors. With an emulated sdhci-pci eMMC on > > the virt machine and 6 GiB of RAM, card initialization data transfers > > fail silently, the MMC block device never probes, and bootstd finds no > > bootflow on the eMMC: autoboot drops to the prompt with an empty 'pci' > > listing as the only visible symptom (enumeration not yet run), while > > 'dm tree' after a manual 'pci enum' shows the controller bound but the > > blk child never probed. > > > > Clamp the usable RAM top to 4 GiB like other boards with 32-bit DMA > > constraints do, so U-Boot and its buffers stay DMA-addressable however > > much memory the VM is given. The OS still sees and uses all of it. > > > > Fixes: f37770c7707b ("ARM: qemu-arm: Bump RAM size in AArch64 MMU table") > > Signed-off-by: Igor Opaniuk <[email protected]> > > --- > > A single fix for running U-Boot on the QEMU virt machine with more > > than 3 GiB of RAM: relocation then places U-Boot (and its DMA > > buffers) above the 32-bit boundary, which the generic SDHCI driver > > cannot address with SDMA or 32-bit ADMA2 descriptors, so an emulated > > sdhci-pci eMMC silently loses its block device and bootstd finds no > > bootflow on it. Clamp the usable RAM top to 4 GiB, as other boards > > with 32-bit DMA constraints do. > > > > Found while bringing up an Android boot chain (TF-A + OP-TEE + > > U-Boot AVB + eMMC/RPMB) on qemu_arm64 and raising the VM memory > > from 3 GiB to 6 GiB. > > This is another case for LMB_LIMIT_DMA_BELOW_RAM_TOP too, isn't it? In > this case the generic SDHCI driver should select it?
I agree that LMB_LIMIT_DMA_BELOW_RAM_TOP belongs in this picture. It and the clamp will complement each other in this case, but LMB_LIMIT_DMA_BELOW_RAM_TOP cannot replace the clamp( if I understood your comment correctly). I can send a separate patch for adding "imply LMB_LIMIT_DMA_BELOW_RAM_TOP" to MMC_SDHCI driver. Thanks! > > -- > Tom
