From: Theo Buehler <tb@theobuehler.org>
Subject: puc(4): make NM9900 attach
To: tech@openbsd.org
Date: Thu, 3 Jul 2025 10:49:00 +0200

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
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.

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
	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

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 },