pinn
pinn copied to clipboard
procount
Booting PINN from PCIe on CM4
Using the same CM4 carrier board with a dedicated PCIe slot, I am able to boot normally via a USB enclosure with an NVME drive into PINN but when booting with the same NVME drive in the PCIe slot I receive the error "Cannot find the drive with PINN files". Is this because PINN is looking for mmcblk, sda1, etc but not nvme0n1p1?
Not really. PINN searches all devices in /sys/class/block that are not virtual devices by mounting them and trying to locate recovery.rfs. Does your drive show up in there?
At the moment, after clicking past the above message I get to: "Recovery application crashed Starting shell" etc When I have PINN installed on the eMMC it does not list the NVME over PCIe, but does over usb as sda
@XECDesign - Do I need any additional drivers for NVME drives in the CM4 PCIe slot?
@procount Might be worth trying to compare the Linux kernel config used by PINN with that used by Raspberry Pi OS, to see if anything obvious jumps out?
Thanks @pelwell. I enabled CONFIG_NVMEM_RMEM after adding required CONFIG_PCI, but CONFIG_NVMEM_RMEM was not available. Guess I need a newer kernel for that. I'm using 5.4.51
I'll try to test this out tonight, but are there any potential updates with PINN 3.7?
3.7.1 is the latest. It has a later 5.10 kernel but I haven't enabled the additional CONFIG_NVMEM_RMEM config yet so it may still not work. I'll check if it is now available.
Thanks again for all your great work here. I am wondering whether you ever had a chance to see whether the CONFIG_NVMEM_RMEM config was available in the current kernel. Thanks!
Yes it seems to be available now, so I'll push up a version for you to test if you wouldn't mind.
https://sourceforge.net/projects/pinn/files/testing/pinn-3753.zip/download
From what I can tell so far it works! I wiped a CM4 so that only the NVME drive had PINN on it and am currently installing my OS's to PINN. I will update again once the installation is complete and I am able to test boot some OS's, but all looks good on my end so far.
No issues with PINN itself, but once the images are installed I will need to do quite a bit of research to figure out how to get them set up properly. The firmware that allows this to work is pretty new, so manually updating the firmware of the various installations is necessary to even get access to PCIE boot. I will keep experimenting with this. Do you expect it to be enabled in updates (I notice there was an update earlier today) or not until it is more proven?
AFAIK PCIe booting should "just work" with Raspberry Pi OS, but of course the situation with other OSes may vary... :wink:
@timg236 or @peterharperuk Does the partition-selection used by NOOBS (something to do with PM_RSTS IIRC) also work with booting from NVMe SSDs?
@NumberOneGit - As you indicated that it basically worked, I have added the appropriate drivers to v3.8, so you can update to that version for your tests if you like. I have not announced that feature yet as I await your further investigations.
@procount I would definitely say that it can be officially announced. I have compiled a working kernel for OSMC using the config changes mentioned above and LibreElec has said they can add those changes to future builds. RPOS has it enabled by default and RetroPie can boot from NVME over PCIe if it has been installed on another drive (SD or eMMC) and fully updated then cloned over.
I don't expect Lineage to work with it any time soon.
@NumberOneGit Does that mean that PINN's json files ought to report which OSes are bootable over NVME, and only offer to install those ones? (Like it already does for OSes that are bootable over USB, IIRC?)
@lurch I'm not sure how that's decided, as many OS's that I would put on the CM4 functional list seem not to appear there. My only concern that if hiding functionality isn't working as expected, 'showall' may not work 100%. I tried to install Kali 64-bit to USB a few weeks ago after setting up my cmdline.txt on pinn.mjh.nz and even with 'showall' enabled, it would disappear when I selected my USB drive and re-appear when I selected my SD card (on RP4B). I use 'showall' by default when I'm using PINN with my CM4 because it's difficult to draw the line between "working" and "not working" in general at this stage. For example, to get USB to work on OSMC I put "i2c-dev" in /etc/modules which allows my "otg_mode=1" command to work. The dev may never make that change in the OS due to the way they choose to release it, but it takes very little effort to fix once one is aware that it's needed.
Normally, PINN hides OSes that do not include the current RPi model in the supported_models field. The showall option shows all OSes regardless of RPi model. But this is independent of whether the OS can be installed to USB.
The first is normally due to firmware and the second is generally due to kernel facilities.
I don't have a CM4 to test compatibility, so if you are able to do this I can add more OSes to the CM 4 family.
@procount I don't have a CM4 either, but I believe if you're booting off NVMe the boot device would be something like /dev/nvme0n1p1 (at least, that's how the NVMe SSD in my Linux laptop appears).
@procount Do you make any changes at all to modify the OS itself in cases where the OS is linked via sourceforge rather than linked directly to the dev's page? I ask because I'd be glad to point out minor changes like the one mentioned above for OSMC that would make CM4 fully functional, that the dev themself may not consider if they want to keep their OS vanilla. RPOS doesn't package a separate CM4 version, so any modules added to other OS's should mimic RPOS' approach. Not a suggestion, just curious because I could provide very minor tweaks that would not hurt people with RPi4B but save multiple steps for people with a CM4.
One immediate suggestion would be to add:
" [cm4]
dtoverlay=dwc2,dr_mode=host"
to config.txt of future PINN releases.
You could also switch over to XHCI as the RPi Foundation has because there is no use for "device mode" in PINN but due to the limited time spent in PINN this would just be to stay current and not in any way necessary.
I try to keep the OS identical. The only changes I make are superficial ones to get the OS to multi-boot. For example: removing U-Boot, removing scripts that expand partitions & file systems etc. And of course, I convert the .img to a .tar.xz for each partition. Adding tweaks like [CM4] sections to config.txt of an OS would be ok, because they won't affect other models, but it makes it difficult to manage each time a new update to the OS it produced. An alternative is to capture the changes in a separate tar file and apply them at installation using a process that used to be called 'noobsconfig' I can add the section to PINN's config.txt easily if it helps CM4 users.
BTW, I have a test version of PINN almost ready to test out the hiding of OSes that don't support NVMe, as per Lurch's suggestion. Would you be able to test it out for me if I provide some test instructions?