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

Dark_iaji · 1 June 2022 17:39

https://forum.pine64.org/showthread.php?tid=8685

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?

spikerguy · 4 June 2022 22:18

Never tested that.

If uboot have pcie support then yes it should boot

Dark_iaji · 5 June 2022 00:43

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

Dark_iaji · 8 June 2022 01:50

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

My log

gist.github.com

https://gist.github.com/daiaji/eafa111f4d6dd0079561f16107e555d0

T4_U-Boot.log


U-Boot TPL 2020.07-00900-gce920e0e56 (Jun 08 2022 - 02:18:29)
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
Trying to boot from BOOTROM
Returning to boot ROM...

This file has been truncated. show original

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.

github.com/u-boot/u-boot

pci: Add Rockchip PCIe PHY controller driver

committed 12:53PM - 22 May 20 UTC

openedev

+306 -14

Yes, it is possible to have a dedicated UCLASS PHY driver for this Rockchip PCIe… PHY but there are some issues on Generic PHY framework to support the same. The Generic PHY framework is unable to get the PHY if the PHY parent is of a different uclass. Say if we try to get the PCIe PHY then the phy-uclass will look for PHY in the first instance if it is not in the root node it will try to probe the parent by assuming that the actual PHY is inside the parent PHY of UCLASS_PHY. But, in rk3399 hardware representation PHY like emmc, usb and pcie are part of syscon which is completely a different of UCLASS_SYSCON. Example: grf: syscon@ff770000 { compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd"; reg = <0x0 0xff770000 0x0 0x10000>; #address-cells = <1>; #size-cells = <1>; pcie_phy: pcie-phy { compatible = "rockchip,rk3399-pcie-phy"; clocks = <&cru SCLK_PCIEPHY_REF>; clock-names = "refclk"; #phy-cells = <1>; resets = <&cru SRST_PCIEPHY>; drive-impedance-ohm = <50>; reset-names = "phy"; status = "disabled"; }; }; Due to this limitation, this patch adds a separate PHY driver for Rockchip PCIe. This might be removed in future once Generic PHY supports this limitation. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Suniel Mahesh <sunil@amarulasolutions.com> #roc-rk3399-pc Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

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?

Can u-boot output more debugging information?

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

Dark_iaji · 11 June 2022 07:13

Regarding uboot, does anyone know how to submit a bug report? I have sent an email to u-boot@lists.denx.de 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.

Strit · 11 June 2022 07:30

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.

Dark_iaji · 11 June 2022 09:10

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.

Dark_iaji · 17 July 2022 09:10

Radio silence, perhaps a regional war broke out?

Strit · 17 July 2022 09:14

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