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

[Andy Kennedy]

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.

So, with BusyBox's init, an inittab line of "ttyS0::respawn:-/bin/sh", 
and a kernel command line parameter of "console=ttyS0,115200n8" I get a 
nice, shiny, WORKING console and terminal on the serial port.

Thanks to all you that helped me with issue as your support led me to 
the underlying hardware issue.

Andy Kennedy