Possible Bug, or Possibly don't know what I'm doing.

[Denis Vlasenko]

On Thursday 15 February 2007 17:19, Andy Kennedy wrote:
> Bernhard Fischer wrote:
> > On Fri, Feb 09, 2007 at 01:45:33PM -0600, Andy Kennedy wrote:
> >   
> >> Andy Kennedy wrote:
> >>     
> >>> To restate my problem (in case some kind developer decides to help me):
> >>>
> >>> When I have the kernel command line parameter "console=ttyS0,115200n8" 
> >>> I get nice neat output on the serial line up until the init runs.  As 
> >>> soon as init runs, I get missing chars.  So, I replace the BusyBox 
> >>> init with minit, compiled from source and using the uCLibC gcc that I 
> >>> let buildroot make for me.  Same problem.  For some reason, when the 
> >>> system initializes -- after the kernel has reported all of its output, 
> >>> my serial console goes splat.  When I initialize the console using 
> >>> BusyBox (/sbin/getty -L ttyS0 115200 vt100) I get "X n", where X is 
> >>> {'i', 'g', 's', 'o', 'l', 'm'}, but I cannot find a pattern in it.  
> >>> One of these letters will appear each time I send enter.
> >>>
> >>> I have tried everything I can think of.  There is no script setting 
> >>> any of the line speeds -- in fact, I have even attempted to remove the 
> >>> scripts and still get the same thing.  Removing the 
> >>> console=ttyS0,115200n8 (or attempting any variant of it) has no 
> >>> affect, except without the console= I get no good output on the line.  
> >>> The only thing I haven't attempted yet is to replace the getty with an 
> >>> equivalent to see if that makes a difference.  I have also tried 9600, 
> >>> 38400, 19200, with E8, O8, 2 stop bits, and 1 stop bit in just about 
> >>> every combination, but I still cannot get a serial console.
> >>>
> >>> Can anyone offer a suggestion as to how I might fix this -- or some 
> >>> other place to start?
> >>>
> >>> Thanks in advance for any help you can offer,
> >>> Andy
> >>>       
> >> Okay, now I'm really confused.  Here is what I have done so far:
> >> Made my laptop boot with a console on ttyS0 and put a login shell on it 
> >> (to verify that I can do it -- I was beginning to think maybe I needed 
> >> to remove Linux from my computer and get rid of all of  it being to 
> >> stupid to own a computer, much less program an embedded system) and I 
> >> had no problems.  So, I took my syslinux disk and booted from it (the 
> >> SAME DISK THAT I'M USING TO BOOT THE EMBEDDED SYSTEM).  Not a problem, 
> >> everything comes up as you would expect.
> >>
> >> Given that this test worked there is one of about three possibilities:
> >> 1) Cable issue.  Tested my serial cable on another embedded system (an 
> >> Arcom Viper), checks out.  Replaced the break-out cable from the 
> >> embedded system -- failed.  Tried a known good cable -- failed.  Tested 
> >> a different VersaLogic board -- failed.  Now, here is the part that 
> >> really yanked me around:
> >>
> >> The last time I booted the machine I didn't have the keyboard connected 
> >> to the break-out cable.  The boot went as it normally does except the 
> >> keyboard driver never reported a keyboard -- duh, it wasn't plugged in.  
> >> BusyBox init takes over the console and prints all kind of whack.  I 
> >> plug in the keyboard and the keyboard driver prints a perfect string 
> >> onto the serial console.
> >>
> >> I've looked through the code to see what type of initialization init is 
> >> doing to the console, but it doesn't look like it is re-initializing the 
> >> sucker at all.  The only thing that I can think is that BusyBox is doing 
> >> something that Linux doesn't do to interact with the ttyS0 so I'm not 
> >> getting what I expect.
> >>     
> >
> > IIRC busybox's init doesn't do anything special for serial lines.
> >
> > As vda already suggested, better seek help on lkml or try to find
> > somebody to whom that <char><space><char>.. pattern sounds familiar.
> >   
> Found the problem.  Wasn't a bug in BusyBox, wasn't that I didn't know 
> what I was doing either.  Found that the computer that has the UART 
> 16550A is configured such that the serial detection algorithm of Linux 
> didn't see it as a 16550A, but a 16750.  Difference being that the 
> 16550A has a 16-Byte buffer, whereas the 16750 has a 64-byte buffer.  
> The kernel, using the 16750 command set, waited for the buffer to get 
> full, thus anything written to the serial line was getting trashed.  I 
> have modified my kernel, for this specific computer, to "manually" set 
> the kernel to 16550A as the serial interface.

In case you will try to submit permanent fix for this into
mainlike kernel - I think that the only place where kernel
can decide that it is a 16750 is here:

drivers/serial/816:8250.c

        /*
         * No EFR.  Try to detect a TI16750, which only sets bit 5 of
         * the IIR when 64 byte FIFO mode is enabled when DLAB is set.
         * Try setting it with and without DLAB set.  Cheap clones
         * set bit 5 without DLAB set.
         */
        serial_outp(up, UART_LCR, 0);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status1 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, UART_LCR_DLAB);
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO | UART_FCR7_64BYTE);
        status2 = serial_in(up, UART_IIR) >> 5;
        serial_outp(up, UART_FCR, UART_FCR_ENABLE_FIFO);
        serial_outp(up, UART_LCR, 0);

        DEBUG_AUTOCONF("iir1=%d iir2=%d ", status1, status2);

        if (status1 == 6 && status2 == 7) {
                up->port.type = PORT_16750;
                up->capabilities |= UART_CAP_AFE | UART_CAP_SLEEP;
                return;
        }
--
vda