How I Migrated U-Boot to Support a New eMMC Chip After Samsung’s Line Shutdown

When Samsung announced the discontinuation of one of its widely used eMMC product lines, many embedded vendors were forced to make quick adjustments. In our case, the eMMC used on one of our Rockchip-based boards became EOL (End of Life), and we had to quickly replace it with a different vendor's part to keep production moving.

This article documents the steps I took to modify U-Boot to support the new eMMC chip, including datasheet analysis, pin compatibility checks, register tuning, and extensive code changes.

Background

Our board is based on a Rockchip SoC (RK3566), using a Samsung eMMC for storage. The original chip had been in stable production until Samsung shut down its eMMC production line for that model. The replacement chip came from a different vendor, with different electrical specs and initialization behavior.

The challenge was that the replacement chip:

• Had different timing requirements (especially HS400 mode).

• Required tuning of EXT_CSD registers.

• Had a slightly different boot partition behavior.

Step 1: Analyze the New eMMC Datasheet

The first step was downloading and studying the new chip’s datasheet, particularly:

• Supported voltages (VCC and VCCQ)

• Supported modes (HS200/HS400)

• Default values of EXT_CSD

• Boot partition size and offset

By comparing this with Samsung's datasheet, I created a list of divergences that would affect U-Boot initialization.

Step 2: Check Hardware Compatibility

I confirmed with the hardware engineer that:

• Power rails matched (no need to modify PMIC setup)

• Signal routing for CLK/DS/DQ pins was sufficient

• No changes to pull-up resistors or series termination

This validated that the issue was purely on the firmware side.

Step 3: Identify U-Boot Subsystems to Modify

In our Android BSP, U-Boot is customized by Rockchip. The key files I needed to touch included:

• drivers/mmc/rockchip_sdhci.c

• drivers/mmc/mmc.c

• drivers/mmc/mmc_hwpart.c

• drivers/mmc/mmc_ops.c

The modifications included:

• Adjusting delays in mmc_send_tuning()

• Enabling vendor-specific initialization hooks

• Logging and inspecting EXT_CSD responses

• Tuning HS200 and HS400 transitions

Step 4: Test in Stages

Each test cycle involved:

1. Rebuilding U-Boot and flashing to SPI NOR

2. Observing boot logs via UART

3. Dumping EXT_CSD values

4. Using mmc read commands to check data integrity

After 2–3 days of debugging, the new chip initialized correctly, and could reliably boot from the boot0 partition.

Final Code Changes

The total git diff over the U-Boot source directory (u-boot/) showed 2700+ lines of changes. I created a separate branch in our GitHub repo:

🔗 view TFT config

While the repo is named after our TFT config repo, we’ve temporarily documented all firmware bring-up changes there for transparency.

Lessons Learned

• Don’t rely on one vendor for critical components.

• Datasheet diffing is your best friend.

• EXT_CSD debugging is vital — write a parser or script for it.

• HS400 tuning is extremely sensitive on Rockchip platforms.

Conclusion

Migrating to a new eMMC after Samsung's shutdown was stressful, but also rewarding. I now have a much deeper understanding of how U-Boot and eMMC interact, and the confidence to adapt our firmware quickly to future BOM changes.

If you’re facing similar migration needs, feel free to fork the GitHub repo or open a discussion with your experience.