I honestly don't understand how to calculate the baudrate, the following hack:
switch (baud) {
case 9601: { tcr = 4; cpr = 32; quot = 406; } break;
case 9602: { tcr = 8; cpr = 16; quot = 406; } break;
case 9603: { tcr = 16; cpr = 8; quot = 406; } break; /* tcr will be masked to 0 */
}
*frac = (cpr << 8) | (tcr & OXSEMI_TORNADO_TCR_MASK);
I believed that they should give the same baudrate, but I get these baudrates:
9600 -> 10700 tcr = 9; cpr = 9; quot = 643; /* Use standard calculations, not hack */
9601 -> 38400 tcr = 4; cpr = 32; quot = 406;
9602 -> 19200 tcr = 8; cpr = 16; quot = 406
9603 -> 9600 tcr = 16; cpr = 8; quot = 406;
On 2022-09-13 18:19, Maciej W. Rozycki wrote:
Hi Anders,
Sorry to cause you trouble.
I really don't know what to do here, sorry. Are you saying a specific
commit has broken this? If so, did you test if you made a change it
fixed the issue?
Yes, commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c broke the one to one
correspondence
between programmed and actual baudrate; reverting it (and
9c5c8aaed50bf3478073ab51b8b1f3f5327d3cfa
that builds on that patch) restores the expected functionality (i.e. you get
the baudrate you ask for)
on 5.19.8.
I have implemented the calculation using parameters from original OxSemi
datasheets and verified this code across three architectures available to
me (POWER9, RISC-V, 32-bit x86) and a couple of cards made by different
manufacturers connected to a non-OxSemi serial device each at the other
end. I have checked the usual baud rates of up to 460800bps. Higher baud
rates work too, though I could only try them between OxSemi devices, so
actual rates were not verified for correctness.
And offhand I can say it works just fine at 230400bps with 6.0.0-rc2 as
at commit 10d4879f9ef0 and my RISC-V machine (using an EXSYS EX-44171
1S+1P port PCIe option card, built around the OXPCIe952 too) talking to a
remote console server in my lab. I don't have an oscilloscope available
to check actual waveforms produced.
What do you suggest happen here?
Either there is a bug in the code, or the chipset on my card (a Delock 2xRS232
card) is not a true oxford
chipset (the package and PCI id's says that they are).
A bug can never be ruled out. I doubt that Delock would use a fake chip
or indeed that anyone would choose to clone an OxSemi part, which seems
fairly complex to me for a serial port.
Since the chip seems to be discontinued since 2014 (see
https://www.mouser.com/PCN/PLX_Technology_2013_8.pdf),
I think a revert would not be uncalled for.
The problem is the original calculation is inaccurate enough for the
serial interface not to communicate correctly at higher baud rates. I
found setting two stop bits while talking to a remote end that has one
stop bit set a possible workaround for some cases, but why not do the
calculation correctly in the first place?
If you're willing to debug it, then I'll be more than happy to supply you
with diagnostic patches, some of which I made in the development of the
fix. Also what processor architecture do you use the interface with?
Maciej
--
Anders Blomdell Email: anders.blomdell@xxxxxxxxxxxxxx
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118
SE-221 00 Lund, Sweden
