Hi people,
On Stuart's suggestion I'm forwarding this to the tech mailing list.
Maybe someone has some ideas on this?
To bring everyone else up to speed I'm working on adding support to 5.4
OpenBSD for an Oxford PCIe952 dual port serial card. This has been made
considerably easier by the fact that a patch for 4.9 already exists,
alas the patch never made it into the main code base.
The relevant data structures have changed between 4.9 and 5.4 and I was
bit stuck as code in /usr/src/sys/dev/pci/pucdata.c no longer compiled.
Eg. compilation of
{ PUC_PORT_TYPE_COM, 0x10, 0x1000, 4000000 * 8 * 2},
failed. This I replaced with
{ PUC_COM_POW2(5), 0x10, 0x1000 },
as PUC_COM_POW2() is now commonly used for other similar serial cards.
This compiled and the port seemed to work fine (with a loopback, data
out -> data in, OK) but the port speed setting seemed off by around 10%
(too fast). I came to this conclusion regarding the speed by measuring
port throughput. Stuart Henderson (thanks!) suggested using
PUC_COM_MUL(34)
in place of the PUC_COM_POW2(5) and indeed this now has *almost*
everything working 100%. All speeds now seem accurate when talking with
a known good serial port, EXCEPT for 9600bps! Setting the port to
9600bps results in a much faster speed, something like 25800bps
(estimated). See E-Mail below for the details.
This seems a bit bizarre to me that one and just one speed setting is
way off. Perhaps some serial guru can shed some light on what might be
going on. Any help much appreciated!
-Martin
Here is the original patch, written by Tero Koskinen (thanks!) for
OpenBSD 4.9:
http://article.gmane.org/gmane.os.openbsd.misc/184558/match=oxford
-------- Original Message --------
Subject: Re: Fwd: Re: Oxford PCIE952 patch for puc driver - OpenBSD
Date: Wed, 26 Mar 2014 15:50:42 +1300
From: Martin van den Nieuwelaar <[email protected]>
To: Stuart Henderson <[email protected]>
Hi Stuart and thanks very much for the response. I now have the card
*almost* running properly. I changed my multiplier to PUC_COM_MUL(34)
and then tested out the port. I initially saw something very strange.
The speed as measured by my throughput program seemed to increase even
more. I ran a few different tests and realised I was looking at an
exceptional case (9600bps, see below). Some results:
For each test I connected a dual port serial card port with a null modem
back to a motherboard built in serial port that I'm confident in. I
used "cu" at each end at varying speeds to check correct transmission
and reception of data.
300, 1200, 2400, 4800, 19k2, 38k4, 57k6, 115k2 all work fine. 9600 does
not! 9600 produces rubbish on both transmit and receive.
I then used my throughput testing program on the dual port serial card
port with a loop-back to itself and the 9600bps setting actually results
in throughput more in keeping with a port that would be running at
around (estimated) 25800bps. It's quite interesting - 9600bps runs
faster than 19200 :) I then tried using "cu" again back to the
motherboard serial port running at 28800 (which seems to be an
intermediate speed and the closest to 25800bps I could find that's
supported) but still rubbish.
Any thoughts on this? Maybe some bit field being mis-interpreted?
I'm not sure if we actually need 9600, but it's not the kind of bug I'd
like to leave around to have to re-discover in five years.
Are you actually involved in development/maintenance of the puc driver?
The reason we're using this dual serial card is the multi port Digi
board we initially wanted to use seems to exhibit an annoying bug. I
reported the bug to the OpenBSD bug list but unfortunately nothing came
of it.
Regards,
-Martin
On 26/03/14 11:56, Stuart Henderson wrote:
Hi Martin,
I still have the card somewhere, but no suitable machine to put it
in to test things (only box I have at hand with PCIe slots is running
esxi..)
The UART is clocked at 62.5MHz (derived from the external PCIe
clock) so the actual divisor to reach the standard 1.8432MHz reference
clock is something like 33.91.
This chip has a pre-scaler which by default approximates this as 33.875.
If we're lucky, the driver won't touch this and the default will stand,
and if that's the case then hopefully PUC_COM_MUL(34) will be close
enough to work..
Good idea to estimate based on throughput. If 34x doesn't work, can you
time it and see if you can work out roughly how far off that is? (The
pre-scaler is configured using a 6-bit integer part and 3-bit fractional
part, however the integer part is spread between 5 bits in CPR and 1
(disjoint) bit in CPR2, so if the driver is trying to reprogramme this
anywhere it might be getting it wrong; in which case a speed estimate
might help point the finger).
I hope this helps, please do let me know how you get on.
If 34x *does* work then I think we could initially add it to the
driver with fixed uart register/dma addresses.. (we are supposed to
read the number of uarts from the BAR and configure based on that; this
is mostly to handle the case where two chips are wired together in
master/slave mode, so you would have more uarts than the pci id
indicates .. but the OpenBSD driver isn't geared up for running a
device-specific attach function at the moment, and if we can at least
get the single-uart cards working that's a useful improvement.)
Stuart
--
R A Ward Ltd. | We take the privacy of our customers seriously.
Christchurch | All sensitive E-Mail attachments MUST be encrypted.
New Zealand
