I took a Samsung SSD hard drive (and some RAM) from a Librem 14 laptop, put it into the NitroPC (1) M.2 slot (the high one), and tried to boot. I get an EFI shell and no volumes appear. If I plug in a USB drive with a GNU/Linux OS, the EFI shell sees the USB drive and I can boot into it.
It makes sense that it doesn’t boot, because the drive does not have an EFI partition on it, however I don’t think it makes sense that it cannot see the drive at all.
These PC are sold with different firmware options. You should name the one including release yours uses. The dasharo firmware, I believe from memory, has options to disallow new devices, the new M2 should show up in the menu.
Invoice from 2024-08 (not 2023, my mistake) said this:
“NitroPC 1 (none, none, none, no wireless, sealed screws and sealed bag, Type B, North America) Operating System: none Option: I donate for firmware updates”
The UEFI shell says:
UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Then shows the USB device on the mapping table as FS0 with BLK0, BLK1.
When I exit, it says:
FW: 4.22-dirty 11/18/2023
Intel(R) Core™ i7-10710U CPU @ 1.10GHz
65536 MB RAM
That must mean I already have the 2024-05-29 firmware release because it includes coreboot 4.22 and also my order was in 2024-08.
If I don’t have the bootable USB stick plugged in, I see nothing on the mapping table.
“Current Secure Boot State” is “Disabled” as well.
I am confident the Samsung SSD works because I can read from it using a USB enclosure on a separate computer.
There is no dmidecode command in the EFI shell but from a live USB distribution I was able to run it. Yes, it shows
Vendor: coreboot
Version: 4.22-dirty
Release Date: 11/18/2023
ROM Size: 16 MB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
BIOS is upgradeable
Selectable boot is supported
ACPI is supported
Targeted content distribution is supported
BIOS Revision: 4.22
Firmware Revision: 0.0
Yes, it was the sole drive on the Purism Librem 14. I was able to use a USB enclosure to copy all the data off of it. I don’t see an EFI partition on it.
Oh, and yes, these are my first attempts to run anything on the NitroPC, I ordered it without RAM and without a hard drive.
Is it odd that it doesn’t show up in the mapping table at all? Or does it need an EFI partition in order to show up?
If you boot a live image, a simple lspci should enumerate the NVME (as “Non-Volatile memory controller”) on the bus, empty or with any partitions. Same for lsblk or sudo blkid If it does not appear, look through kernel messages (dmesg) for red lines. If it does not appear, there is something going on in the firmware.
Within coreboot uefi shell, you can try if it outputs anything related withcbmem -c.
Neither “nvme” nor “volatile” shows up in the live image. Plenty of other “controller”s do appear.
Nothing beyond loop0 and sda (the live USB device) show.
There is no cbmem command available in UEFI. When I run devices it shows a SATA controller but no NVMe nor Non-volatile memory controller.When I run blk it shows three entries: FS0, BLK0, and BLK1, all with “USB” in the details, basically all are coming from the live USB stick.
To me this reads like a hardware defect. You wrote you used “the high slot”. I reckon you have tried the other too. There is nothing secret with lspci output (edit: just don’t add -v options), if you want to post it. I suspect you need to email Nitrokey support.
I don’t think the SSD can fit in the low slot (the one closer to the motherboard), the high one is right on top of the low one and the low one would run into the post holding the screw for the high one.
After a conversation with AI (where it had me use coreboot-utils such as cbfstool and cbmem), your guess seems most likely.
The interesting lines from cbmem -c were these
[INFO ] Remapping PCIe Root Port #10 from PCI: 00:1d.1 to new function number 0.
[NOTE ] pcie_rp_update_dev: Couldn't find PCIe Root Port #13 (originally PCI: 00:1d.4) which was enabled in devicetree, removing and disabling.
Here was the concluding summary AI wrote:
Hardware: v2 confirmed three ways (iGPU 8086:9bca = Comet Lake‑U 6‑core/10710U group per the kernel i915 table, 12 threads, Aug‑2024 invoice).
Firmware: nitropc-v2 confirmed four ways (USE_OPTION_TABLE, STATIC_OPTION_TABLE, CONSOLE_CBMEM_BUFFER_SIZE=0x100000, CPU_MICROCODE_CBFS_DEFAULT_BINS), so the firmware-mismatch hypothesis I led with earlier is ruled out — my apologies for that detour.
Root cause (new, from your cbmem): PCH root port 13 (the M.2 NVMe slot, 00:1d.4) is not being exposed by the silicon, so coreboot removes it from the device tree and no NVMe can enumerate. The firmware is doing the right thing; the hardware isn’t responding.
Action: quick re-seat (low expectations), then RMA with the cbmem line as evidence. The drive is fine; the board’s root port 13 is defective.
