[SOLVED] MMC not working with latest downstream kernels on RPi2 B v1.1 (BCM2836)

[mad.daemon]

Hello!

while trying to switch from mainline kernel to latest downstream kernel (6.12.y cloned yesterday), I found that it's not possible to get MMC working on RPi2 B v1.1 (the rare BCM2836 model), when booting with
kernel build with bcm2709_defconfig without any changes, with latest firmware, proper DT (arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dtb from downstream kernel build) and upstream_kernel=1 commented in config.txt:

Code: Select all

Booting Linux on physical CPU 0xf00
Linux version 6.12.33-rpi+ (md@rpi4) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #11 SMP Fri Jun 20 15:38:35 CEST 2025
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1

Code: Select all

raspberrypi-firmware soc:firmware: Attached to firmware from 2025-05-14T12:25:47, variant start_x
raspberrypi-firmware soc:firmware: Firmware hash is 17084b403fb60475b8ee2641c26049a7d54bf153

I'm getting following errors:

Code: Select all

sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDXC card at address 0007
mmcblk0: mmc0:0007 SD128 117 GiB
sdhost-bcm2835 3f202000.mmc: wait_transfer_complete - still waiting after 100000 retries
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
usb 1-1: new high-speed USB device number 2 using dwc2
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
sdhost-bcm2835 3f202000.mmc: previous command (18) not complete (EDM 00010902)
 mmcblk0: unable to read partition table
mmcblk0: mmc0:0007 SD128 117 GiB (quirks 0x80000000)
mmc0: card 0007 removed

These repeat several times and the kernel eventually panics due to being unable to mount root fs.

As I found that the downstream kernel recently switched to upstream SDHOST driver ( CONFIG_MMC_BCM2835) in commit cb6b027 (https://github.com/raspberrypi/linux/co ... cc76f49369),
I tried to switch back to downstream driver (CONFIG_MMC_BCM2835_SDHOST enabled with CONFIG_MMC_BCM2835 disabled) but that didn't help, with this config, there are no MMC related messages in kernel log and the kernel ends up waiting for root device forever.

I can rule out the possibility of board or card issue because the board & cards works flawlessly with mainline/upstream kernel 6.12.33, using the same upstream driver (CONFIG_MMC_BCM2835) which throws above errors in downstream kernel.

As CONFIG_MMC_BCM2835 works with upstream kernel, while neither CONFIG_MMC_BCM2835 nor CONFIG_MMC_BCM2835_SDHOST work in downstream one, I guess the cause might be in downstream kernel, but outside these drivers...

Any hints/patches how to solve this issue are welcome. In case you don't have BCM2836 board to try, I'm willing to test on mine.

[PhilE]

kernel build with bcm2709_defconfig without any changes, with latest firmware, proper DT (arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dtb from downstream kernel build) and upstream_kernel=1 commented in config.txt:

Without going into the details too much (it's late on Friday), I'd say you have a strange mix of software.

bcm2709_defconfig is only present in the downstream tree (rpi-6.12.y), which means you must be building a downstream kernel, but then pairing that with an upstream Pi 2 dtb file - the correct downstream version would be bcm2709-rpi-2-b.dtb. And then you are setting upstream_kernel=1 to ensure that the bcm2836 version is loaded.

Can you explain your configuration choices?

[mad.daemon]

Thanks for the reply, I've been using only mainline kernels so far, now I'm switching to downstream kernel due to need for accelerated video encoding.

I didn't know that the DTB filenames differ with downstream kernels, so I picked bcm2836-rpi-2-b.dtb from downstream kernel tree (it was built there too). Now I'm going to try with bcm2709-rpi-2-b.dtb, will post results ASAP.

Regarding upstream_kernel=1, I use this line with mainline kernels and comment it out when booting downstream one. I didn't know that it affects which DT gets loaded. However, my downstream kernel somehow boots with bcm2836-rpi-2-b.dtb even when it's commented out - maybe because it's the only DTB present in my setup.

[PhilE]

However, my downstream kernel somehow boots with bcm2836-rpi-2-b.dtb even when it's commented out - maybe because it's the only DTB present in my setup.

Yes, that's correct - the firmware has a list of plausible DTB filenames for each model, downstream first, then upstream. The upstream_kernel setting swaps that order.

[mad.daemon]

I confirm that downstream kernel works with the correct DT file (bcm2709-rpi-2-b.dtb), so the issue is solved.

And after I learned here how downstream kernel and firmware treat DT files, I now see that it's the best way to do it. Different DT file names allow downstream kernels to reside next to upstream ones without having to overwrite the DT file on every switch, while the fallback to less suitable DT also makes sense - although MMC didn't work in my case, all other drivers (incl. downstream ones) correctly initialized even with the wrong upstream DT.

Thanks again, I really appreciate the amazing support here! Based on my corporate experience, if you were IBM, initial next-business-day reply would come next Tuesday, followed by a $1000 invoice in the beginning of next month...