I recently set up an s905-d3 using a Libre Computer Project eMMC 5.x 128GB module. I installed the vanilla arm64 variant of Ubuntu 26.04 server from an SD card to the eMMC module, but when I removed the SD card and rebooted, u-boot failed to load grub from the eMMC module. I had previously installed the same OS to a USB stick, and that worked fine on reboot. Booting into that USB install, I was able to mount the eMMC module and verify the install was intact there. I could perform various reads/writes without issue.
When attempting to boot from eMMC, I got various errors from u-boot. Sometimes there was a card didn’t respond to voltage select message, sometimes it just reported that it failed to read from the partition. Occasionally, I could get it to work long enough to inspect the partitions, but trying to load anything from them put it into the error state. I was using the latest u-boot image (I used pyaml boot to update u-boot in SPI and verified it was the July 2025 u-boot afterwards). I tried downgrading to the 2024-01 branch using libretech-builder-simple, and had the same symptoms there. However, messing around with the u-boot mmc commands, I found that putting the device into MMC_LEGACY mode allowed me to access it successfully from u-boot. I could inspect partitions, list files on them, and even load a kernel (I didn’t have enough u-boot knowledge to figure out how to manually boot grub from this state). I noticed in mmc info, that using this mode set the clock speed for the mmc device to 25MHz rather than the default it came up at of 52MHz. I then found that the MMC HS mode at 26MHz worked as well. With that in mind, I applied this tiny patch to the latest u-boot (v2026.04/lc-master):
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index bf82c5156..21b658b58 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -3058,6 +3058,10 @@ int mmc_start_init(struct mmc *mmc)
}
}
}
+
+ /* XXX Disable MMC_HS_52 to fix eMMC boot on Libretech aml-s905d3-cc */
+ mmc->host_caps &= ~MMC_CAP(MMC_HS_52);
+
#if CONFIG_IS_ENABLED(DM_MMC)
mmc_deferred_probe(mmc);
#endif
Rebuilt, and flashed that to SPI, and now I can boot reliably from eMMC.
However, this obviously isn’t the correct way to solve this and can’t be upstreamed.
Also, I have another issue: the SPI flash tools (pyamlboot and the spiflash images from libretech-builder-simple) fail to find the SPI NAND when an eMMC module is installed. I have to remove the eMMC module to update the firmware. Looking at the device tree files, sure enough there are some pins shared between eMMC and SPI, and it looks like you can either get 8-bit eMMC and no SPI, or 4-bit eMMC and SPI. The configuration looks correct to my untrained eyes, but this makes me wonder if something is not quite right with the setup and there is some conflict between the SPI flash and eMMC causing issues here.
When I successfully boot into Ubuntu with the patched u-boot, this is what is reported for the eMMC module:
$ sudo cat /sys/kernel/debug/mmc0/ios
clock: 200000000 Hz
actual clock: 199999997 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
timing spec: 9 (mmc HS200)
signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)
So clearly the eMMC module and board support higher speed modes just fine, as it’s running stable in this state once the Linux kernel takes over. Seems to be an issue specific to u-boot or the u-boot configuration.
I also found this vaguely similar thread that could be related:
So I should note I’m running the board propped on its side (to give the eMMC module some air) with no case, and I’ve tried 4 different power supplies and four different USB-c cables, and get the same result with all of them. They’re all rated at a minimum of 15 watts (5V+3AMPS supported), so I really don’t think this is a power issue, or if it is, I would say the boards are unreasonably sensitive to power issues.