Orange Pi R1 Plus LTS in v6.3 linux kernel Ethernet PHY issue

DaveWK

Hi,

So I noticed in the v6.3 kernel that the Orange Pi r1 plus LTS appears ot be getting it's own dtb in the mainline kernel:


https://git.kernel.org/pub/scm/l ... 85237f033ffe0f184f1

While I know a bleeding edge release is bound to have issues, this brings me a step closer to getting a clean Fedora install, so I decided to give it a shot.

Unfortunately, something isn't working quite right. Would appreciate some help understandiung how to debug the issue and what the fix might be.

My Image Flashing process:
Currently (and sadly) the Orange Pi R1 Plus LTS is not in mainline u-boot. Fedora boots utilizing EFI, so u-boot scans the parititons for the grubaa64.efi file, and loads the dtb.
The change to scan partitions for the grub efi file were unfortunately merged after the versions of u-boot that are in the orangepi github repos, along with a lot of other driver updates, so it is not as simple as adding the custom DTS from the orangepi repo to the u-boot mainline repo.

Armbian and the original OrangePi ubuntu/debian releases rely on the old syslinux boot process, as well as utilize the less user-friendly rockchip miniloader/trust method rather than the "fully open source" method. Both u-boot builders also don't work natively on fedora/rpm-based systems, nor do they make it terribly easy to just produce the 3 u-boot files that need to be flashed without building the entire system in docker.

.. however I discovered that I was able to rip the uboot.img/trust.img/itbloader.bin files out of the debian os, flash the fedora aarch64 raw image, and then dd the files to the proper spots on the MMC, and it would get into grub and start booting. Luckily it was able to read the MMC's fat/efi/ext4 partitions (fedora uses separate boot/efi/root partitions in their image vs armbian/orangepi which use 1 parititon).


Problem with ipv4 DHCP during after boot and during u-boot:


For some reason after it finished booting, as well as during the u-boot process, the network driver seems broken. It is unable to get an ipv4 address via DHCP, but does seem to get some form of ipv6 address. This does not occur with armbian or orangepi linux on the partition.

When in the OS (via serial) after it finsihes booting, it starts to complain about not being able to see the ETH PHY:

1. [   46.428573] videodev: Linux video capture interface: v2.00
   
2. [   46.831828] hantro-vpu ff350000.video-codec: Adding to iommu group 0
   
3. [   46.832543] iommu: Failed to allocate default IOMMU domain of type 11 for group (null) - Falling back to IOMMU_DOMAIN_DMA
   
4. [   46.850859] hantro-vpu ff350000.video-codec: registered rockchip,rk3328-vpu-dec as /dev/video0
   
5. [   51.393997] NET: Registered PF_QIPCRTR protocol family
   
6. [   54.778180] rk_gmac-dwmac ff540000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
   
7. [   54.780196] rk_gmac-dwmac ff540000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
   
8. [   54.831102] rk_gmac-dwmac ff540000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
   
9. [   54.832984] rk_gmac-dwmac ff540000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
   
10. [   54.880285] rk_gmac-dwmac ff540000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
    
11. [   54.882155] rk_gmac-dwmac ff540000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
    
12. [   54.952956] rk_gmac-dwmac ff540000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
    
13. [   54.954803] rk_gmac-dwmac ff540000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
    
14. [   55.018517] rk_gmac-dwmac ff540000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
    
15. [   55.020487] rk_gmac-dwmac ff540000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
    

Copy code

I noticed that it seems to loading the hantro vpu on a headless board, but assume that is not an issue. When I use "lsusb" and "lspci" I do not see any devices.

I also see some messages arround the rk_gmac-dwmac startup which seem relevant:

1. [   21.097908] cpu cpu0: EM: created perf domain
   
2. [   21.131814] dw_wdt ff1a0000.watchdog: No valid TOPs array specified
   
3. [   21.155580] gpio-syscon ff100000.syscon:grf-gpio: can't read the data register offset!
   
4. [   21.190868] lima ff300000.gpu: gp - mali450 version major 0 minor 0
   
5. [   21.206138] lima ff300000.gpu: pp0 - mali450 version major 0 minor 0
   
6. [   21.206282] dma-pl330 ff1f0000.dmac: Loaded driver for PL330 DMAC-241330
   
7. [   21.207374] dma-pl330 ff1f0000.dmac:         DBUFF-128x8bytes Num_Chans-8 Num_Peri-20 Num_Events-16
   
8. [   21.207397] lima ff300000.gpu: pp1 - mali450 version major 0 minor 0
   
9. [   21.208862] lima ff300000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bit external bus
   
10. [   21.209910] lima ff300000.gpu: l2 cache 64K, 4-way, 64byte cache line, 128bit external bus
    
11. [   21.247696] Synopsys Designware Multimedia Card Interface Driver
    
12. [   21.255034] lima ff300000.gpu: bus rate = 163840000
    
13. [   21.255542] lima ff300000.gpu: mod rate = 163840000
    
14. [   21.257291] [drm] Initialized lima 1.1.0 20191231 for ff300000.gpu on minor 0
    
15. [   21.266499] rk808-rtc rk808-rtc.3.auto: registered as rtc0
    
16. [   21.269288] rk808-rtc rk808-rtc.3.auto: setting system clock to 2016-01-21T08:50:43 UTC (1453366243)
    
17. [   21.273790] systemd-journald[221]: Time jumped backwards, rotating.
    
18. [   21.277778] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit address mode.
    
19. [   21.278486] dwmmc_rockchip ff500000.mmc: Using internal DMA controller.
    
20. [   21.279248] dwmmc_rockchip ff500000.mmc: Version ID is 270a
    
21. [   21.279838] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq 47,32 bit host data width,256 deep fifo
    
22. [   21.297932] input: gpio-keys as /devices/platform/gpio-keys/input/input0
    
23. [   21.301912] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
    
24. [   21.376284] mmc_host mmc1: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0)
    
25. [   21.423244] rk_gmac-dwmac ff540000.ethernet: IRQ eth_wake_irq not found
    
26. [   21.423914] rk_gmac-dwmac ff540000.ethernet: IRQ eth_lpi not found
    
27. [   21.424675] rk_gmac-dwmac ff540000.ethernet: PTP uses main clock
    
28. [   21.425280] rockchip-drm display-subsystem: [drm:rockchip_drm_platform_probe [rockchipdrm]] *ERROR* No available vop found for display-subsystem.
    
29. [   21.425788] rk_gmac-dwmac ff540000.ethernet: clock input or output? (input).
    
30. [   21.427258] rk_gmac-dwmac ff540000.ethernet: TX delay(0x24).
    
31. [   21.427795] rk_gmac-dwmac ff540000.ethernet: RX delay(0x18).
    
32. [   21.428346] rk_gmac-dwmac ff540000.ethernet: integrated PHY? (no).
    
33. [   21.429482] rk_gmac-dwmac ff540000.ethernet: cannot get clock clk_mac_speed
    
34. [   21.430170] rk_gmac-dwmac ff540000.ethernet: clock input from PHY
    
35. [   21.435761] rk_gmac-dwmac ff540000.ethernet: init for RGMII
    
36. [   21.438093] rk_gmac-dwmac ff540000.ethernet: User ID: 0x10, Synopsys ID: 0x35
    
37. [   21.438804] rk_gmac-dwmac ff540000.ethernet:         DWMAC1000
    
38. [   21.439566] rk_gmac-dwmac ff540000.ethernet: DMA HW capability register supported
    
39. [   21.440266] rk_gmac-dwmac ff540000.ethernet: RX Checksum Offload Engine supported
    
40. [   21.440950] rk_gmac-dwmac ff540000.ethernet: COE Type 2
    
41. [   21.441436] rk_gmac-dwmac ff540000.ethernet: TX Checksum insertion supported
    
42. [   21.442079] rk_gmac-dwmac ff540000.ethernet: Wake-Up On Lan supported
    
43. [   21.442856] rk_gmac-dwmac ff540000.ethernet: Normal descriptors
    
44. [   21.443431] rk_gmac-dwmac ff540000.ethernet: Ring mode enabled
    
45. [   21.443969] rk_gmac-dwmac ff540000.ethernet: Enable RX Mitigation via HW Watchdog Timer
    
46. [   21.524429] dwmmc_rockchip ff500000.mmc: Successfully tuned phase to 186
    
47. [   21.525629] mmc1: new ultra high speed SDR104 SDXC card at address 5048
    
48. [   21.559444] mdio_bus stmmac-0: MDIO device at address 0 is missing.
    
49. [   21.654496] rk_gmac-dwmac ff540000.ethernet end0: renamed from eth0
    

Copy code

The lines:

1. [   21.435761] rk_gmac-dwmac ff540000.ethernet: init for RGMII
   
2. [   21.438093] rk_gmac-dwmac ff540000.ethernet: User ID: 0x10, Synopsys ID: 0x35
   
3. [   21.438804] rk_gmac-dwmac ff540000.ethernet:         DWMAC1000
   
4. [   21.439566] rk_gmac-dwmac ff540000.ethernet: DMA HW capability register supported
   

Copy code

The hex values User ID: 0x10, Synopsys ID: 0x35 seem like they may not be getting translated properly into their final map?

I noticed there were similar issues that had to do with changing the "rgmii-id" to "rgmii": https://lore.kernel.org/lkml/19f ... b@wolfvision.net/T/

But this was already set on the kernel dtb. Based on the lack of any usb devices, I suspect the issue has to do with a regulator getting adjusted at the wrong time and breaking the usb driver, but so far am stumped with how to proceed.

fnaf12

You'll be stuck alone in a gigantic toy factory while a scary beast hunts you in the brand-new horror game poppy playtime. Are you ready to go on this adventure? Begin immediately and have fun!