Date: Tue, 24 May 2022 14:46:10 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Mychaela Falconia <mychaela.falconia@gmail.com>, Daniel Feenberg <feenberg@nber.org>, FreeBSD questions <freebsd-questions@freebsd.org>, Warner Losh <imp@freebsd.org>, Kyle Evans <kevans@freebsd.org> Subject: Re: Unwanted auto-assertion of DTR & RTS on serial port open Message-ID: <CANCZdfpOEkOxcBsvW7NdGd9i99bo5Dn2LjJUyAV9mex_NHcJVw@mail.gmail.com> In-Reply-To: <55AF97D3-5212-4A58-9942-3207A176C179@nimnet.asn.au> 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> <55AF97D3-5212-4A58-9942-3207A176C179@nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000009a3f7105dfc80ce6 Content-Type: text/plain; charset="UTF-8" On Tue, May 24, 2022 at 12:18 PM Ian Smith <smithi@nimnet.asn.au> wrote: > On 25 May 2022 3:09:11 am AEST, Mychaela Falconia < > mychaela.falconia@gmail.com> wrote: > > Daniel Feenberg wrote: > > > > > The man page adds the (-)rtsdtr option in version 13.1: > > > > > > https://www.freebsd.org/cgi/man.cgi?query=stty > > > > > > and I can confirm it is an invalid argument in 13.0. > > > Huh? That very same man.cgi on freebsd.org tells me that (-)rtsdtr > > first appears in 13.0 (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. > > I'm not sure if that is a typo, going on the discussion of double > negatives in the review, reposted here: > https://reviews.freebsd.org/D20031 > > The manual page footer actually says FreeBSD 13.0, and could be much > clearer about which of those settings are or are not defaults, at least to > this bear of little brain. > Yes. This was added. The default is rtsdtr, which means "do the rts/dtr wiggling when the data device is opened." The option is -rtsdtr to turn off this historic behavior. The -- is a typo that's still present in the system. I've just pushed a fix. > > > You should be able to test it with any old desktop computer pretty > > > easily though. > > > Still a massive learning curve, given that I don't regularly use > > FreeBSD (or any other alphabetic-prefix-BSD) at all, only Slackware > > Linux. It will probably be a few months before I can make the > > necessary time allocation. 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. 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... > > You don't know anyone running FreeBSD who could help with testing? > I can test. > > > Documented things tend to work. > > > It looks like the key point of my inquiry mas missed. 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 .init) tty device the unwanted auto-assertion > > of DTR & RTS will be suppressed. 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.init (for the purpose of setting the > > termios flag) will jerk the modem control lines. 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 .init > > 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. > > 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.1977 for a 'handmade' computer myself. > The .init device node exists to open the device to do initialization without line wiggle. If we go examine the tty driver in FreeBSD (it sys/kern/tty*.c) we can find the answers directly. For the init device, we just lock the device, check to see if it is still there, and unlock the device (see ttyil_open in sys/kern/tty.c, it's simple enough to follow). The normal device open will do the rts/dtr wiggle, unless it's been disabled with the option we're talking about. See ttydev_open in sys/kern/tty.c, which is a lot more complex, has lots of indirection, but clearly has a test for the option: if ((tp->t_termios.c_cflag & CNO_RTSDTR) == 0) ttydevsw_modem(tp, SER_DTR|SER_RTS, 0); So absent direct observations to the contrary, I'd say that opening the .init device will do what's desired here. > > > Have you thought of the alternative solution of cutting some wires > > > in the serial cable? > > > Ahmm, I am the _designer_ of the hardware in question. If I wanted > > to > > modify my design, I wouldn't be cutting wires, I would modify the > > design at the source. 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. > > See above. I perceive Daniel's response as only trying to be helpful. > > 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. > > 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 > encouraged to do so. > > I'll leave the tail quote below for completeness. > > Good luck and cheers, Ian > All I have to add is that there's a trivial setting to make this work as the device designer desires, despite the fact that the device uses conventions that are not RS-232 standard conventions (though most of them are somewhat dated, I'll admit, given the near total lack of modems today). It's hard to support both legacy devices and innovative devices without breaking somebody by default, and there's not been a ground-swell to change the defaults as of yet so it's rather favored the archaic traditions out of inertia. Anyway, I hope this has been helpful. I don't normally monitor the questions@ list (and hopefully I've done the right subscribe dance for this answer to appear). Warner > > > 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. These host-controlled > > boot modes are super-helpful for both hardware bring-up and firmware > > development. > > > > 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. 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. FT2232D handles all of them just fine, > > and so does Linux. 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. > > > > 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. 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. 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.init 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. > > > > 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. 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. > > > > M~ > > --0000000000009a3f7105dfc80ce6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Tue, May 24, 2022 at 12:18 PM Ian Smit= h <<a href=3D"mailto:smithi@nimnet.asn.au">smithi@nimnet.asn.au</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 25 May= 2022 3:09:11 am AEST, Mychaela Falconia <<a href=3D"mailto:mychaela.fal= conia@gmail.com" target=3D"_blank">mychaela.falconia@gmail.com</a>> wrot= e:<br> =C2=A0> Daniel Feenberg wrote:<br> =C2=A0> <br> =C2=A0> > The man page adds the (-)rtsdtr option in version 13.1:<br> =C2=A0> ><br> =C2=A0> >=C2=A0 <a href=3D"https://www.freebsd.org/cgi/man.cgi?query= =3Dstty" rel=3D"noreferrer" target=3D"_blank">https://www.freebsd.org/cgi/m= an.cgi?query=3Dstty</a><br> =C2=A0> ><br> =C2=A0> > and I can confirm it is an invalid argument in 13.0.<br> <br> =C2=A0> Huh?=C2=A0 That very same man.cgi on <a href=3D"http://freebsd.o= rg" rel=3D"noreferrer" target=3D"_blank">freebsd.org</a> tells me that (-)r= tsdtr<br> =C2=A0> first appears in 13.0 (there is a typo in the man page, the nega= tive<br> =C2=A0> form is -rtsdtr, not --rtsdtr as the man page says), ditto for t= he<br> =C2=A0> appearance of CNO_RTSDTR in termios(4), the underlying kernel<br= > =C2=A0> interface.<br> <br> I'm not sure if that is a typo, going on the discussion of double negat= ives in the review, reposted here:<br> <a href=3D"https://reviews.freebsd.org/D20031" rel=3D"noreferrer" target=3D= "_blank">https://reviews.freebsd.org/D20031</a><br>; <br> The manual page footer actually says FreeBSD 13.0, and could be much cleare= r about which of those settings are or are not defaults, at least to this b= ear of little brain.<br></blockquote><div><br></div><div>Yes. This was adde= d. The default is rtsdtr, which means "do the rts/dtr wiggling when th= e data device is opened."</div><div>The option is -rtsdtr=C2=A0to turn= off this historic behavior. The -- is a typo that's still present in t= he system. I've just pushed</div><div>a fix.</div><div>=C2=A0</div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex"> =C2=A0> > You should be able to test it with any old desktop computer= pretty<br> =C2=A0> > easily though.<br> <br> =C2=A0> Still a massive learning curve, given that I don't regularly= use<br> =C2=A0> FreeBSD (or any other alphabetic-prefix-BSD) at all, only Slackw= are<br> =C2=A0> Linux.=C2=A0 It will probably be a few months before I can make = the<br> =C2=A0> necessary time allocation.=C2=A0 Lots of other higher priorities= : I need<br> =C2=A0> to<br> =C2=A0> finish setting up my own test GSM network, I need to get my Venu= s<br> =C2=A0> board into PCB layout, etc - you get the idea.=C2=A0 Testing whe= ther or<br> =C2=A0> not<br> =C2=A0> FreeBSD's recent CNO_RTSDTR addition really fixes the design= flaw<br> =C2=A0> inherited from 1970s UNIX is only a side project here...<br> <br> You don't know anyone running FreeBSD who could help with testing?<br><= /blockquote><div><br></div><div>I can test.</div><div>=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex"> =C2=A0> > Documented things tend to work.<br> <br> =C2=A0> It looks like the key point of my inquiry mas missed.=C2=A0 I ha= ve no<br> =C2=A0> doubt<br> =C2=A0> that the newly added CNO_RTSDTR termios flag (and stty -rtsdtr u= ser<br> =C2=A0> front end to it) works as documented, meaning that on subsequent= <br> =C2=A0> opens<br> =C2=A0> of the "regular" (sans .init) tty device the unwanted = auto-assertion<br> =C2=A0> of DTR & RTS will be suppressed.=C2=A0 But the part which is= not clear at<br> =C2=A0> all, which is not documented anywhere I could find, is whether o= r not<br> =C2=A0> the act of opening /dev/ttyU1.init (for the purpose of setting t= he<br> =C2=A0> termios flag) will jerk the modem control lines.=C2=A0 If the la= tter line<br> =C2=A0> jerking still happens, then FreeBSD's recent "fix"= does NOT really<br> =C2=A0> fix<br> =C2=A0> the ancient design flaw from 1970s - or if opening of the .init<= br> =C2=A0> device<br> =C2=A0> does not assert modem control lines, *then* (and only then) we w= ill<br> =C2=A0> be<br> =C2=A0> able to celebrate, and tell the world that FreeBSD is the first<= br> =C2=A0> Unix-style OS that finally fixed the old 1970s serial port contr= ol<br> =C2=A0> misdesign.<br> <br> 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 a= nd the equipment we were dealing with back then, and still are now - having= built a couple of UART-based circuits c.1977 for a 'handmade' comp= uter myself.<br></blockquote><div><br></div><div>The .init device node exis= ts to open the device to do initialization without</div><div>line wiggle. I= f we go examine the tty driver in FreeBSD (it sys/kern/tty*.c)</div><div>we= can find the answers directly. For the init device, we just lock the devic= e, check</div><div>to see if it is still there, and unlock the device (see = ttyil_open in sys/kern/tty.c,</div><div>it's simple enough to follow). = The normal device open will do the rts/dtr wiggle,</div><div>unless it'= s been disabled with the option we're talking about. See ttydev_open</d= iv><div>in sys/kern/tty.c, which is a lot more complex, has lots of indirec= tion, but</div><div>clearly has a test for the option:</div><div>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((tp->t_termios.c_cflag= & CNO_RTSDTR) =3D=3D 0)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ttydevsw_modem(tp, SER_DTR|SER_RT= S, 0);<br></div><div><br></div><div>So absent direct observations to the co= ntrary, I'd say that opening</div><div>the .init device will do what= 9;s desired here.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"> =C2=A0> > Have you thought of the alternative solution of cutting som= e wires<br> =C2=A0> > in the serial cable?<br> <br> =C2=A0> Ahmm, I am the _designer_ of the hardware in question.=C2=A0 If = I wanted<br> =C2=A0> to<br> =C2=A0> modify my design, I wouldn't be cutting wires, I would modif= y the<br> =C2=A0> design at the source.=C2=A0 But why would I agree to modify what= I<br> =C2=A0> consider<br> =C2=A0> to be a beautiful design?=C2=A0 My approach is one of philosophi= cal<br> =C2=A0> principle: if the flawed design of 1970s Unix is the thing that&= #39;s in<br> =C2=A0> the wrong, then it is the flawed OS that needs to be fixed (whic= h in<br> =C2=A0> my case is Linux - I am merely _inquiring_ about FreeBSD), rathe= r<br> =C2=A0> than<br> =C2=A0> me giving up on my idea of elegant hw design to please the broke= n OS.<br> <br> See above.=C2=A0 I perceive Daniel's response as only trying to be help= ful.<br> <br> You've posted to a general questions list but you'd likely do bette= r on a more technical list, especially if you are expecting a very rapid re= sponse.<br> <br> At some risk to their equanimity, I've cc'd the participants in tha= t code, man page and review, who are best equipped to help, should they be = encouraged to do so.<br> <br> I'll leave the tail quote below for completeness.<br> <br> Good luck and cheers, Ian<br></blockquote><div><br></div><div>All I have to= add is that there's a trivial setting to make this work as the device<= /div><div>designer desires, despite the fact that the device uses conventio= ns that are</div><div>not RS-232 standard conventions (though most of them = are somewhat</div><div>dated, I'll admit, given the near total lack of = modems today). It's hard to</div><div>support both legacy devices and i= nnovative devices without breaking</div><div>somebody by default, and there= 's not been a ground-swell to change</div><div>the defaults as of yet s= o it's rather favored the archaic traditions out</div><div>of inertia.<= /div><div><br></div><div>Anyway, I hope this has been helpful. I don't = normally monitor the questions@</div><div>list (and hopefully I've done= the right subscribe dance for this answer to</div><div>appear).</div><div>= <br></div><div>Warner</div><div>=C2=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"> =C2=A0> > Does your device even need those signals?<br> <br> =C2=A0> Yes, I put that circuit in there for a reason: with this circuit= <br> =C2=A0> added,<br> =C2=A0> giving a -Prts (pulse RTS) command line flag to my FreeCalypso t= ools<br> =C2=A0> fc-loadtool, fc-iram, fc-xram, rvinterf etc causes a PWON (curre= nt<br> =C2=A0> hw)<br> =C2=A0> or RPWON (next upcoming hw) pulse to be given to Iota VRPC, wher= eas<br> =C2=A0> giving a -Pdtr (pulse DTR) command line flag to the same tools c= auses<br> =C2=A0> a deep reset pulse to be sent to the target.=C2=A0 These host-co= ntrolled<br> =C2=A0> boot modes are super-helpful for both hardware bring-up and firm= ware<br> =C2=A0> development.<br> <br> =C2=A0> > Would it work at a lower data rate?<br> <br> =C2=A0> What do data rates have anything to do with DTR & RTS contro= l signal<br> =C2=A0> issues?=C2=A0 But as far as data rates go, "would it work a= t a lower data<br> =C2=A0> rate" is the wrong question to ask - instead it is the duty= of<br> =C2=A0> hardware<br> =C2=A0> engineers like me to design our hardware so that the highest pos= sible<br> =C2=A0> data rates will work.=C2=A0 My Calypso GSM chip (no, I didn'= t make the<br> =C2=A0> chip,<br> =C2=A0> I only make boards with these chips on them, but I do act as a s= ort<br> =C2=A0> of<br> =C2=A0> Adoptive Mother to the chip design itself too) supports standard= UART<br> =C2=A0> baud rates up to 115200 bps, and GSM-specific (otherwise<br> =C2=A0> non-standard)<br> =C2=A0> baud rates up to 812500 bps.=C2=A0 FT2232D handles all of them j= ust fine,<br> =C2=A0> and so does Linux.=C2=A0 And when you are routinely transferring= >2 MiB<br> =C2=A0> code images (flash or run-from-RAM) in the course of firmware<br= > =C2=A0> development, that highest baud rate of 812500 bps really does he= lp.<br> =C2=A0> <br> =C2=A0> Back to FreeBSD: as of right now, I don't have any active or= even<br> =C2=A0> prospective users of my FreeCalypso GSM devices who have express= ed a<br> =C2=A0> desire to use my GSM gear with FreeBSD instead of Linux.=C2=A0 B= ut about a<br> =C2=A0> year and a half ago, when I went to battle against Linux kernel<= br> =C2=A0> gatekeepers^Wmaintainers, trying to get them to mainline my patc= h<br> =C2=A0> that<br> =C2=A0> fixes the DTR & RTS problem in Linux, one of them pointed me= to that<br> =C2=A0> FreeBSD review D20031, showing how the problem has recently been= <br> =C2=A0> addressed in FreeBSD.=C2=A0 I know for certain that the solution= which<br> =C2=A0> this<br> =C2=A0> particular Linux maintainer has been advocating for would not wo= rk<br> =C2=A0> correctly in Linux, which lacks ttyXX.init devices altogether - = but I<br> =C2=A0> am still seeking to find out whether or not FreeBSD's seemin= g-fix<br> =C2=A0> actually fixes the problem in FreeBSD, as a matter of informatio= n<br> =C2=A0> gathering.<br> =C2=A0> <br> =C2=A0> It appears that the topic at hand is too obscure and specialized= for<br> =C2=A0> anyone to have a ready answer - so it looks like there is no oth= er<br> =C2=A0> way<br> =C2=A0> to proceed than biting the bullet and getting FreeBSD installed = just<br> =C2=A0> for this test.=C2=A0 I will now go back to setting up my test GS= M network,<br> =C2=A0> but maybe I can squeeze in this FreeBSD install in between the t= est<br> =C2=A0> network and FC Venus board.<br> =C2=A0> <br> =C2=A0> M~<br> <br> </blockquote></div></div> --0000000000009a3f7105dfc80ce6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpOEkOxcBsvW7NdGd9i99bo5Dn2LjJUyAV9mex_NHcJVw>