It seems that nvme and Btrfs enabled u-boot should be ported for rk3399 devices

Sigmaris seems to have done quite a lot of work and conducted some tests on pine64. Maybe it should enable these features that are not incorporated into the mainline for other rk3399 devices.

In fact, the mainline u-boot contains the PCI-E driver, but the weird thing is that I cannot use NVME to boot the NanoPC-T4. Is the fat32 partition lacking some kind of marking?

Debugging in the uboot command line found that nvme info did not have any output.

I have compiled all the u-boots I can find. It seems that they are useless.

@spikerguy Can your nanopc-t4 boot from nvme?:face_with_monocle:

Never tested that.

If uboot have pcie support then yes it should boot

My pm981a cannot be booted.
Although the driver porter claims that the original driver was tested on nanopc-t4.

After a lot of attempts, it is almost certain that this submission caused this failure.

My log

This commit mentions that the PCIe PHY driver seems to have been having some issues, but the generic PCIe PHY seems to have replaced the Rockchip PCIe PHY before the glitch was fully fixed.

This PCIe PHY is supposed to be a native component of rk3399, but why haven’t I heard from pine64 users reporting that nvme boot is not available?:thinking:

Can u-boot output more debugging information?

@speakerguy Can you try to reproduce this failure on your nanopc-t4?

Regarding uboot, does anyone know how to submit a bug report? I have sent an email to but have not received any response, I would love to use its issue list at gitlab, but it seems that using the issue list requires admin approval, what should I do after this Do? Using the v2020.07 version of uboot still seems to have some problems that prevent the kernel from being booted, but I don’t know if this is a failure caused by uboot’s pci-e driver.

The mailing list should be fine, but emails coming from outside the “members” of the list, needs to get approved, which can take a while.

I did some forward porting of old drivers, but I ran into a problem with the dev construct not being defined, and it’s totally unclear whether it was a pci-e driver failure that caused the kernel to fail to boot, or something else, I’m skeptical It is necessary to continue to work hard, and it seems that we can only continue to wait for the reply from the uboot maintainer for the time being.:smiling_face_with_tear:

:smiling_face_with_tear:Radio silence, perhaps a regional war broke out?

I’ve waited months for replies on that mailing list before. So it’s pretty normal.