linux-kernel - Re: Orange Pi 4 (RK3399) fails to bring up ethernet on boot

Open Source and information security mailing list archives

Date:   Mon, 6 Jan 2020 12:58:51 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Joseph Kogut <joseph.kogut@...il.com>
Cc:     robh+dt@...nel.org, mark.rutland@....com,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: Orange Pi 4 (RK3399) fails to bring up ethernet on boot

On 03/01/2020 1:04 am, Joseph Kogut wrote:
> Hello,
> 
> I'm working on getting the newly released Orange Pi 4 up and running
> with the mainline kernel. Using the rk3399-orangepi device tree gets
> the device to start booting, but the kernel has an oops when starting
> networking, and the boot process fails to continue.
> 
> [  153.325306] Internal error: Oops: 96000004 [#1] SMP
> [  153.325733] Modules linked in: rockchipdrm btsdio(+) brcmfmac
> analogix_dp rockchip_rga dw_mipi_dsi brcmutil dw_hdmi hci_uart cec
> videobuf2_dma_sg cfg80211 v4l2_mem2mem btqca rc_core videobuf2_memops
> btbcm videobuf2_v4l2 btintel videobuf2_common drm_kms_helper bluetooth
> dwmac_rk syscopyarea stmmac_platform videodev panfrost sysfillrect
> stmmac snd_soc_simple_card sysimgblt fb_sys_fops gpu_sched
> snd_soc_simple_card_utils ecdh_generic st_lsm6dsx_spi phylink mc
> st_lsm6dsx_i2c ecc inv_mpu6050_i2c drm rfkill st_lsm6dsx inv_mpu6050
> adc_keys rockchip_saradc gpio_keys ak8975 cm32181 dw_wdt
> rockchip_thermal rtc_rk808
> [  153.330457] CPU: 1 PID: 493 Comm: systemd-network Tainted: G
>       L    5.5.0-rc4-1-ARCH #1
> [  153.331230] Hardware name: Orange Pi RK3399 Board (DT)
> [  153.331681] pstate: 40000005 (nZcv daif -PAN -UAO)
> [  153.332108] pc : mdiobus_get_phy+0xc/0x28
> [  153.332487] lr : stmmac_open+0x288/0xa50 [stmmac]
> [  153.332899] sp : ffff800011f2b5e0
> [  153.333190] x29: ffff800011f2b5e0 x28: 0000000000000000
> [  153.333656] x27: ffff0000eb6448c0 x26: ffff0000eb7e7e10
> [  153.334122] x25: 0000000000000001 x24: 0000000000000000
> [  153.334587] x23: ffff800011829000 x22: ffff0000eb644000
> [  153.335053] x21: ffff800011f2bbd0 x20: ffff0000ea0e6280
> [  153.335519] x19: 00000000ffffffff x18: 0000000000000000
> [  153.335984] x17: 0000000000000000 x16: 0000000000000000
> [  153.336449] x15: 0000000000000000 x14: 0000000000000000
> [  153.336915] x13: 0000000000000000 x12: 0000000000000000
> [  153.337380] x11: 0000000000000003 x10: 0101010101010101
> [  153.337845] x9 : ffff8000090becb0 x8 : 7f7f7f7f7f7f7f7f
> [  153.338310] x7 : fefefeff646c606d x6 : 1e091448e4e5f6e9
> [  153.338776] x5 : 697665644814091e x4 : 8080808000000000
> [  153.339241] x3 : 8343c96b232bb348 x2 : ffff0000ea0b8880
> [  153.339707] x1 : 00000000ffffffff x0 : fffffffffffffff8
> [  153.340172] Call trace:
> [  153.340392]  mdiobus_get_phy+0xc/0x28
> [  153.340717]  __dev_open+0x104/0x198
> [  153.341025]  __dev_change_flags+0x1a0/0x208
> [  153.341393]  dev_change_flags+0x28/0x68
> [  153.341731]  do_setlink+0x2cc/0xcc0
> [  153.342040]  rtnl_setlink+0xf0/0x188
> [  153.342355]  rtnetlink_rcv_msg+0x2b0/0x358
> [  153.342719]  netlink_rcv_skb+0x60/0x120
> [  153.343056]  rtnetlink_rcv+0x1c/0x28
> [  153.343371]  netlink_unicast+0x1a0/0x248
> [  153.343716]  netlink_sendmsg+0x1c0/0x3c0
> [  153.344061]  sock_sendmsg+0x4c/0x58
> [  153.344368]  __sys_sendto+0xd4/0x138
> [  153.344683]  __arm64_sys_sendto+0x2c/0x38
> [  153.345039]  el0_svc_handler+0xa4/0x188
> [  153.345377]  el0_sync_handler+0x1c8/0x260
> [  153.345730]  el0_sync+0x140/0x180
> [  153.346025] Code: d65f03c0 aa1e03e9 d503201f 8b21cc00 (f941d000)
> [  153.346560] ---[ end trace 0d82e8dab5e0c74f ]---
> 
> It's worth noting that the rk3399-orangepi device tree isn't
> necessarily compatible with this board, though after perusing the
> schematics for both the Orange Pi 4 and Orange Pi RK3399, I found no
> differences as far as the networking hardware goes. However, this is
> not an area in which I am well experienced.
> 
> I was able to work around this issue by reading a few other RK3399
> based device trees, and adding a phy-handle property to the gmac node,
> as well as an mdio child node. I have a patch [0] that works with my
> board, but I'm unsure if it's correct for both Orange Pis, and even if
> it is, I'm not sure what the original problem was, or how to word the
> commit message to actually send the patch.
> 
> Could you please advise on how I should proceed?

FWIW this appears to be down to a recent driver change breaking MDIO 
auto-probing in the case where there is neither a fixed link nor an 
explicitly-described phy - see the discussion on the thread here: 
https://lore.kernel.org/netdev/1599392.7x4dJXGyiB@diego/

Robin.

> 
> Best,
> Joseph
> 
> [0] https://gist.github.com/jakogut/bc21de0535b640f2374c1d07a710e8ab
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives