How To Move Root Partition From eMMC to SSD

[Spam Sink]

It's very kind of you to get back to me.  I got it working in the 
meantime.  I am working with a U-Boot fork from FriendlyElec 
(manufacturer of the NanoPi R6C), I think that might be different from 
the rockchip fork.

Yes by SSD I mean NVMe.  I wanted to put boot and root partitions on 
NVMe but my understanding is that the R6C is not capable of finding the 
boot partition on NVMe, so the best you can do is to put the boot 
partition on eMMC and root partition on NVMe.

FriendlyElec package for the R6C half a dozen OS images, all of which 
share the same custom kernel image.  I am using one of their ubuntu images.

In the U-Boot monitor, I tried to override bootargs to change 
"root=/dev/mmcblk2p8" to "root=/dev/nvme0n1p1".  It didn't work.  I 
looked at the source code of FriendlyElec's fork of U-Boot and it 
appears that it ignores input from the monitor.

Instead I modified the source code of the FriendlyElec U-Boot fork, and 
hard coded the change:

     env_update("bootargs", "root=/dev/nvme0n1p1");

This worked and now it loads the root partition from NVMe.

You say that upstream U-Boot can boot a Linux OS from NVMe on an RK3588 
device, so I don't know why the FriendlyElec build is incapable of doing 
the same.  I might try to use upstream U-Boot.

Regards,
Eric

On 2/17/24 17:36, Peter Robinson wrote:
>> I am running the NanoPi R6C.  The device is not capable of booting from
>> the SSD, the next best thing is to load the root filesystem from the SSD.
> 
> By booting you mean loading the firmware from SSD (by which I think
> you mean NVME right).
> 
>> Using rockchip's repos, I compile from source the images to boot 1) from
>> the microSD card and 2) from eMMC.  I install to the eMMC.  Then, so as
>> not to mount any partitions from eMMC, I boot from the microSD card, and
>> I clone the root partition from the eMMC (/dev/mmcblk2p8) to the SSD
>> (/dev/nvme0n1p1).
>>
>> I boot from the eMMC, the output of "cat /proc/cmdline" is:
>>
>> storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal
>> androidboot.dtbo_idx=0 androidboot.verifiedbootstate=orange
>> earlycon=uart8250,mmio32,0xfeb50000 console=ttyFIQ0 coherent_pool=1m
>> irqchip.gicv3_pseudo_nmi=0 rw root=/dev/mmcblk2p8 rootfstype=ext4
>> rootflags=discard data=/dev/mmcblk2p9 consoleblank=0
>> cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
>> androidboot.fwver=uboot-a83a7263ef-01/09/2024
>>
>> How do I change "root=/dev/mmcblk2p8" to "root=/dev/nvme0n1p1"?
>>
>> I connect to the serial port and get to the U-Boot monitor.  I examine
>> the variables.  "bootcmd" runs "bootrkp" which boots the system.
>> "bootrkp" ignores "bootargs", I confirm this by deleting "bootargs"
>> before running "bootrkp", the system boots up as before with no change
>> in behavior.  "bootrkp" is implemented in file "cmd/bootrkp.c".  That
>> code emits the equivalent of:
>>
>> setenv bootm-no-reloc y
>> booti 0x400000 0xa200000:0x7b2bc0 0x8300000
>>
>> Can I tell U-Boot to load the root partition from /dev/nvme0n1p1, either
>> by entering commands at the monitor, or by modifying the source code of
>> U-Boot, or through any other means?
> 
> You don't mention what OS you're trying to load, is it Android?
> 
> So upstream U-Boot can boot a Linux OS from NVME on a rk3588 device,
> but it appears you're using the Rockchip fork and I have no idea of
> the state of that.
> 
> The upstream U-Boot doesn't yet have the R6C.
> 
> Generally if a device doesn't have something like a SPI flash where
> you can put firmware it's fine to use the eMMC for firmware and it
> should be able to run an OS from NVME.
> 
> If you're not using Android and are using a standard Linux distro I
> would look at enabling "distro boot" in the rockchip fork which will
> give you a standard UEFI boot interface and things should work. I have
> no idea if the U-Boot fork you're using includes PCI or NVME support
> but obviously make sure the appropriate drivers are enabled for that
> (look at the upstream Rock5B config).
> 
> Unfortunately I can't offer much more help from there as I generally
> only deal with upstream.
> 
> Peter