6.18: RPi3B+ can't boot from SD card, sdhost-bcm2835 doesn't complete transfer

[HiassofT]

Describe the bug

Trying to boot RPiOS trixie lite 32bit on a RPi3B+ fails with the current rpi-6.18.y rpi-update kernel (6.18.0-rc5). Both 32bit and 64bit kernels are affected.

The SD card (a Sandisk Extreme Pro 32GB) is detected, but trying to read the partition table fails as sdhost-bcm2835 doesn't seem to be able to complete the transfer:

[    2.843796] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.859076] mmc0: new high speed SDHC card at address aaaa
[    2.863658] mmcblk0: mmc0:aaaa SE32G 29.7 GiB
[    2.891623] sdhost-bcm2835 3f202000.mmc: wait_transfer_complete - still waiting after 100000 retries
[    2.896740] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.900876] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.904420] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.907791] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.911133] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.914379] sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 000108f2)
[    2.917866]  mmcblk0: unable to read partition table
[    2.921418] mmcblk0: mmc0:aaaa SE32G 29.7 GiB (quirks 0x00004000)
[    2.926200] mmc0: card aaaa removed

Steps to reproduce the behaviour

Install RPiOS Lite 32bit, boot on RPi3B+, run rpi-update rpi-6.18.y, reboot

Device (s)

Raspberry Pi 3 Mod. B+

System

OS: RPiOS Lite 32bit
Firmware:

[    0.040064] raspberrypi-firmware soc:firmware: Attached to firmware from 2025-08-20T17:04:09, variant start
[    0.050070] raspberrypi-firmware soc:firmware: Firmware hash is cd866525580337c0aee4b25880e1f5f9f674fb24

Kernel:

[    0.000000] Linux version 6.18.0-rc5-v7+ (runner@runnervmwmpaq) (arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP Wed Nov 12 10:58:09 UTC 2025

and

[    0.000000] Linux version 6.18.0-rc5-v8+ (runner@runnervmwmpaq) (gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP PREEMPT Wed Nov 12 11:03:41 UTC 2025

Logs

Serial console logs are here:
rpi3-boot.txt
rpi3-64-boot.txt

Additional context

rpi-6.17 kernel boots fine.

I know it's early days, just wanted to report in case others run into the same issue

[lategoodbye]

I wasn't able to reproduce this with mainline 6.18-rc5 on RPi 3B+ (arm/multi_v7_defconfig), so it seems to be downstream specific.

[pelwell]

I haven't tried a full upstream build yet, but I can trace the failure to commits e53d29f and f732619. They are part of a series that creates the concept of MMIO DMA addresses, which is an attribute indicating that they are non-movable hardware as opposed to movable pages. The concept sounds fine, but the implementation comes from a PC-centric world where the address space is uniform - sadly not the case with VideoCore hardware.

Although the series is large, the damage is done by two lines. The first applies the new MMIO attribute to any addresses passed through dma_(un)map_resource, and API used by many drivers that use external DMA: f732619#diff-cfa453f3a6f126274529d665fe88e052a6a023915a0a9fc487293bb0b84c4de8R373

The second decrees that, as a result, no DMA mapping should be applied: e53d29f#diff-1269d83c2aa603d9969d092eb68f06dc50a6220c2a72e60ad06b3af812b12e63R97

This assumption is clearly not valid in the VideoCore architecture.

@lategoodbye Your upstream build is getting away with it because it still contains this nugget which does an end run around all the Device Tree DMA address mapping:

	host->ioaddr = devm_platform_ioremap_resource(pdev, 0);
	if (IS_ERR(host->ioaddr)) {
		ret = PTR_ERR(host->ioaddr);
		goto err;
	}

	/* Parse OF address directly to get the physical address for
	 * DMA to our registers.
	 */
	regaddr_p = of_get_address(pdev->dev.of_node, 0, NULL, NULL);
	if (!regaddr_p) {
		dev_err(dev, "Can't get phys address\n");
		ret = -EINVAL;
		goto err;
	}

	host->phys_addr = be32_to_cpup(regaddr_p);

In the downstream world this is just:

	host->ioaddr = devm_platform_get_and_ioremap_resource(pdev, 0, &iomem);
	if (IS_ERR(host->ioaddr)) {
		ret = PTR_ERR(host->ioaddr);
		goto err;
	}

	host->phys_addr = iomem->start;

19a2aa9 is a patch that puts a phys_to_dma call into the MMIO code path.

[pelwell]

N.B. Running a downstream 6.18 kernel on a Trixie image on a 3B+, I found that the vc4-kms-v3d driver would trigger a hard reset as the driver was initialising. It looks like a watchdog reboot, but the watchdog was not enabled. However, it's a long time since I've tried to run a desktop image on a 4K screen using such an old device, and it may need some additional configuration.

[pelwell]

FYI, @rleon.

[lategoodbye]

N.B. Running a downstream 6.18 kernel on a Trixie image on a 3B+, I found that the vc4-kms-v3d driver would trigger a hard reset as the driver was initialising. It looks like a watchdog reboot, but the watchdog was not enabled. However, it's a long time since I've tried to run a desktop image on a 4K screen using such an old device, and it may need some additional configuration.

Maybe related: https://lore.kernel.org/linux-arm-kernel/20251005113816.6721-1-wahrenst@gmx.net/

[pelwell]

We have that patch, and reverting it doesn't prevent the reset.

[rleon]

19a2aa9 is a patch that puts a phys_to_dma call into the MMIO code path.

It is a strange, before introduction of dma_direct_map_phys(), the old dma_direct_map_resource didn't perform any phys_to_dma() translation.

Current dma_direct_map_phys( ..., DMA_ATTR_MMIO) is supposed to implement dma_direct_map_resource() exactly as it was before.

BTW, we didn't assume that "the address space is uniform", but only that caller knows to which memory, this specific physical address belongs.

Your bug is probably in description of the memory, as you basically partially implement dma_map_page() https://elixir.bootlin.com/linux/v6.17.7/source/kernel/dma/direct.h#L88 and not dma_map_resource().

Thanks

[pelwell]

Current dma_direct_map_phys( ..., DMA_ATTR_MMIO) is supposed to implement dma_direct_map_resource() exactly as it was before.

And I claim that it doesn't.

BTW, we didn't assume that "the address space is uniform", but only that caller knows to which memory, this specific physical address belongs.

Please explain what you mean by this.

BTW, we didn't assume that "the address space is uniform", but only that caller knows to which memory, this specific physical address belongs.

What do you mean by

to which memory, this specific physical address belongs

?

The data register of the SDHOST interface is clearly an MMIO address. However, its address as seen by the BCM2835 DMA controller is not the same as its address as seen by the CPU(s) (this mapping is described by the (downstream) DTS file). And that is why dma_addr = phys is insufficient.

[pelwell]

However, I am now wondering why we aren't seeing problems with Pi 5 and the bus masters in RP1.

[pelwell]

And the answer is obviously that most bus mastering blocks only need the address of system memory; only DMA controllers access MMIO registers, and the common Pi 5 use cases don't make use of RP1's DMA controller.

[rleon]

Current dma_direct_map_phys( ..., DMA_ATTR_MMIO) is supposed to implement dma_direct_map_resource() exactly as it was before.

And I claim that it doesn't.

Can you please support that claim with LXR links?
Like I said, code before map_phys and after map_phys patches must be the same.
Also if it doesn't happen with upstream code and only with some out-of-tree patches, why do you think that the problem is with the upstream?

BTW, we didn't assume that "the address space is uniform", but only that caller knows to which memory, this specific physical address belongs.

Please explain what you mean by this.

The one who is supplying physical address need to be aware if that address is backed by struct page or MMIO address without struct page.

Thanks

[pelwell]

The one who is supplying physical address need to be aware if that address is backed by struct page or MMIO address without struct page.

It is, and that's why it uses devm_platform_ioremap_resource.

With the new organisation, where is the translation from CPU physical address to DMA address meant to occur?

[rleon]

It depends on the platform.
Most likely that in your case, you will need to have .map_phys callback with DMA_ATTR_MMIO implementation. Or maybe there is some other bug exists.
Changing dma_direct_map_phys() function can't be right as this function wasn't changed.

[pelwell]

Changing dma_direct_map_phys() function can't be right as this function wasn't changed.

dma_direct_map_phys did not exist before e53d29f. The function that it replaced, dma_direct_map_page, had this structure:

static inline dma_addr_t dma_direct_map_page(struct device *dev,
		struct page *page, unsigned long offset, size_t size,
		enum dma_data_direction dir, unsigned long attrs)
{
	phys_addr_t phys = page_to_phys(page) + offset;
	dma_addr_t dma_addr = phys_to_dma(dev, phys);
	...
	return dma_addr;
};

Its replacement, dma_direct_map_phys, is:

static inline dma_addr_t dma_direct_map_phys(struct device *dev,
		phys_addr_t phys, size_t size, enum dma_data_direction dir,
		unsigned long attrs)
{
	dma_addr_t dma_addr;
	...
	if (attrs & DMA_ATTR_MMIO) {
		dma_addr = phys;
		...
	} else {
		dma_addr = phys_to_dma(dev, phys);
		...
	}
	...
	return dma_addr;
	...
}

The elided code in both functions includes some paths that return the result of swiotlb_map, but that is not relevant when called with an MMIO address. It also contains some error handling, not relevant for this discussion.

Excluding swiotlb and errors, dma_direct_map_page always returns the result of calling phys_to_dma. dma_direct_map_phys only returns a value from phys_to_dma for the non-MMIO cases; for MMIO, the unmodified phys input value is returned.

How is that not a change in behaviour?