Re: OnLogic Helix 330
On Mon, Nov 27, 2023 at 09:10:18PM -0700, Devin Reade wrote: > On Tue, 2023-11-28 at 11:29 +1100, Jonathan Gray wrote: > > > STD_PHYID1 67C9 > > STD_PHYID2 DC00 > > > > /sys/dev/mii/miivar.h > [...] > > Thanks. > > So it looks like the approach here is to add a gpyphy.c and > gpyphyreg.h file, and tie it in via miidevs, correct? Yes, though a .h isn't needed. Two models are described on page 182 of the datasheet "Chip Identification and Ordering Information". > > I don't understand files.mii but it looks like it's only had one > commit in the last nine years; is files.mii obsolete? If not, > where do I find out more? Not all Ethernet drivers use the sys/dev/mii code. The config glue would look something like the below, see files.conf(5) and config(8). miidevs.h is regenerated by running 'make' in /sys/dev/mii after modifying miidevs. Index: sys/dev/mii/miidevs === RCS file: /cvs/src/sys/dev/mii/miidevs,v diff -u -p -r1.133 miidevs --- sys/dev/mii/miidevs 8 Jul 2023 08:18:30 - 1.133 +++ sys/dev/mii/miidevs 28 Nov 2023 04:23:25 - @@ -73,6 +73,7 @@ oui PLESSEYSEMI 0x046b40Plessey Semi. oui NATSEMI0x080017National Semi. oui TI 0x080028Texas Instruments oui MOTORCOMM 0x13d47aMotorcomm +oui MAXLINEAR 0x19f277MaxLinear /* in the 79c873, AMD uses another OUI (which matches Davicom!) */ oui xxALTIMA 0x000895Altima @@ -264,6 +265,10 @@ model MARVELL E1116R 0x0024 88E1116R Gi model MARVELL E30160x0026 88E3016 10/100 PHY model MARVELL PHYG65G 0x0027 PHYG65G Gigabit PHY model MARVELL E15450x002a 88E1545 Quad 10/100/1000 PHY + +/* MaxLinear PHYs */ +model MAXLINEAR GPY115B0x0030 GPY115B Gigabit PHY +model MAXLINEAR GPY115C0x0031 GPY115C Gigabit PHY /* Micrel PHYs */ model MICREL KSZ9021 0x0021 KSZ9021 10/100/1000 PHY Index: sys/dev/mii/files.mii === RCS file: /cvs/src/sys/dev/mii/files.mii,v diff -u -p -r1.33 files.mii --- sys/dev/mii/files.mii 4 Mar 2023 22:40:37 - 1.33 +++ sys/dev/mii/files.mii 28 Nov 2023 04:25:43 - @@ -152,3 +152,7 @@ filedev/mii/brswphy.c brswphy device ytphy: mii_phy attach ytphy at mii file dev/mii/ytphy.c ytphy + +device gpyphy: mii_phy +attach gpyphy at mii +file dev/mii/gpyphy.cgpyphy Index: sys/arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v diff -u -p -r1.520 GENERIC --- sys/arch/amd64/conf/GENERIC 11 Oct 2023 12:52:00 - 1.520 +++ sys/arch/amd64/conf/GENERIC 28 Nov 2023 04:27:28 - @@ -626,6 +626,7 @@ etphy* at mii? # Agere/LSI ET1011 Tru jmphy* at mii? # JMicron JMP202/JMP211 PHYs atphy* at mii? # Attansic F1 PHYs ipgphy*at mii? # IC Plus IP1000A PHYs +gpyphy* at mii?# MaxLinear GPY115 PHYs ukphy* at mii? # "unknown" PHYs eap* at pci? # Ensoniq AudioPCI S5016
Re: OnLogic Helix 330
On Tue, 2023-11-28 at 11:29 +1100, Jonathan Gray wrote: > STD_PHYID1 67C9 > STD_PHYID2 DC00 > > /sys/dev/mii/miivar.h [...] Thanks. So it looks like the approach here is to add a gpyphy.c and gpyphyreg.h file, and tie it in via miidevs, correct? I don't understand files.mii but it looks like it's only had one commit in the last nine years; is files.mii obsolete? If not, where do I find out more?
Re: OnLogic Helix 330
On Mon, Nov 27, 2023 at 11:30:23PM -, Stuart Henderson wrote: > On 2023-11-27, Devin Reade wrote: > > Once running snapshots, I initially configured the network for dwqe0. > > It came up and I was able to ping hosts on the dwqe0 network, but > > I noticed that carrier state seemed unpredictable. I then deleted > > hostname.dwqe0 and started trying to determine behavior based only on > > ifconfig status and media values. In short, things seem to be > > quite unpredicable. Some sample trials are shown, below: > [..] > > I don't know enough about it to go into detail, but these sort of symptoms > are making me think of issues with the PHY driver rather than the nic driver. > > > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev > > 0x52, address 84:8b:cd:4d:b5:f6 > > ukphy0 at dwqe0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > > 0x19f277, model 0x0030 > > dwqe1 at pci0 dev 29 function 2 "Intel Elkhart Lake Ethernet" rev 0x11: rev > > 0x52, address 84:8b:cd:4d:bc:36 > > ukphy1 at dwqe1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > > 0x19f277, model 0x0030 > > No idea whether there might be a better phy driver to start from, nothing > shows up in searches for that OUI. Maybe there are clues in linux dmesg or > mii tools. https://www.onlogic.com/hx330/ "1x MaxLinear GPY115 or 2x MaxLinear GPY115" https://assets.maxlinear.com/web/documents/617807_gpy115b1vi_gpy115c0vi_ds_rev1.4.pdf STD_PHYID1 67C9 STD_PHYID2 DC00 /sys/dev/mii/miivar.h #define MII_OUI(id1, id2) (((id1) << 6) | ((id2) >> 10)) (0x67c9 << 6) | (0xdc00 >> 10) is 0x19f277 #define IDR2_MODEL 0x03f0 /* vendor model */ #define MII_MODEL(id2) (((id2) & IDR2_MODEL) >> 4) as model is 0x30 ID2 will have those bits set 0xdc00 | (0x30 << 4) is 0xdf00
Re: OnLogic Helix 330
On Mon, 2023-11-27 at 23:30 +, Stuart Henderson wrote: > I don't know enough about it to go into detail, but these sort of > symptoms are making me think of issues with the PHY driver rather > than the nic driver. Yeah, mostly at the moment I'm trying to understand the different obsd network device layers. It looks like ukphy is a fallback for when a more specific PHY is not located, which means I'm likely looking for the PHY detection code. This part of the code base is new to me ... Devin
Re: OnLogic Helix 330
On 2023-11-27, Devin Reade wrote: > Once running snapshots, I initially configured the network for dwqe0. > It came up and I was able to ping hosts on the dwqe0 network, but > I noticed that carrier state seemed unpredictable. I then deleted > hostname.dwqe0 and started trying to determine behavior based only on > ifconfig status and media values. In short, things seem to be > quite unpredicable. Some sample trials are shown, below: [..] I don't know enough about it to go into detail, but these sort of symptoms are making me think of issues with the PHY driver rather than the nic driver. > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev > 0x52, address 84:8b:cd:4d:b5:f6 > ukphy0 at dwqe0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x19f277, model 0x0030 > dwqe1 at pci0 dev 29 function 2 "Intel Elkhart Lake Ethernet" rev 0x11: rev > 0x52, address 84:8b:cd:4d:bc:36 > ukphy1 at dwqe1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI > 0x19f277, model 0x0030 No idea whether there might be a better phy driver to start from, nothing shows up in searches for that OUI. Maybe there are clues in linux dmesg or mii tools.
Re: OnLogic Helix 330
It took me a while to get to this, and I'm just starting to investigate, but I figured I'd give an update. Based on Stefan's comments, I wasn't expecting things to work, but I figured I'd post what I have so far. The behavior seems to be consistent between the 18 Nov and 24 Nov snapshots; the dmesg for the latter is at the end of this post, as well as the output of `ifconfig -a` and `pcidump -v 2>&1`; for the latter, note the PCIOCGETVPD that shows up when dumping 0:29:1. Summary: Two dwqe devices show, but the behavior is inconsistent. The first bit on Observations describes some of the inconsistency in case it provides anyone with some insight. After that, there's a short discussion section, followed by pcidump and dmesg outputs. Note that em0 is configured throughout (I'm mostly connecting via ssh while watching console). Changes are made on dwqe only. The cabling to the dwqe ports was validated by observing link status and media changes when the cabling was attached to em1. === Observations: Once running snapshots, I initially configured the network for dwqe0. It came up and I was able to ping hosts on the dwqe0 network, but I noticed that carrier state seemed unpredictable. I then deleted hostname.dwqe0 and started trying to determine behavior based only on ifconfig status and media values. In short, things seem to be quite unpredicable. Some sample trials are shown, below: Trial 1: When neither dwqe device is configured, but dwqe0 is plugged into a switch at boot (all expected behavior): a. Initially status on dwqe0 is "active", dwqe1 is "no carrier". b. Unplugging the cable results in both being "no carrier". c. Plugging into dwqe1 changes dwqe1 to "active" d. Changing cable to dwqe0 results in dwqe0 "active", and dwqe1 as "no carrier". Trial 2: When neither dwqe device is configured, and neither device is plugged into a switch: a. Initially at boot the carrier LEDs are dark (as expected). b. ifconfig does not report a status line at all (media shows as autoselect/none) c. Plugging dwqe0 into the switch fails to result in a change of status or media values, the link light doesn't show d. Switching the cable from dwqe0 to dwqe1 exhibits the same behavior as (c) Trial 3: Similar sequence as Trial 1, except this time: a. The link light of dwqe0 comes on at boot b. Neither dwqe status value is shown, media is autoselect/none, similar to Trial 2 c. The link light stays on when dwqe0 is unplugged. Trial 4: Following trial 3, do a shutdown and manual power-off (but leave the power connector attached): a. The link light of dwqe0 stays on while the device is powered down, even if the cable is detached b. Detaching power caused the link light to go off. Waiting 20s and reapplying power resulted in the no-link-light case of Trial 2, other than the fact that the cable was still connected. Trial 5: I actually saw this one early on, when hostname.dwqe0 was configured, and dwqe0 was plugged in during boot: a. Network connection is alive as configured. b. Detatching the cable causes dwqe0 to go "no carrier" c. Reattaching the cable does NOT return the status to "active". This seems to be intermittent. Trial 6: I'm pretty sure I also saw a case where the cable was plugged into dwqe0 after boot, the link light was initially off, but eventually lit after a few _minutes_. I wasn't recording enough detail at that point to be sure, though. === Discussion I'm just starting to wrap my head around the network device driver code. I've read the EuroBSDCon 2017 paper, and am going through the various *dwqe* files in CVS, as well as pcidevs*. Other hints are welcome. Stefan mentioned up-thread: > At present we are only attaching dwqe to one of several possible MAC > PCI IDs I'm assuming this is referring to dwqe_pci_attach, which would imply that the attach _does_ occur already since dmesg shows the two Elkhart Lake Ethernets? === ifconfig -a (trimmed, dwqe0 currently connected to switch) dwqe0: flags=8802 mtu 1500 lladdr 84:8b:cd:4d:b5:f6 index 3 priority 0 llprio 3 media: Ethernet autoselect (none) dwqe1: flags=8802 mtu 1500 lladdr 84:8b:cd:4d:bc:36 index 4 priority 0 llprio 3 media: Ethernet autoselect (none) === pcidump -v Domain /dev/pci0: 0:0:0: Intel Elkhart Lake Host 0x: Vendor ID: 8086, Product ID: 453a 0x0004: Command: 0006, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 01 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS:
Re: OnLogic Helix 330
On Tue, Nov 07, 2023 at 09:17:57PM -, Stuart Henderson wrote: > On 2023-11-07, Devin Reade wrote: > > I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted > > the 7.4 install image via USB; no installation yet, no serial console > > configured yet, no sharable dmesg yet. > > > > I have the version with the four network interfaces, based on the > > J6426. Dropping to shell from the 7.4 install image, it looks like > > ony two of the four are detected, via em(4) as I210. Interestingly, > > it is the two on the add-on board rather than the two integrated > > ports, based on the link status in ifconfig(8). > > > > The underlying network hardware is a Maxlinear GPY115 per [3]. > > > > Booting into Debian 12, all four interfaces are detected. It looks like > > support for the GPY115 is relatively new there. > > GPY115 is a PHY, the NIC is dwqe(4), which was only recently supported > on non-ARM. Try -current before spending any more time on it. It seems this particular PHY is not yet supported. At present we are only attaching dwqe to one of several possible MAC PCI IDs because I don't have other hardware to test on. Help towards adding support for more devices would be very welcome.
Re: OnLogic Helix 330
On 2023-11-07, Devin Reade wrote: > I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted > the 7.4 install image via USB; no installation yet, no serial console > configured yet, no sharable dmesg yet. > > I have the version with the four network interfaces, based on the > J6426. Dropping to shell from the 7.4 install image, it looks like > ony two of the four are detected, via em(4) as I210. Interestingly, > it is the two on the add-on board rather than the two integrated > ports, based on the link status in ifconfig(8). > > The underlying network hardware is a Maxlinear GPY115 per [3]. > > Booting into Debian 12, all four interfaces are detected. It looks like > support for the GPY115 is relatively new there. GPY115 is a PHY, the NIC is dwqe(4), which was only recently supported on non-ARM. Try -current before spending any more time on it. -- Please keep replies on the mailing list.
OnLogic Helix 330
(Returning after a long hiatus due to $DayJob$.) I recently acquired an OnLogic Helix 330 (see [1] and [2]) and booted the 7.4 install image via USB; no installation yet, no serial console configured yet, no sharable dmesg yet. I have the version with the four network interfaces, based on the J6426. Dropping to shell from the 7.4 install image, it looks like ony two of the four are detected, via em(4) as I210. Interestingly, it is the two on the add-on board rather than the two integrated ports, based on the link status in ifconfig(8). The underlying network hardware is a Maxlinear GPY115 per [3]. Booting into Debian 12, all four interfaces are detected. It looks like support for the GPY115 is relatively new there. I intend to add support for these network interfaces but in the event anyone already has this or related work in progress, please drop me a line either here or privately. Once I get a proper install in place, I'll submit the usual dmesg output. Devin [1]: <https://www.onlogic.com/hx330/> [2]: <https://support.onlogic.com/documentation/hx300-technical-resources/> [3]: <https://assets.maxlinear.com/web/documents/617807_gpy115b1vi_gpy115c0vi_ds_rev1.4.pdf>
