Hi Vagrant,
On 1/30/26 10:07 PM, Vagrant Cascadian wrote:
On 2026-01-30, Quentin Schulz wrote:
On 1/30/26 2:46 AM, Vagrant Cascadian wrote:
Thanks for adding support for rk3588 MNT Reform2!
I tried using u-boot 2026.01 with the rk3588 MNT Reform2, but it only
gets as far as SPL, and then fails:
U-Boot SPL 2026.01 (Jan 01 1970 - 00:00:01 +0000)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Error: -38
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
I *think* MMC1 is eMMC, which I currently have blanked, as recovering
from a failed install on eMMC is trickier.
It's surprising it isn't trying MMC1 twice as that's what it's supposed
to do due to u-boot,spl-boot-order containing "same-as-spl" and the eMMC
controller again later in the chain (see the property).
In any case, no support for the SD controller in SPL according to the
defconfig, can you try with:
"""
diff --git a/configs/mnt-reform2-rk3588_defconfig
b/configs/mnt-reform2-rk3588_defconfig
index 6adc9e4e60c..982e6c6eb20 100644
--- a/configs/mnt-reform2-rk3588_defconfig
+++ b/configs/mnt-reform2-rk3588_defconfig
@@ -50,6 +50,8 @@ CONFIG_MMC_HS400_ES_SUPPORT=y
CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
CONFIG_MMC_HS400_SUPPORT=y
CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
"""
and report if it gets you further?
Much further, indeed! With that applied to 2026.04-rc1, I managed to
load the kernel, initrd and dtb from NVMe, and boot all the way to a
rootfs!
Good to hear!
With one big downside... no display on linux (eDP? panel, or on
HDMI). Neither upstream u-boot or vendor u-boot provided output on the
display, so that part is not a regression.
I have a slightly older rk3588 module that does not use dsi -> eDP, that
might be an issue... maybe upstream u-boot vs. vendor u-boot is
configuring or not configuring something needed...
We should have HDMI support for RK3588 for a few releases in Linux
already. It works on RK3588 Tiger and Jaguar last time I checked. Maybe
missing/disabled DT nodes for your module, or drivers not
selected/installed.
There should be eDP support as well, we use those lanes on RK3588 Tiger
Displayport carrier which uses eDP for the DP connector. I tested that
with
https://lore.kernel.org/linux-rockchip/[email protected]/
so maybe missing DT nodes for either the eDP controller or the panel for
your board?
I think you'll be missing support for
the CD gpio as well in SPL.
So probably you need to enable SPL_GPIO:
"""
diff --git a/configs/mnt-reform2-rk3588_defconfig
b/configs/mnt-reform2-rk3588_defconfig
index 6adc9e4e60c..7485d03a0cb 100644
--- a/configs/mnt-reform2-rk3588_defconfig
+++ b/configs/mnt-reform2-rk3588_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
CONFIG_SKIP_LOWLEVEL_INIT=y
CONFIG_COUNTER_FREQUENCY=24000000
CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SPL_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3588-mnt-reform2"
CONFIG_ROCKCHIP_RK3588=y
CONFIG_SPL_SERIAL=y
@@ -50,6 +51,8 @@ CONFIG_MMC_HS400_ES_SUPPORT=y
CONFIG_SPL_MMC_HS400_ES_SUPPORT=y
CONFIG_MMC_HS400_SUPPORT=y
CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
"""
aaaand also enable it in SPL DT:
"""
diff --git a/arch/arm/dts/rk3588-mnt-reform2-u-boot.dtsi
b/arch/arm/dts/rk3588-mnt-reform2-u-boot.dtsi
new file mode 100644
index 00000000000..47509f4cb37
--- /dev/null
+++ b/arch/arm/dts/rk3588-mnt-reform2-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+/* SD CD */
+&gpio0 {
+ bootph-pre-ram;
+ bootph-some-ram;
+};
"""
I believe?
Do you think it is worth testing this part as well? Or is booting to
Likely yes.
Can you test having U-Boot TPL+SPL (idbloader.img) on eMMC (block offset
64, 32KiB), but not U-Boot proper. Have U-Boot proper (u-boot.itb) on SD
card (block offset 16384, 8MiB).
U-Boot should boot from eMMC first and then fallback to SD card next.
You can also try the opposite to verify this is properly setup as well.
The BootROM initializes various controllers such that if U-Boot doesn't
need to use another storage controller in SPL (or in proper
pre-relocation) it'll likely reach U-Boot proper (and Linux) just fine.
You can have this split in two commits. One to make it possible to boot
from SD card, another one for supporting fallbacks.
Cheers,
Quentin
