Messages in this thread | | | Subject | Re: Orange Pi 4 (RK3399) fails to bring up ethernet on boot | From | Robin Murphy <> | Date | Mon, 6 Jan 2020 12:58:51 +0000 |
| |
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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
| |