On Wed, 2020-06-10 at 09:24 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On Tue, Jun 09, 2020 at 03:01:14PM +0000, Joakim Tjernlund wrote: > > On Tue, 2020-06-09 at 16:22 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > On Tue, Jun 09, 2020 at 01:13:06PM +0000, Joakim Tjernlund wrote: > > > > On Tue, 2020-06-09 at 13:57 +0200, Greg KH wrote: > > > > > On Tue, Jun 09, 2020 at 11:38:49AM +0000, Joakim Tjernlund wrote: > > > > > > Hi List > > > > > > > > > > > > I was advised to come here with this problem(started on the USB list). > > > > > > > > > > > > We have a USB to RS232 bridge which presents itself as an ttyACM and the first connect after power on, > > > > > > we see some garbage chars transmitted back from USB host(PC) to out device which becomes input to > > > > > > the device. > > > > > > > > > > > > After much debugging I found that this are chars sent early in the boot process which then > > > > > > are buffered and the TTYs default to ECHO chars is the cause. > > > > > > > > > > So some program in the boot sequence is trying to send data out the > > > > > device? Why not just not do that? > > > > > > > > This is the boot console. Both u-boot and Linux prints a lot there, then init prints while starting services > > > > > > So the same device is used for boot console as well as a ttyACM device > > > later on? > > > > Not quite, the USB to RS232 chip is integrated on the device and is connected the CPUs RS232, > > there is no other port. > > I think you could compare with an external USB to RS232 puck. Senario: > > - Connect the puck to both computer and your device with an RS232 port. > > - Power on the device with the RS232 port. > > - Device "boots" and prints stuff on its RS232 port, > > > > some time passes > > > > - Open ttyACM in PC using minicom/cu > > Now early history of the boot prints are echoed back from PC to device with RS232 > > Ah, ok, so, are you sure that data isn't just "stuck" in the USB-serial > chip's buffers? That's often the case with many devices as they are > tiny and dumb and try to do the right thing most of the time (like not > drop data that was sent to it.) not 100% no but even if it was, why would the PC echo back chars because the TTY gets opened? I can see that that the chars are sent back by the PC, not just sure if the PC received them at that same time or if the PC got them when the cable was connected, stored inside some driver and written back once the TTY is opened, before one have had a chance to adjust baudrate/echo etc.? Jocke
