Closed klslz closed 2 years ago
It's not supported because the firmware does not have write support for NVMe. The USB-MSD firmware is a pretty old legacy stack so unlikely to be improved.
However, the Raspberry Pi Imager embedded version can be launched via rpiboot (you need the very latest release) and that supports NVMe. I think the future direction is to load a Linux RD which can then use standard Linux commands to modify the file-system e.g. HTTP download etc or use a USB gadget driver from Linux.
I am wondering if the rpi-imager is the right tool for day2day maintenance tasks.
The way I'd see it. You'd basically would have to disassemble the whole device or you'd need to insert and boot an uSD to run this or that maintenance task.
However. That's the way it is.
Would be nice to see a note about that IMO serious limitation in the otherwise excellent RPI online doc:
Otherwise more people will run into this trap.
THX
It's more likely to be a Linux-initrd that exposes the block device(s) via the OTG in gadget mode, although MTP might also be an option. That way it will work with whatever hardware the Linux kernel supports rather than baking all of this into the VPU stack.
I see. Let me put it my words, just to make sure I understood what you're saying.
You mean a special "maintenance" boot-mode on the NVMe could be an option, that'd put the RPI into gadget mode, while exposing the nvme filesystems. Similar to what's being done (process wise), with the overlay feature (which also creates a special initrd). Meaning. A new feature inside raspi-config that would enable gadget mode after a reboot would perhaps be required.
If it works then msd.elf will be replaced by a boot.img file containing a minimal Linux init-rd that exposes block devices via USB OTG gadget mode. It won't be Raspberry Pi OS or interactive and in the first instance would just replace what the custom msd.elf firmware does i.e. export EMMC. In principle it could export other block devices and since it's just a buildroot image anyone can roll their own.
@klslz I've uploaded an early release of the rpiboot replacement. https://github.com/raspberrypi/usbboot/pull/121
The usage is pretty much the same as msd but will will export NVMe, SCSI block devices in addition to EMMC
git clone https://github.com/timg236/usbboot.git usbboot-msg
cd usbboot-msg
git checkout mass-storage-gadget
make
cd mass-storage-gadget
../rpiboot -d .
Just ran a test against my Waveshare board and a Samsung PM991. It works! Great stuff.
I had to change the clone command though.
git clone https://github.com/timg236/usbboot.git usbboot-msg
Thanx a lot for your efforts.
I have a couple more drives and MBs over here. I'll do some more testing next week.
Just ran a test against my Waveshare board and a Samsung PM991. It works! Great stuff.
I had to change the clone command though.
git clone https://github.com/timg236/usbboot.git usbboot-msg
Thanx a lot for your efforts.
I have a couple more drives and MBs over here. I'll do some more testing next week.
Thanks. Hopefully, it can be merged into the main repo next week.
2nd test:
DFRobot DFR0767 MBO + CM4 - 8GB EMMC
OK!!
Hi Tim.
How would the eeprom update (recovery) work now??
So. Final feedback.
I just tested the Eeprom update. It also works. I also tested a Samsung 980Pro on a PCI-E adapter on the CM4 IO Board. Works great too.
Bottom line. 3 MBOs, 3 media types. All OK.
From my POW the case can be closed as soon as the update is merged.
Thx again.
@peterharperuk @pelwell ok to merge?
@klslz Thanks for the test report. This is now merged.
I ran latest rpiboot against a CM4 on a Waveshare-IO-BASE-A module.
uSD card is working fine - as expected
The NVME fs /dev/nvme0n1p1 and /dev/nvme0n1p2 won't be recognised though.
Is there anything I can do about it. Or is it simply not supported?
This to me would be a major drawback.