Date: Mon, 17 Jun 2024 20:10:52 +0000 From: John F Carr <jfc@mit.edu> To: JMT Sihvola <jsihv@gmx.com> Cc: "freebsd-riscv@freebsd.org" <freebsd-riscv@freebsd.org> Subject: Re: JH7110 dwc MAC support Message-ID: <00D2F480-7703-4DE5-BC80-9E69D3B4E4D0@mit.edu> In-Reply-To: <trinity-2bf96660-359f-49f1-967e-da3cfea8e00c-1718395200970@3c-app-mailcom-bs13> References: <7E28ED97-DD4B-40AA-91FB-DB3982042265@mit.edu> <trinity-e7a78d45-28c3-4905-9504-37475fb12770-1718379639909@3c-app-mailcom-bs01> <AA50117A-8C29-4FD2-BCFD-FBC87ECC57CC@mit.edu> <trinity-2bf96660-359f-49f1-967e-da3cfea8e00c-1718395200970@3c-app-mailcom-bs13>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 14, 2024, at 16:00, JMT Sihvola <jsihv@gmx.com> wrote: >=20 > John F Carr wrote: >> Thanks. I tried putting your driver on the main (15-CURRENT) branch. >> It attaches but does not seem to put anything on the wire. >> I will try building your 14-based branch next. >=20 > I use it with 15 branch myself. That github of mine is probably not in > a coherent state. I recommend not using it for anything except > for grabbing these network related files. >=20 >> Is it correct to see a total of four PHYs in the dmesg output below? >=20 > Yes, it is seen like that also on vendor's OS. >=20 > Probably some sort of error message should appear somewhere during > the boot if it's not working. >=20 > One of the several things needed is the code for syscon pseudo device > (starfive_syscon.c) that is used for the device memory access. > It's already added to the mainline repository. >=20 > It may be challenging to get it working at this stage since things > needed are a bit scattered now, but network codes will hopefully > be added to CURRENT after a little while. >=20 > -jari s. All is forgiven. Almost all. The main problem was the failure of the kern= el to set up network configuration to mount / over NFS. With root on a memory disk (load -t md_image) I can use ifconfig to set up the interface. It at least passes a smoke test, reading files over NFS. However, the driver has offended WITNESS by trying to hold "eqos lock" and "Clock topology lock" at the same time. # ifconfig eqos0: flags=3D8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=3D80008<VLAN_MTU,LINKSTATE> ether f2:00:73:a0:80:56 media: Ethernet autoselect (none) nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> [...] # ifconfig eqos0 192.168.5.2/30 eqos0: link state changed to DOWN # lock order reversal: (sleepable after non-sleepable) 1st 0xffffffc085227070 eqos lock (network driver, sleep mutex) @ /usr/home= /15/src/sys/kern/kern_mutex.c:209 2nd 0xffffffc000895940 Clock topology lock (Clock topology lock, sx) @ /us= r/home/15/src/sys/dev/clk/clk.c:1208 lock order network driver -> Clock topology lock attempted at: #0 0xffffffc0003730f6 at witness_checkorder+0x99e #1 0xffffffc00031715e at _sx_xlock+0x58 #2 0xffffffc0000edd04 at clk_set_freq+0x44 #3 0xffffffc0005dfcd6 at if_eqos_starfive_set_speed+0x78 #4 0xffffffc0005b7018 at eqos_miibus_statchg+0x13e #5 0xffffffc00010ff72 at miibus_statchg+0x50 #6 0xffffffc000110c86 at mii_phy_update+0x60 #7 0xffffffc00010e850 at mcommphy_service+0x20a #8 0xffffffc00010f8ea at mii_tick+0x32 #9 0xffffffc0005b860c at eqos_tick+0x68 #10 0xffffffc000328948 at softclock_call_cc+0x106 #11 0xffffffc000329d8a at softclock_thread+0xaa #12 0xffffffc0002cba34 at fork_exit+0x68 #13 0xffffffc0005d8eca at fork_trampoline+0xa eqos0: link state changed to UP [...] # ifconfig eqos0 eqos0: flags=3D1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> met= ric 0 mtu 1500 options=3D80008<VLAN_MTU,LINKSTATE> ether f2:00:73:a0:80:56 inet 192.168.5.2 netmask 0xfffffffc broadcast 192.168.5.3 media: Ethernet autoselect (1000baseT <full-duplex,master>) status: active nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00D2F480-7703-4DE5-BC80-9E69D3B4E4D0>