[FEA] support for flashing NVMe SSD disk

[fboudra]

Hi,

I'm not sure if it's the right place to ask for feature request, feel free to redirect me in the right direction if needed.

Using the Toradex i.MX 8M Plus and contributed support for PCIe/NVME on U-Boot:
https://source.denx.de/u-boot/u-boot/-/commit/950e74f60fd6b03bea45a5cb2e8516f44b6342a9

We can use an SSD to store and boot the OS successfuly.

Ideally, we can use a tezi image and TEZI to flash the OS directly on NVMe. As of today, only eMMC is supported with TEZI.

[rbeims]

Hello @fboudra, in theory, TEZI should be able to write data to any block device that's present in the system. You can define the needed devices and partition table using the blockdevs variable in image.json. Here's the documentation of the variables that are available in image.json:
https://developer.toradex.com/easy-installer/5.0/toradex-easy-installer/toradex-easy-installer-configuration-files

Said that, I'm not sure the kernel we distribute with the standard TEZI will properly detect the NVME disk. I assume it will, but there's a possibility that there's some configuration missing.
Would you be able to boot the module into recovery with the serial port connected and check if the NVME device is available?

[fboudra]

@rbeims Thanks for the pointers. I checked with tezi 6.8.0+build.8 and I can confirm its kernel doesn't have NVMe enabled (dmesg and zcat /proc/config.gz).

[fboudra]

@rbeims I sent a patch for the scarthgap branch to enable PCIe/NVMe support as described in the README.

I still need to figure out a proper configuration to write a Torizon OS 7.0 using blockdevs variable.

[rbeims]

Thank you for the patch, we will review it internally.

[fboudra]

@rbeims it looks like the kernel enablement isn't the only issue. While it looks like I'm using NVMe, the otaroot isn't correct:

/dev/disk/by-label/otaroot  29899644 1075416  27280036   4% /sysroot
/dev/nvme0n1p1             960302096 1075768 910371904   1% /var/rootdirs/media/otaroot

/dev/disk/by-label/otaroot -> /dev/mmcblk2p1

I suspect there's something that needs to be fixed with udev to propely populate /dev/disk/by-label and is most likely hardcoded or coupled somehow with mmcblk.

You need NVMe driver built-in in the kernel because the kernel modules aren't automatically loaded in the initramfs, hence udev doesn't create the disk/by-label symlink for NVMe.