Panzerknacker

No, because U-Boot loads the kernel from nvme and boots it. Then the defect kernel would find no pcie/nvme and therefore has no root fs. You land with a booted kernel in the ramdisk.

Probably not, it affected only linux-next and the kernel booted always fine, just without initializing pcie.

root@roc-pc:/usr/src/linux-next# cat .config |grep PCI |grep =y CONFIG_BLK_MQ_PCI=y CONFIG_HAVE_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_DOMAINS_GENERIC=y CONFIG_PCI_SYSCALL=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEFAULT=y CONFIG_PCIE_PME=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PCI_QUIRKS=y CONFIG_PCI_LABEL=y CONFIG_PCIE_ROCKCHIP=y CONFIG_PCIE_ROCKCHIP_HOST=y CONFIG_PCIE_DW=y CONFIG_PCIE_DW_HOST=y CONFIG_PCIE_DW_PLAT=y CONFIG_PCIE_DW_PLAT_HOST=y CONFIG_SERIAL_8250_PCI=y CONFIG_SND_PCI=y CONFIG_ARM_GIC_V3_ITS_PCI=y CONFIG_PHY_ROCKCHIP_PCIE=y CONFIG_GENERIC_PCI_IOMAP=y

U-Boot v2021.01 + SPI-Patch Linux roc-pc 5.11.0-rc6-next-20210205 #166 SMP PREEMPT Fri Feb 5 12:05:45 CET 2021 aarch64 GNU/Linux But did also work with December kernels. pci was broken on linux-next/arm64 from 8. Jan. until end of Jan or beginning of Feb.

[ 0.733926] vcc3v3_pcie: supplied by sys_12v [ 0.927228] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 0.927911] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 [ 0.928695] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 [ 0.930542] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 1.006248] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00 [ 1.006851] pci_bus 0000:00: root bus resource [bus 00-1f] [ 1.007343] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff] [ 1.007956] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff]) [ 1.008833] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400 [ 1.009486] pci 0000:00:00.0: supports D1 [ 1.009849] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 1.013657] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 1.014561] pci 0000:01:00.0: [144d:a808] type 00 class 0x010802 [ 1.015175] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 1.015931] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256) [ 1.017053] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 1.033595] pci_bus 0000:01: busn_res: [bus 01-1f] end is updated to 01 [ 1.034235] pci 0000:00:00.0: BAR 8: assigned [mem 0xfa000000-0xfa0fffff] [ 1.034854] pci 0000:01:00.0: BAR 0: assigned [mem 0xfa000000-0xfa003fff 64bit] [ 1.035551] pci 0000:00:00.0: PCI bridge to [bus 01] [ 1.036004] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa0fffff] [ 1.036811] pcieport 0000:00:00.0: enabling device (0000 -> 0002) [ 1.037672] pcieport 0000:00:00.0: PME: Signaling with IRQ 87 [ 1.039033] pcieport 0000:00:00.0: AER: enabled with IRQ 87 [ 1.331091] nvme nvme0: pci function 0000:01:00.0

Dumb USB 5V/3A Wallplug, USB-A->USB-C cable, USB-C power-in.

Can you try another drive? Samsung MZ-V7S1T0BW 970 EVO Plus 1 TB NVMe M.2 works for me.

On roc-rk3399-pc you can short pin 6 of the 8pin SPI-Flash-Chip to GND during power on. Then rk3399 boots from SD/eMMC.

I forgot to mention how to build ATF (Arm Trusted Firmware) git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git make PLAT=rk3399 bl31 cp build/rk3399/release/bl31/bl31.elf ../u-boot You need bl31.elf to build your u-boot!

If you really want to get rid of the SPI, you can erase it from your running u-boot. Stop auto boot in u-boot and type "sf" at the prompt.

Is a file named bl31.elf existing in the directory where you built u-boot? If yes, where did you get it from?

Where did you get bl31.elf in u-boot src dir from?

Therefore I doubt that the SPI chip is spoiled.

Right path?

earlycon=uart8250,mmio32,0xff1a0000 console=tty1 console=ttyS2,1500000