Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2022 04:17:20 +1000
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Mychaela Falconia <mychaela.falconia@gmail.com>,Daniel Feenberg <feenberg@nber.org>,freebsd-questions@freebsd.org
Cc:        Warner Losh <imp@freebsd.org>,Kyle Evans <kevans@freebsd.org>
Subject:   Re: Unwanted auto-assertion of DTR & RTS on serial port open
Message-ID:  <55AF97D3-5212-4A58-9942-3207A176C179@nimnet.asn.au>
In-Reply-To: <CA%2BuuBqbJtZFfPm-jMou9A=57-MGbRHKPzKu2aYn%2B-=A0rSQiPQ@mail.gmail.com>
References:  <CA%2BuuBqZ=PJMcuWj%2Bz3kGAy0bG=1S8oRXUAaO13PPqTea%2BoS04Q@mail.gmail.com> <b3ca19e-e7b2-92b6-dba1-d9734c2b3a11@nber.org> <CA%2BuuBqbJtZFfPm-jMou9A=57-MGbRHKPzKu2aYn%2B-=A0rSQiPQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25 May 2022 3:09:11 am AEST, Mychaela Falconia <mychaela=2Efalconia@gmai=
l=2Ecom> wrote:
 > Daniel Feenberg wrote:
 >=20
 > > The man page adds the (-)rtsdtr option in version 13=2E1:
 > >
 > >  https://www=2Efreebsd=2Eorg/cgi/man=2Ecgi?query=3Dstty
 > >
 > > and I can confirm it is an invalid argument in 13=2E0=2E

 > Huh?  That very same man=2Ecgi on freebsd=2Eorg tells me that (-)rtsdtr
 > first appears in 13=2E0 (there is a typo in the man page, the negative
 > form is -rtsdtr, not --rtsdtr as the man page says), ditto for the
 > appearance of CNO_RTSDTR in termios(4), the underlying kernel
 > interface=2E

I'm not sure if that is a typo, going on the discussion of double negative=
s in the review, reposted here:
https://reviews=2Efreebsd=2Eorg/D20031

The manual page footer actually says FreeBSD 13=2E0, and could be much cle=
arer about which of those settings are or are not defaults, at least to thi=
s bear of little brain=2E

 > > You should be able to test it with any old desktop computer pretty
 > > easily though=2E

 > Still a massive learning curve, given that I don't regularly use
 > FreeBSD (or any other alphabetic-prefix-BSD) at all, only Slackware
 > Linux=2E  It will probably be a few months before I can make the
 > necessary time allocation=2E  Lots of other higher priorities: I need
 > to
 > finish setting up my own test GSM network, I need to get my Venus
 > board into PCB layout, etc - you get the idea=2E  Testing whether or
 > not
 > FreeBSD's recent CNO_RTSDTR addition really fixes the design flaw
 > inherited from 1970s UNIX is only a side project here=2E=2E=2E

You don't know anyone running FreeBSD who could help with testing?

 > > Documented things tend to work=2E

 > It looks like the key point of my inquiry mas missed=2E  I have no
 > doubt
 > that the newly added CNO_RTSDTR termios flag (and stty -rtsdtr user
 > front end to it) works as documented, meaning that on subsequent
 > opens
 > of the "regular" (sans =2Einit) tty device the unwanted auto-assertion
 > of DTR & RTS will be suppressed=2E  But the part which is not clear at
 > all, which is not documented anywhere I could find, is whether or not
 > the act of opening /dev/ttyU1=2Einit (for the purpose of setting the
 > termios flag) will jerk the modem control lines=2E  If the latter line
 > jerking still happens, then FreeBSD's recent "fix" does NOT really
 > fix
 > the ancient design flaw from 1970s - or if opening of the =2Einit
 > device
 > does not assert modem control lines, *then* (and only then) we will
 > be
 > able to celebrate, and tell the world that FreeBSD is the first
 > Unix-style OS that finally fixed the old 1970s serial port control
 > misdesign=2E

Mychaela, I'm not sure that telling everyone that what they've been doing =
for 50 years was mistaken will cut much ice; please respect people and the =
equipment we were dealing with back then, and still are now - having built =
a couple of UART-based circuits c=2E1977 for a 'handmade' computer myself=
=2E

 > > Have you thought of the alternative solution of cutting some wires
 > > in the serial cable?
=20
 > Ahmm, I am the _designer_ of the hardware in question=2E  If I wanted
 > to
 > modify my design, I wouldn't be cutting wires, I would modify the
 > design at the source=2E  But why would I agree to modify what I
 > consider
 > to be a beautiful design?  My approach is one of philosophical
 > principle: if the flawed design of 1970s Unix is the thing that's in
 > the wrong, then it is the flawed OS that needs to be fixed (which in
 > my case is Linux - I am merely _inquiring_ about FreeBSD), rather
 > than
 > me giving up on my idea of elegant hw design to please the broken OS=2E

See above=2E  I perceive Daniel's response as only trying to be helpful=2E

You've posted to a general questions list but you'd likely do better on a =
more technical list, especially if you are expecting a very rapid response=
=2E

At some risk to their equanimity, I've cc'd the participants in that code,=
 man page and review, who are best equipped to help, should they be encoura=
ged to do so=2E

I'll leave the tail quote below for completeness=2E

Good luck and cheers, Ian


 > > Does your device even need those signals?

 > Yes, I put that circuit in there for a reason: with this circuit
 > added,
 > giving a -Prts (pulse RTS) command line flag to my FreeCalypso tools
 > fc-loadtool, fc-iram, fc-xram, rvinterf etc causes a PWON (current
 > hw)
 > or RPWON (next upcoming hw) pulse to be given to Iota VRPC, whereas
 > giving a -Pdtr (pulse DTR) command line flag to the same tools causes
 > a deep reset pulse to be sent to the target=2E  These host-controlled
 > boot modes are super-helpful for both hardware bring-up and firmware
 > development=2E

 > > Would it work at a lower data rate?

 > What do data rates have anything to do with DTR & RTS control signal
 > issues?  But as far as data rates go, "would it work at a lower data
 > rate" is the wrong question to ask - instead it is the duty of
 > hardware
 > engineers like me to design our hardware so that the highest possible
 > data rates will work=2E  My Calypso GSM chip (no, I didn't make the
 > chip,
 > I only make boards with these chips on them, but I do act as a sort
 > of
 > Adoptive Mother to the chip design itself too) supports standard UART
 > baud rates up to 115200 bps, and GSM-specific (otherwise
 > non-standard)
 > baud rates up to 812500 bps=2E  FT2232D handles all of them just fine,
 > and so does Linux=2E  And when you are routinely transferring >2 MiB
 > code images (flash or run-from-RAM) in the course of firmware
 > development, that highest baud rate of 812500 bps really does help=2E
 >=20
 > Back to FreeBSD: as of right now, I don't have any active or even
 > prospective users of my FreeCalypso GSM devices who have expressed a
 > desire to use my GSM gear with FreeBSD instead of Linux=2E  But about a
 > year and a half ago, when I went to battle against Linux kernel
 > gatekeepers^Wmaintainers, trying to get them to mainline my patch
 > that
 > fixes the DTR & RTS problem in Linux, one of them pointed me to that
 > FreeBSD review D20031, showing how the problem has recently been
 > addressed in FreeBSD=2E  I know for certain that the solution which
 > this
 > particular Linux maintainer has been advocating for would not work
 > correctly in Linux, which lacks ttyXX=2Einit devices altogether - but I
 > am still seeking to find out whether or not FreeBSD's seeming-fix
 > actually fixes the problem in FreeBSD, as a matter of information
 > gathering=2E
 >=20
 > It appears that the topic at hand is too obscure and specialized for
 > anyone to have a ready answer - so it looks like there is no other
 > way
 > to proceed than biting the bullet and getting FreeBSD installed just
 > for this test=2E  I will now go back to setting up my test GSM network,
 > but maybe I can squeeze in this FreeBSD install in between the test
 > network and FC Venus board=2E
 >=20
 > M~




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55AF97D3-5212-4A58-9942-3207A176C179>