BPI-R3 Mini eMMC Upgrade Project – Planning a 256 GB Upgrade

Hello everyone, I’m planning to upgrade the onboard eMMC of my Banana Pi BPI-R3 Mini from the factory chip to a 256 GB Samsung eMMC.

The eMMC I’m planning to use is: Samsung KLMEG8UERM-C041

From the information I have, it offers: Capacity: 256 GB Interface: eMMC 5.1 Package: BGA153 Manufacturer: Samsung

Higher storage capacity for Ubuntu, OpenWrt, Docker, containers, VMs, and development work. My goal is to make the BPI-R3 Mini a more capable router/NAS/server while keeping the onboard storage instead of relying entirely on an external SSD.

I’m also working on improving PCIe/NVMe support for my board, so increasing the onboard eMMC capacity will provide much more space for firmware development and testing.

I’d appreciate any advice from anyone who has: Successfully replaced the original eMMC. Verified compatibility of the Samsung KLMEG8UERM-C041 with the MT7986 platform. Found any bootloader (BL2/FIP), partitioning, or hardware issues after upgrading to a larger eMMC. Any experience or recommendations would be greatly appreciated.

Thank you!

Its original chip is an 8G eMMC, model number THGBMJG6C1LBAIL.

To replace it, I think we first need to compare their hardware power supply and software timings. If you are not familiar with this, you can try replacing it after comparing the voltage levels to see if it works.

You can find the datasheet for this chip online to view it.

Update: Samsung 256 GB eMMC Upgrade — Confirmed Findings and Open Questions

Hello everyone,

I have installed the Samsung KLMEG8UERM-C041 256 GB eMMC on my Banana Pi BPI-R3 Mini. I am currently investigating why Linux fails to switch the device to an eight-bit bus.

I have separated the observations confirmed by command output from possible explanations that have not yet been verified.

A. Confirmed facts

1. Test environment and storage

  • Board: Banana Pi BPI-R3 Mini, MediaTek MT7986.
  • Current OS: BananaWRT v25.12-linkup, booted from the board’s SPI-NAND for testing.
  • Replacement eMMC: Samsung KLMEG8UERM-C041, nominal 256 GB.
  • Linux-reported device name: EURM4S.
  • Detected capacity: 233 GiB.
  • eMMC revision: 5.1.
  • Boot partitions: boot0 and boot1, 4 MiB each.
  • RPMB: 4 MiB.

The replacement is detected by both U-Boot and Linux. Ubuntu has not yet been flashed to the replacement eMMC.

2. Linux initialization and current operating mode

The boot log contains:

mmc0: switch to bus width 8 failed
mmc0: new HS200 MMC card at address 0001
mmcblk0: mmc0:0001 EURM4S 233 GiB

The live controller state, read from /sys/kernel/debug/mmc0/ios, reports:

bus width:      2 (4 bits)
timing spec:    9 (mmc HS200)
signal voltage: 1.80 V
actual clock:   104000000 Hz

Therefore, Linux is currently operating the Samsung in four-bit HS200 mode, not HS400.

3. Samsung eMMC capabilities

The EXT_CSD data reports:

EXT_CSD_REV: 0x08
CARD_TYPE:   0x57
SEC_COUNT:   00c01e1d

The revision indicates eMMC 5.1. The CARD_TYPE value advertises HS200 and HS400 support at 1.8 V. SEC_COUNT is consistent with the detected capacity.

This confirms the advertised capabilities, but does not establish that the board can successfully initialize all those modes.

4. Active device-tree and pinctrl configuration

The live device tree contains:

bus-width          = 8
max-frequency      = 200000000
mmc-hs200-1_8v     = present
mmc-hs400-1_8v     = present
hs400-ds-delay     = 0x00014014

The clocks, assigned-clocks and assigned-clock-parents properties are also present.

Linux pinctrl reports all 12 eMMC signals assigned to the controller:

  • DAT0–DAT7
  • CMD
  • CLK
  • DS
  • RSTB

The pin configuration is present for all 12 signals. These checks establish the software assignments, not physical continuity of the PCB traces or BGA solder joints.

5. U-Boot result

U-Boot reports:

Mode: MMC High Speed (52MHz)
Bus Width: 4-bit

Requesting MMC mode index 10 did not change the reported mode. The capabilities of this particular U-Boot build have not been independently established, so this result alone does not prove a hardware problem.

In my earlier logs, the original Kioxia THGBMJG6C1LBAIL 8 GB eMMC successfully reached HS400 on this board.

B. Hypotheses—not yet confirmed

The cause of the failed eight-bit switch remains unresolved.

Hypothesis 1: Physical connection issue

A poor BGA solder joint or PCB connection affecting DAT4–DAT7 could prevent eight-bit operation while allowing the device to work in four-bit mode. This is plausible but has not been demonstrated by continuity measurements or BGA inspection.

Hypothesis 2: Controller or driver initialization issue

The MediaTek MSDC driver, the firmware version, or a chip-specific initialization difference could explain the failure. The presence of the expected device-tree properties does not prove that every initialization step is correct.

Hypothesis 3: Clock or timing configuration

The clock-parent configuration or HS400 timing parameters might require further investigation. However, the current clock-tree information has not established that these are the cause.

The hs400-ds-delay setting may matter when tuning HS400, but the eight-bit switch fails before HS400 is activated. I therefore do not want to change the data-strobe delay prematurely.

No evidence currently proves that the Samsung chip itself is defective or that its soldering is faulty.

C. Questions for the community

  1. Are there known initialization quirks or MediaTek MSDC patches for the Samsung KLMEG8UERM-C041 on MT7986?
  2. What is the recommended way to debug switch to bus width 8 failed in the Linux MMC core and MediaTek MSDC driver?
  3. Can anyone confirm HS400 operation with this Samsung part on the BPI-R3 Mini or another MT7986 platform?
  4. What is the most reliable procedure for separating a driver/configuration issue from a physical DAT4–DAT7 connection problem?

My objective is to diagnose the eight-bit initialization failure before changing the device tree or performing further BGA rework.

Thank you for your technical advice.