On 2020-06-09 17:01, 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
It sounds like either the USB-RS232 device or the ttyACM driver are
holding
the incoming data over RS232 even though there is no open connection
over
USB. My first suspicion would be the USB-RS232 device.
Also, doesn't it help to open minicom with echo off?
Maarten
PS:
Oliver, please help me make this clear. You sent me here :)
> > > When the TTY is opened, any chars in the this buffer is ECHOed back over USB to the device,
> > > before one has a chance to disable ECHO. The device then thinks these chars are regular input.
> >
> > Wait, you said something in the boot process did write to the device,
> > which would have caused the tty to be opened then, right?
>
> well, boot process of the device prints and it is enough for the USB cable to be attached but not opened by any app.
> The device just see an UART and prints when UART is initialized.
What tool does that? Why not fix that?
> > > Seems to me that this behaviour is unwanted in general and and app. should get a chance to flush/discard
> > > any chars so this does not happen.
> >
> > Where are the characters coming from that would need to be flushed?
>
> Early output from boot, basically whatever prints just after connecting the USB cable.
Then don't have boot print to that device :)
> > When should characters be flushed exactly?
>
> Whatever is in the buffers before opening the tty.
But what is supposed to happen to the data that was sent to it while
it
was "closed"?
> The terminal app(like cu) tries to flush any input when it starts, just to avoid any old chars in the
> queue but it is to late then.
I strongly just suggest having userspace not write to the device to
start with, that would solve this, right?
It is not user space, it is the serial driver in kernel writing this
back automatically.
Jocke
thanks,
greg k-h
