Following the instructions from this github I was able to successfully install Debian and boot it from NVMe on a NanoPi R5S.
It includes a u-boot image (with signed Rockchip images) that is flashed to to eMMC which in my understanding is reponsible to load and run Debian directly from NVMe:
u-boot r5s - signed with rockchip binaries: idbloader-r5s.img - uboot spl v2023.07.02 loader for nanopi r5s u-boot-r5s.itb - uboot v2023.07.02 loader for nanopi r5s
I tried to replace the Debian image in the NVMe with a DietPi R5S image, but the u-boot above (in the R5S eMMC) was not able to load DietPi from R5S NVMe.
I was wondering if there is any anything I could do to boot DietPi from R5S NVMe in the same way it is able to boot Debian from NVMe with the above u-boot images.
Unfortunately, debian image which shared with this uboot unable to do hardware acc and not really optimised.
I was able to install armbian image to nvme via their armbian-installer when installed to sd card but after armbian when i tried to write dietpi to nvme partition it didn’t boot.
Where did you find the Armbian image for the R5S? I looked at the Armbian website and I was not able to find an R5S image (no official nor community Armbian images for R5S are available).
Anyway, I understand that the reason that I was not able to boot DietPi from NVMe using the Debian u-boot would be the same reason you were not able to boot Armbian from the NVMe.
Perhaps in the future Armbian could provide an optimized u-boot that could be installed to the R5S eMMC and that would be able to boot from NVMe (similar to what was done with the OrangePi 5 u-Boot in SPI that is able to boot Armbian and DietPi from NVMe).
Armbian installed and booting OK from NVMe on a R5S.
However running the DietPi dietpi-installer failed with the following error with Armbian booted from NVMe, probably related to the different partition schema:
(...)
[ INFO ] Selected Git branch: MichaIng/master
[ INFO ] DietPi-Installer | Detected distribution version: Bookworm (ID: 7)
[ INFO ] DietPi-Installer | Detected host CPU architecture: aarch64 (ID: 3)
DietPi-Installer
─────────────────────────────────────────────────────
Step: [0] Detecting existing DietPi system
[ INFO ] DietPi-Installer | No DietPi system found, skipping old instance uninstall...
DietPi-Installer
─────────────────────────────────────────────────────
Step: [1] Target system inputs
[ INFO ] DietPi-Installer | Entered image creator: dme3
[ INFO ] DietPi-Installer | Entered pre-image info: https://www.armbian.com/nanopi-r5s/
[ INFO ] DietPi-Installer | Detected target userland/OS architecture: arm64
[ INFO ] DietPi-Installer | Selected hardware model ID: 76
lsblk: /dev/mmcblk1p1[/boot]: not a block device
[FAILED] DietPi-Installer | Unable to flash the bootloader: The boot drive does not contain a partition table. Aborting...
root@r5s:~#
This command must print /dev/mmcblk1p1 and no [/boot] afterwards:
findmnt -Ufnro SOURCE -T /boot
This appendix is known for bind mounts and Btrfs subvolumes. If it is a Btrfs subvolume, then DietPi would’t work with this anyway, as dietpi-drive_manager does not support those, and a bind mount wouldn’t make any sense. Also, I am not sure whether U-Boot supports Btrfs subvolumes.
Please use a regular single-partition image, like the official Armbian images for the R5S linked above your post. /boot can also be a dedicated (regular) partition, but I see only downsides doing this.
EDIT: Ah, I see you did use the official Armbian image, according to your pre-image input. Pretty strange, it does contain a single ext4 partition only and there is only the single expected /etc/fstab entry, no bind mount of anything else. Did you setup something by yourself? And you did use the Bookworm CLI image from September 13th?
Why that, instead of having everything on NVMe? Can you show the related fstab entry?
My understanding is that R5S cannot boot directly from NVMe. It either boots from SD or eMMC (see here, booting from NVMe is not mentioned). This way the bootloader goes to eMMC and the rest to NVMe.
Nope, it has an SPI flash from where it can boot from NVMe directly. Our current image can be booted from NVMe and USB directly.
EDIT: Hmm, or I mix it up with the other RK35xx boards. Will recheck.
So now we see that the /boot partition is a bind mount from /media/mmcboot which is not the /bootdirectory content itself, but contains /boot as a sub directory. Now I wonder why it is like that, instead of having the boot content in its root and using a regular mount to /boot directly. Can you show:
ls -l /media/mmcboot
We could use the --nofsroot/-v flag for findmnt to have the [/boot] suffix omitted, and dietpi-drive_manager at least just ignores and leaves bind mounts in place. But dietpi-installer would still remove /media/mmcboot, so the bind mount would fail without re-adding this. Generally this all looks fragile and unnecessary. Not sure why armbian-install sets it up like this. I would just have everything as a single partition on NVMe and good.
You are right. I was also confused by the /dev/mmcblk2boot* devices, on your’s and our images, but those are pointing to the /dev/mmcblk1p2 partition, and are added by the kernel as pseudo-devices, I guess. I mixed it up with the other RK35xx SBCs indeed.
If someone is ready to possibly break bootability without manually reverting the change, I would like to see whether it can boot from eMMC with all the files in its root instead of /boot subdirectory. Can be tested like this:
umount /boot
mv /media/mmcboot/boot/{,.??,.[^.]}* /media/mmcboot/
rmdir /media/mmcboot/boot
umount /media/mmcboot
sed -i '/[[:blank:]]\/boot[[:blank:]]/d' /etc/fstab
sed -i 's|/media/mmcboot|/boot|' /etc/fstab
systemctl daemon-reload
mount /boot
So the content on the eMMC is moved from the subdirectory into its root, the old boot mount is removed, and the eMMC directly mounted to /boot instead. The /etc/fstab should then contain only:
Looks like the NanoPi R5/6 are then another case where such mini images would be handy: USB boot | Provide tiny SD card image as USB boot relay · Issue #6186 · MichaIng/DietPi · GitHub
So even the content of /boot can remain on the rootfs drive and the eMMC (or SD card) contains only a tiny U-Boot to boot script which does nothing more than loading and running the boot script from the NVMe or USB drive.
We just tested it with my above steps. I mixed up /media/mmcboot with /mnt/mmcboot but just fixed the steps, and it works as expected. That way the dietpi-installer should work as well.
As this is how the armbian-install script sets things up, probably because they cannot know for sure whether the bootloader supports boot scripts in the partitions root instead of /boot sub directory, we can probably do these adjustments in dietpi-installer as well.
also could you check your dm 