strongtz

Well, it doesn't seem to be the case now. After link training timeout, I just need to reload the pcie kernel module, no matter when it's reloaded. (vcc3v3_pcie was kept on during the process by modifying device tree) Is there any way to workaround the problem without manual reloading?

Now I've got some ideas. It seems that some PCIe cards can't deal with 3.3V power well. From the log above, we know that kernel disabled the fixed-regulator vcc3v3_pcie, as it was unused after PCIe probe failure. When I manually reloaded the module, the regulator got enabled instantly (PCIe device getting its power), and PCIe link training went on smoothly. It leads me to think: Some PCIe devices might require immediate link training after getting 3.3V power, otherwise it fails to probe. AFAIK vcc3v3_pcie is enabled much earlier than the PCIe controller driver gets loaded, which might be the cause of the problem. So, is there a way to enable that regulator only when needed? (when the PCIe driver gets loaded)

Btw, I've seen people with NVMe storage encountering the same problem. I wonder if it's caused by something same.

Hi. I've got a ROC-RK3399-PC SBC with a JMB585 PCIe to SATA extension card. Unfortunately PCIe always doesn't work on boot, whether it is in u-boot or kernel, with `PCIe link training gen1 timeout` error. Just as the following log: However, after I manually run these commands, PCIe seems working. ```modprobe -r pcie_rockchip_host modprobe pcie_rockchip_host ``` Kernel log: Does anyone have any idea about what is going on? Thanks in advance.

Now we have a preliminary UEFI edk2 port for rk3399 boards with (kind of) working video output. It is able to boot Windows and Linux with pure ACPI now, though the acpi is quite broken currently. Windbg used to debug NT kernel over uart is basically working. You are welcomed to get involved to do some testing or offer some help! Repo: https://github.com/edk2-porting/edk2-rk3399/

I guess the device tree in the mainline kernel has some problems. Now I'm using Ubuntu Server 20.04 with the following device tree. Basically everything works, except for USB PD. (The OS was installed using iso with u-boot's EFI implementation) Here is the boot log. rk3399-roc-pc-mezzanine.dtb rk3399-roc-pc.dtsi rk3399-roc-pc-mezzanine.dts

Ubuntu 20.04 daily iso build works with 5.6.2 kernel (deb package) from https://kernel.ubuntu.com/ Issues: 1.device tree from mainline doesn't work, currently using dts from 5.4 (5.5?) 2."modprobe.blacklist=fusb302" is needed if you use a PD power supply 3.USB2 in u-boot is not stable, USB3(type-c) in u-boot is not usable 4.directly booting the iso without modification is not possible since you need to provide it with a device tree 5.you won't get USB3 working if you take step 2 6.to get correct display using efi boot, append "video=efifb:off" u-boot.log kernel.log

https://forum.loverpi.com/discussion/861/upstream-u-boot-status Will it be possible to use the forthcoming SPI u-boot to boot armbian?

It's more generic and is able to easily boot all kinds of OSes (maybe even win10 on arm like the raspberry pi 3b!) the rpi's uefi is a good example:https://github.com/andreiw/RaspberryPiPkg

Does anyone have interest in this project? It looks quite promising! https://github.com/andreiw/rk3399-edk2/