Thank you, I will run these tests on Friday,
I’ve got an A311D Pocket Reform. My NVME disappeared also, during/after apt upgrade. It boots 6.18.5-mnt-reform-arm64 (A311D here), / and /boot are on the internal EMMC, just can’t mount /home, which ought to be /dev/nvme0n1p1.
Only /dev/nvme-fabric exists.
journalctl -xb shows errors with meson-pcie, wait linkup timeout.
@Savasten @tomicdesu I just put my Pocket Reform SSD, the Taifast P1000 (the label is on the underside, so you have to remove the SSD to confirm if you have the same model) into my classic Reform with A311D and booted the most recent system image while my emmc was zeroed, so this was with kernel 6.18 and u-boot 2026-01-28. Do you also have this in your dmesg:
[Fri Jan 30 13:52:55 2026] pci 0000:00:00.0: bridge window [mem 0xfc700000-0xfc7fffff]: assigned
[Fri Jan 30 13:52:55 2026] pci 0000:00:00.0: ROM [mem 0xfc800000-0xfc80ffff pref]: assigned
[Fri Jan 30 13:52:55 2026] pci 0000:01:00.0: BAR 0 [mem 0xfc700000-0xfc703fff 64bit]: assigned
[Fri Jan 30 13:52:55 2026] meson-pcie fc000000.pcie: error: wait linkup timeout
[Fri Jan 30 13:52:55 2026] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[Fri Jan 30 13:52:55 2026] pci 0000:00:00.0: bridge window [mem 0xfc700000-0xfc7fffff]
[Fri Jan 30 13:52:56 2026] pci_bus 0000:00: resource 4 [io 0x0000-0xfffff]
[Fri Jan 30 13:52:56 2026] pci_bus 0000:00: resource 5 [mem 0xfc700000-0xfdffffff]
[Fri Jan 30 13:52:56 2026] pci_bus 0000:01: resource 1 [mem 0xfc700000-0xfc7fffff]
[Fri Jan 30 13:52:56 2026] pci 0000:00:00.0: Max Payload Size set to 256/ 256 (was 256), Max Read Rq 256
[Fri Jan 30 13:52:56 2026] meson-pcie fc000000.pcie: error: wait linkup timeout
[Fri Jan 30 13:52:56 2026] pci 0000:01:00.0: Failed attempting to set the MPS
[Fri Jan 30 13:52:56 2026] meson-pcie fc000000.pcie: error: wait linkup timeout
[Fri Jan 30 13:52:56 2026] meson-pcie fc000000.pcie: error: wait linkup timeout
[Fri Jan 30 13:52:56 2026] pci 0000:01:00.0: Max Payload Size set to 128/ 256 (was 128), Max Read Rq 128
[Fri Jan 30 13:52:56 2026] pcieport 0000:00:00.0: PME: Signaling with IRQ 22
[Fri Jan 30 13:52:56 2026] pcieport 0000:00:00.0: AER: enabled with IRQ 22
Followed by a bunch more meson-pcie fc000000.pcie: error: wait linkup timeout until then:
[Fri Jan 30 13:52:59 2026] nvme 0000:01:00.0: of_irq_parse_pci: failed with rc=134
[Fri Jan 30 13:52:59 2026] nvme nvme0: pci function 0000:01:00.0
[Fri Jan 30 13:52:59 2026] nvme nvme0: missing or invalid SUBNQN field.
[Fri Jan 30 13:52:59 2026] hwmon hwmon2: temp1_input not attached to any thermal zone
[Fri Jan 30 13:53:00 2026] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
[Fri Jan 30 13:54:00 2026] nvme nvme0: I/O tag 4 (1004) QID 0 timeout, disable controller
[Fri Jan 30 13:54:05 2026] nvme nvme0: Device not ready; aborting shutdown, CSTS=0x5
[Fri Jan 30 13:54:05 2026] nvme nvme0: failed to set host mem (err -4, flags 0x1).
[Fri Jan 30 13:54:05 2026] nvme 0000:01:00.0: probe with driver nvme failed with error -4
Full log: https://mister-muffin.de/p/EmB_.txt
Do you two have the same dmesg output with the same SSD?
Yes those dmesg logs look almost identical.
![]()
I have been able to download and write the latest image from above. As assumed it did not boot. I was able to write the u-uboot test to the new image skipping the first 512 of the sd card and unfortunately still will not boot.
Back to the November image i guess.
I was able to reproduce the issue with A311D classic Reform and the Taifast SSD from the Pocket on kernel 6.18. I am no longer able to reproduce the problem with kernel 6.19~rc6.
@Savasten @tomicdesu @G3M Could you try flashing a system image from this gitlab CI job and find out if you can then see /dev/nvme0n1 again?
I forward ported our patches to 6.19~rc6 today and built above system image which includes that kernel so that you have an easy time test-driving it.
Yes, I flashed that image to an SD card, booted my Pocket Reform A311D, and my NVMe is now visible.
The new image does see the NVMe drive properly. u-boot did not work on the new image so I had to flash 2024.04-dirty to the emmc to get it to boot.
What do you mean by that?
The new image would not boot with the EMMC zeroed.
This is odd because it worked for G3M.
Do you have a UART adapter and can see what is going on?
Can you also make sure you flashed the correct image? I sometimes flash the wrong one and since that one includes the wrong u-boot the system wont boot if emmc is zeroed.
Thank you so much @josch, I am back up and running thanks to
your help and the temporary fix from here.
I ordered som different cable with j-hooks that will allow me to connect to uart a little easier. I will move my u-boot digging back to this thread as these issues are self inflicted:
Have a wonderful day!
You mean you are now on kernel 6.19~rc6? Keep us posted with problems you find!