Started to test Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img and I could not boot off of the eMMC. So I put Armbian_19.11.5_Rockpi-4b_buster_current_5.4.6.img on an SD card and formatted my eMMC. I was then able to get the Rock Pi 4 to boot successfully. It looks like the kernel can not initialize the eMMC. Here are some messages from dmesg on boot:
[ 53.338988] dwmmc_rockchip fe310000.dwmmc: IDMAC supports 32-bit address mode.
[ 53.339028] dwmmc_rockchip fe310000.dwmmc: Using internal DMA controller.
[ 53.339048] dwmmc_rockchip fe310000.dwmmc: Version ID is 270a
[ 53.339126] dwmmc_rockchip fe310000.dwmmc: DW MMC controller at irq 28,32 bit host data width,256 deep fifo
[ 53.339411] dwmmc_rockchip fe310000.dwmmc: allocated mmc-pwrseq
[ 53.339426] mmc_host mmc0: card is non-removable.
[ 53.351589] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 53.364798] dwmmc_rockchip fe320000.dwmmc: IDMAC supports 32-bit address mode.
[ 53.364825] dwmmc_rockchip fe320000.dwmmc: Using internal DMA controller.
[ 53.364840] dwmmc_rockchip fe320000.dwmmc: Version ID is 270a
[ 53.364898] dwmmc_rockchip fe320000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo
[ 53.365040] dwmmc_rockchip fe320000.dwmmc: Got CD GPIO
[ 53.377851] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 53.393119] mmc2: CQHCI version 5.10
[ 53.399037] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[ 53.400631] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 53.402215] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 53.405068] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 53.408569] mmc0: queuing unknown CIS tuple 0x81 (9 bytes)
[ 53.417703] mmc2: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA
[ 53.427277] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[ 53.427416] mmc1: new high speed SDHC card at address 0001
[ 53.432073] mmcblk1: mmc1:0001 00000 7.41 GiB
[ 53.434118] mmcblk1: p1
[ 53.463648] mmc_host mmc0: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 53.515437] mmc2: mmc_select_hs400es failed, error -84
[ 53.515446] mmc2: error -84 whilst initialising MMC card
[ 53.599556] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 224
[ 53.601739] mmc0: new ultra high speed SDR104 SDIO card at address 0001
[ 53.637621] mmc2: mmc_select_hs400es failed, error -84
[ 53.637632] mmc2: error -84 whilst initialising MMC card
[ 53.777039] mmc2: mmc_select_hs400es failed, error -110
[ 53.777059] mmc2: error -110 whilst initialising MMC card
[ 53.968760] mmc2: mmc_select_hs400es failed, error -110
[ 53.968777] mmc2: error -110 whilst initialising MMC card
I brought this up in the Raxda forum: https://forum.radxa.com/t/armbian-buster-5-4-6-emmc-slot-not-being-detected/2422/2 and it was suggested to switch to hs200. I made the following modifications to the dtb like below on a freshly imaged eMMC:
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
index 1ae1ebd4efdd..5ea6286e5faa 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dts
@@ -592,8 +592,7 @@
&sdhci {
bus-width = <8>;
- mmc-hs400-1_8v;
- mmc-hs400-enhanced-strobe;
+ mmc-hs200-1_8v;
non-removable;
status = "okay";
};
This works, though hs400 seemed to be working on the Kernel 4.4 and I also see posts in this forum that suggests it was possibly working on 5.3.y? I reviewed the kernel docs for ../5.4.y/Documentation/devicetree/bindings/mmc/mmc-controller.yaml, though to be honest I'm a little out of my depth on proper configuration and if there are currently config issues preventing the eMMC from being initialized properly. My next step are to try and setup the build environment and figure out how to build 5.3.y branch to see if eMMC was working off of that branch? If anyone could confirm booting off of eMMC on 5.3.y that would be helpful, as then I could start a git bisect in the kernel source to try and figure out what commit broke support. Any further advice for someone more experienced with these SoC boards would be appreciated.