RK1 - Booting and running off storage beyond eMMC
# │forum
t
Once the RK1's eMMC is flashed and configured, including "apt upgrade", it is time to flash the attached M.2 NVMe SSD. The documentation has the user dd the uncompressed Ubuntu disk image file to a node's M.2 SSD. When a disk is cloned (in this case the Ubuntu disk image file), the disk partition labels have identical UUIDs and identical root file system /etc/fstab entries containing these UUIDs. The net result is that, somewhat randomly, u-boot boots the kernel from the first eMMC partition or the first NVMe partition and then, somewhat randomly, mounts the root file system from the second partition of eMMC or the second partition of NVMe. The way around this is the "/usr/bin/ubuntu-rockchip-install /dev/nvme0n1" command. It clones the pre-configured eMMC partitions to the NVMe device while automatically assigning new partition UUIDs and modifying fstab in the NVMe SSD's root file system. This command should work with any block storage device. The RK1's u-boot configuration boots from NVMe before eMMC. Interrupting u-boot during the boot process allows examining the environment variables with "printenv", specifically the "bootcmd" and "boot_targets" environment variables. bootcmd contains "bootflow scan". boot_targets contains "mmc1 nvme scsi usb mmc0 pxe dhcp spi". "bootflow scan" iteratively attempts to boot from each of the boot targets sequentially until it succeeds. If nothing is bootable, u-boot restarts at the beginning of the "boot_targets" list. "boot_targets" can be modified with
setenv boot_targets "<device_list>"
. The environment variable is ephemeral across reboots. Some u-boot implementations include the
saveenv
u-boot command to make environment variable changes persistent. It doesn't appear this option is included in the RK1 implementation. Adding the option should be possible via the source. To boot from eMMC, would be "mmc0". To boot NVMe, would be "nvme0". Booting from a SATA/SCSI device should be "scsi0".
s
I've been trying to come up with solutions to prevent clashing UUID's to avoid this problem entirely. But ive not been able to come up with any good ideas so far, if anyone has an idea please do let me know.
t
@Spooky 'tune2fs -U' can be used to change the UUID of a Linux partition. I didn't pursue it completely, but I believe something like 'mlabel -N aaaa1111 -i /dev/mmcblk0p1 ::' might work for the vfat partition. Frankly, I like the way 'ubuntu-rockchip-install' works. Just wish I hadn't spent time having to find it.
s
The problem is you should not change the UUID of a partition while it's mounted, this can lead to filesystem corruption. We can easily modify the UUID of the boot partiton when it's not mounted, but the root partition is a diffrent story.
t
Understood. Is this something that could be done by bmcd as the final step of RK1 eMMC flashing? The eMMC partitions are visible to the BMC OS as sda1 and sda2. The same process could work from a Linux machine being used to flash over USB.
s
My knowledge of the BMC is limited as my main focus is Ubuntu. In theory i think this should be doable, but i dont know how reliable this process would be.
t
Now that I have a basic understanding of bmcd's flashing process, I'll investigate. Assuming there is enough space available in the v2.4 board's storage device, I can add the necessary Linux commands to the firmware build process.
s
It may be easier to do with Ubuntu 24.04, i'm working on it now and switching over to extlinux. The current method of using flash-kernel is ugly and terrible to maintain. But Ubuntu 22.04 and 24.04 will require different steps to properly change the UUID.
t
Glad to hear about progress on 24.04. With release of 24.04 LTS coming next month, I'll be watching closely.
s
It should be a very large improvement, including a more recent kernel (Linux 6.1).
t
@CFSworks I'm wondering whether there is a way to make changes to a RK1's u-boot environment variables persistent. It doesn't look like the
saveenv
command is implemented or it's hidden. Yes, I understand the possibility of temporarily bricking. I'm going to be testing a couple of Ethernet adapters (2.5Gb mPCIe and 10Gb M.2 B+M) in my RK1 cluster. I don't imagine there will be driver support in the current RK1 u-boot implementation. I particularly like the idea of setting individual RK1 SoMs and entire 4-node clusters up as FRUs.
x
Not sure if this is relevant/helpful, I used the ubuntu-rockchip-install script to clone eMMC to my nvme, script randomises UUIDs when creating the new partitions. https://cdn.discordapp.com/attachments/1219853884705607772/1220834934705492079/image.png?ex=66106222&is=65fded22&hm=2e535d2c73064255254fe01e257a59f8f3e3d9c4cf57f1582b1208a89f5d63b5&
t
That's what it's supposed to do.
x
yes apologies, you do mention this in your original post... doh, just reread it, its a great synopsis, I fluked using ubuntu-rockchip-install over dd, thanks for info, very helpful
6 Views