On Tue, Oct 27, 2026 at 11:56:41AM +0100, Igor Opaniuk wrote: > 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).
Because there's other possible issues on this platform, even if that driver was disabled? This gets to what I asked Marek in a different thread, on if we should invert the logic and make the new behavior opt-in for when platforms are safe and need it, rather than opt-out. > I can send a separate patch for adding "imply LMB_LIMIT_DMA_BELOW_RAM_TOP" > to MMC_SDHCI driver. Please, thanks. -- Tom
signature.asc
Description: PGP signature
