From: Mark Kettenis Subject: Re: puc(4): make NM9900 attach To: Theo Buehler Cc: tech@openbsd.org Date: Fri, 04 Jul 2025 00:13:46 +0200 > Date: Thu, 3 Jul 2025 23:45:29 +0200 > From: Theo Buehler > > On Thu, Jul 03, 2025 at 11:22:29PM +0200, Mark Kettenis wrote: > > > Date: Thu, 3 Jul 2025 10:49:00 +0200 > > > From: Theo Buehler > > > > > > On my Dell Precision 3640 build box I'm trying to get a serial > > > card (the one recommended by Dell) to work as kernel console. > > > With the diff below the card attaches as > > > > > > puc0 at pci3 dev 0 function 0 "NetMos Nm9900" rev 0x00: ports: 16 com > > > com4 at puc0 port 0 apic 2 int 16: st16650, 32 byte fifo > > > > > > and after editing /etc/ttys to contain > > > > > > tty04 "/usr/libexec/getty std.9600" vt220 on secure > > > > > > I can log in using 'cu -l usb0.0.000010 -s 9600' once init > > > ran on that machine. > > > > > > The 'mach comaddr 0x00003000/0x0008' + 'set tty com4' bit described here > > > > Hmm, I don't think the '/0x0008' bit is right. But it probably > > doesn't matter. > > Oh right. I should have deleted the /0x0008 part since this is just > strtou* parsing the first part of the number up to the /. > > > > https://marc.info/?l=openbsd-misc&m=144159112421386&w=2 > > > doesn't seem to work. Not sure if this is expected to work for efiboot > > > at all. > > > > I don't see why it wouldn't work with efiboot, but I'm not sure I ever > > tested it. > > ok, thanks. Maybe I just haven't managed to figure out the correct magic. > > > > Here's the relevant bit of the pcidump. > > > > > > 3:0:0: NetMos unknown > > > 0x0000: Vendor ID: 9710, Product ID: 9900 > > > 0x0004: Command: 0100, Status: 0010 > > > > Hmm, that means PCI_COMMAND_IO_ENABLE isn't set, which means the > > device won't respond to io access. That makes sense if the > > information was collected using a kernel that didn't include your > > diff. Is that correct? > > That's right. I thought it'd be better to show what's there without > my fiddling/guesswork, so I'm sure it's coherent. > > My diff changes the information as follows, so the _IO_ _MEM_ and _MASTER_ > commnds are enabled, if I understand correctly. 'n vectors (1 enabled)' > is added to all PCI devices with MSIs, where n is one of 1, 8, or 32. Ok, then that explains why the 'mach comaddr' thing doesn't work. The PCI device isn't active at that point, so the serial port doesn't work until the kernel boots and enabled the device. In principle it is possible to do this from efiboot. But we need to think about how we would implement this. > --- nodiff Thu Jul 3 23:25:49 2025 > +++ withdiff Thu Jul 3 23:26:01 2025 > @@ -1,6 +1,6 @@ > 3:0:0: NetMos unknown > 0x0000: Vendor ID: 9710, Product ID: 9900 > - 0x0004: Command: 0100, Status: 0010 > + 0x0004: Command: 0107, Status: 0010 > 0x0008: Class: 07 Communications, Subclass: 00 Serial, > Interface: 02, Revision: 00 > 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, > @@ -17,7 +17,7 @@ > 0x0038: 00000000 > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) > - Enabled: no > + Enabled: no; 8 vectors (1 enabled) > 0x0078: Capability 0x01: Power Management > State: D0 > 0x0080: Capability 0x10: PCI Express > > or in full: > > 3:0:0: NetMos unknown > 0x0000: Vendor ID: 9710, Product ID: 9900 > 0x0004: Command: 0107, Status: 0010 > 0x0008: Class: 07 Communications, Subclass: 00 Serial, > Interface: 02, Revision: 00 > 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, > Cache Line Size: 10 > 0x0010: BAR io addr: 0x00003000/0x0008 > 0x0014: BAR mem 32bit addr: 0x91101000/0x00001000 > 0x0018: BAR empty (00000000) > 0x001c: BAR empty (00000000) > 0x0020: BAR empty (00000000) > 0x0024: BAR mem 32bit addr: 0x91100000/0x00001000 > 0x0028: Cardbus CIS: 00000000 > 0x002c: Subsystem Vendor ID: a000 Product ID: 1000 > 0x0030: Expansion ROM Base Address: 00000000 > 0x0038: 00000000 > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) > Enabled: no; 8 vectors (1 enabled) > 0x0078: Capability 0x01: Power Management > State: D0 > 0x0080: Capability 0x10: PCI Express > Max Payload Size: 256 / 512 bytes > Max Read Request Size: 512 bytes > Link Speed: 2.5 / 2.5 GT/s > Link Width: x1 / x1 > 0x0100: Enhanced Capability 0x02: Virtual Channel Capability > 0x0800: Enhanced Capability 0x01: Advanced Error Reporting > > > > > > 0x0008: Class: 07 Communications, Subclass: 00 Serial, > > > Interface: 02, Revision: 00 > > > 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, > > > Cache Line Size: 10 > > > 0x0010: BAR io addr: 0x00003000/0x0008 > > > 0x0014: BAR mem 32bit addr: 0x91101000/0x00001000 > > > 0x0018: BAR empty (00000000) > > > 0x001c: BAR empty (00000000) > > > 0x0020: BAR empty (00000000) > > > 0x0024: BAR mem 32bit addr: 0x91100000/0x00001000 > > > 0x0028: Cardbus CIS: 00000000 > > > 0x002c: Subsystem Vendor ID: a000 Product ID: 1000 > > > 0x0030: Expansion ROM Base Address: 00000000 > > > 0x0038: 00000000 > > > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > > > 0x0050: Capability 0x05: Message Signalled Interrupts (MSI) > > > Enabled: no > > > 0x0078: Capability 0x01: Power Management > > > State: D0 > > > 0x0080: Capability 0x10: PCI Express > > > Max Payload Size: 256 / 512 bytes > > > Max Read Request Size: 512 bytes > > > Link Speed: 2.5 / 2.5 GT/s > > > Link Width: x1 / x1 > > > 0x0100: Enhanced Capability 0x02: Virtual Channel Capability > > > 0x0800: Enhanced Capability 0x01: Advanced Error Reporting > > > > > > The pucdata.c diff is adapted from the NM9901, omitting the parallel part > > > since I couldn't find any hint on that in my dump. > > > > > > There was another, much more involved, puc(4) diff recently but this one > > > should not conflict with it and seems independent: > > > https://marc.info/?l=openbsd-tech&m=175080329526382&w=2 > > > > This diff is ok kettenis@ > > Thanks. > > > > > > Index: sys/dev/pci/pcidevs > > > =================================================================== > > > RCS file: /cvs/src/sys/dev/pci/pcidevs,v > > > diff -u -p -r1.2101 pcidevs > > > --- sys/dev/pci/pcidevs 21 Jun 2025 20:17:35 -0000 1.2101 > > > +++ sys/dev/pci/pcidevs 23 Jun 2025 13:42:52 -0000 > > > @@ -7822,6 +7822,7 @@ product NETMOS NM9820 0x9820 Nm9820 > > > product NETMOS NM9835 0x9835 Nm9835 > > > product NETMOS NM9845 0x9845 Nm9845 > > > product NETMOS NM9865 0x9865 Nm9865 > > > +product NETMOS NM9900 0x9900 Nm9900 > > > product NETMOS NM9901 0x9901 Nm9901 > > > product NETMOS NM9922 0x9922 Nm9922 > > > > > > Index: sys/dev/pci/pucdata.c > > > =================================================================== > > > RCS file: /cvs/src/sys/dev/pci/pucdata.c,v > > > diff -u -p -r1.121 pucdata.c > > > --- sys/dev/pci/pucdata.c 9 Nov 2024 10:23:06 -0000 1.121 > > > +++ sys/dev/pci/pucdata.c 19 Jun 2025 18:18:40 -0000 > > > @@ -1665,6 +1665,15 @@ const struct puc_device_description puc_ > > > }, > > > > > > /* NetMos PCIe Peripheral Controller :UART part */ > > > + { /* "NetMos NM9900 UART" */ > > > + { PCI_VENDOR_NETMOS, PCI_PRODUCT_NETMOS_NM9900, 0xa000, 0x1000 }, > > > + { 0xffff, 0xffff, 0xffff, 0xffff }, > > > + { > > > + { PUC_PORT_COM, 0x10, 0x0000 }, > > > + }, > > > + }, > > > + > > > + /* NetMos PCIe Peripheral Controller :UART part */ > > > { /* "NetMos NM9901 UART" */ > > > { PCI_VENDOR_NETMOS, PCI_PRODUCT_NETMOS_NM9901, 0xa000, 0x1000 }, > > > { 0xffff, 0xffff, 0xffff, 0xffff }, > > > > > > >