kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and
OXPCIe958 PCI Express chips
blortz at pacbell.net
Tue Nov 10 07:00:17 UTC 2009
The following reply was made to PR kern/134878; it has been noted by GNATS.
From: "Bill Lortz" <blortz at pacbell.net>
To: "'David Wood'" <david at wood2.org.uk>
Cc: <bug-followup at FreeBSD.org>
Subject: RE: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Mon, 9 Nov 2009 22:57:39 -0800
I'm glad to hear that I wasn't way off base.
To answer your questions:
> Most importantly, does the serial port work with your amended patch?
> Does /var/run/dmesg.boot contain a line:
> puc0: 1 UARTs detected
Yes, the serial port works great. I'm using with NTPD and have a GPS PPS
signal from a Garmin 18x LVC GPS on pin 1 (DSR) along with TX/RX and GND on
the appropriate pins. NTPD and the kernel are seeing the PPS signal and
receiving a NMEA data just fine. I don't know if NTPD tries to transmit
anything though, so it is possible the transmit function isn't working and I
don't know it. If you'd like me to test that specifically, I can probably
find something else to plug in besides the GPS and try it out - even a null
modem to another PC might work.
The relevant lines in dmesg.boot are:
pci3: <ACPI PCI bus> on pcib2
pci3: <simple comms, parallel port> at device 0.0 (no driver attached)puc0:
<Oxford Semiconductor OXPCIe952 UARTs (function 1)> mem
0xd8200000-0xd8203fff,0xd8600000-0xd87fffff,0xd8400000-0xd85fffff irq 16 at
device 0.3 on pci3
puc0: 1 UARTs detected
uart2: <16950 or compatible> on puc0
I do remember seeing some sort of weird message when I did the verbose boot
logging. Something about assigning a memory block and some conflict with
an entry (sorry about being so vague). If you do have time to come up with
an updated patch, I'll try both unknowns: "transmitting" and to get the
message from the verbose boot log for you.
The device names in /dev that it created didn't match anything I saw online,
but I took a chance and used them in NTPD which worked. The names it
created were: /dev/cuau2 /dev/cuau2.init /dev/cuau2.lock /dev/ttyu2
I used the /dev/cuau2 for NTPD by using some symbolic links.
>You did the right thing by replying to me and cc'ing
>bug-followup at FreeBSD.org
>The only suggestion I have is to send plain text emails; GNATS makes a
>bit of a mess of HTML as you can see at
Yes. I actually searched on google by the patch id and some other words
and found the "Current FreeBSD problem reports" page. I clicked on the
followup link and it wound up launching Microsoft Outlook with the correct
"to:" and "cc:" elements. I didn't realize that it was sending HTML also
until (with horror) I saw my reply on that case with all the HTML garbage
afterwards. On this message, Outlook is claiming to send Plain Text.
We'll see... :)
>I may also have a go at the parallel port and legacy UART functions.
>Could you test the parallel port if I attempt to support it, or have you
>not got any parallel devices? I suspect that most people have left
>parallel port devices behind by now - printers have used USB for many
Sure. I'll have to open the computer case and temporarily attach the
parallel port cable to the card. I'll probably have to pick up the right
kind of adapter cable, but I think that I have a couple of printers around
that can accept parallel. If not at home, I do at work.
>I'm also planning to revisit the patch to attempt to add support for
>MSI-X on these Oxford UARTs, though that requires changing some of the
>main puc code, not just pucdata.c. I want to use my OXPCIe954 based card
>for NTP master clocks - using MSI-X offers the prospect of reducing
>interrupt latency and jitter. It's just a matter of finding the
That sounds like something that would help my little NTPD/GPS clock setup.
Let me know if there is anything I can help you with.
More information about the freebsd-bugs