For those of you who are on BusyBox's mailing list, you've already seen
this -- I was sent here for help.
Specs:
Linux: 2.6.18
Bootloader: SysLinux
Init: BusyBox (ver 1.4.0) init.
Kernel command line: console=ttyS0,115200,n,8,1
System: VersaLogic 568 (STD80/STD32 Bus, i386 based computer)
Issue: Booting on "System" I get perfect printk's to the serial
console. When the init takes over (from within an initrd), the console
begins to miss characters. I can still send write commands through the
console, however, the output of these commands is garbled. The really
odd part is when the init releases control (is killed by Linux), or when
a printk is issued, the console prints perfectly again. The next really
strange part about this is that changing "System" to my laptop -- no
problems PERIOD.
The BusyBox list directed me to LKML as this is a wider base of users
that may have experienced the same problem and could provide me an answer.
Thanks in advance for the help (and sorry for asking such a non-related
issue on the LKML),
Andy
On Mon, 12 Feb 2007, Andy Kennedy wrote:
>
> For those of you who are on BusyBox's mailing list, you've already seen this
> -- I was sent here for help.
>
> Specs:
> Linux: 2.6.18
> Bootloader: SysLinux
> Init: BusyBox (ver 1.4.0) init.
> Kernel command line: console=ttyS0,115200,n,8,1
> System: VersaLogic 568 (STD80/STD32 Bus, i386 based computer)
> Issue: Booting on "System" I get perfect printk's to the serial console.
> When the init takes over (from within an initrd), the console begins to miss
> characters. I can still send write commands through the console, however,
> the output of these commands is garbled. The really odd part is when the
> init releases control (is killed by Linux), or when a printk is issued, the
> console prints perfectly again. The next really strange part about this is
> that changing "System" to my laptop -- no problems PERIOD.
> The BusyBox list directed me to LKML as this is a wider base of users that
> may have experienced the same problem and could provide me an answer.
I've seen this happen when you accidently have multple programs attached to the
same console (even with the text-mode vga consoles)
double check that nothing else is trying to use that serial port
David Lang
David Lang wrote:
> On Mon, 12 Feb 2007, Andy Kennedy wrote:
>
>>
>> For those of you who are on BusyBox's mailing list, you've already
>> seen this -- I was sent here for help.
>>
>> Specs:
>> Linux: 2.6.18
>> Bootloader: SysLinux
>> Init: BusyBox (ver 1.4.0) init.
>> Kernel command line: console=ttyS0,115200,n,8,1
>> System: VersaLogic 568 (STD80/STD32 Bus, i386 based computer)
>> Issue: Booting on "System" I get perfect printk's to the serial
>> console. When the init takes over (from within an initrd), the
>> console begins to miss characters. I can still send write commands
>> through the console, however, the output of these commands is
>> garbled. The really odd part is when the init releases control (is
>> killed by Linux), or when a printk is issued, the console prints
>> perfectly again. The next really strange part about this is that
>> changing "System" to my laptop -- no problems PERIOD. The BusyBox
>> list directed me to LKML as this is a wider base of users that may
>> have experienced the same problem and could provide me an answer.
>
> I've seen this happen when you accidently have multple programs
> attached to the same console (even with the text-mode vga consoles)
>
> double check that nothing else is trying to use that serial port
>
> David Lang
>
<Adding Off-line chatter Between David Lang and Andy Kennedy>
>>>> Not to be thick, but it is the same disk used on two different
>>>> systems. . . one works, the other doesn't. Doesn't that imply that
>>>> there is only one thing grabbing the serial port? If not, I'll
>>>> look again. I have even had this problem with nothing in the
>>>> inittab. . . The only thing I could think is that maybe something
>>>> within the init code opens the /dev/console the wrong way. . . or
>>>> is init opening /dev/console AND /dev/ttyS0 and that is what is
>>>> causing the problem???? BUT, then why would it work on my laptop,
>>>> however, not the embedded system?
>>>
>>> with the same disk working differently on different hardware I would
>>> start looking at the drivers and interrupts. does one of the two
>>> have different hardware that could be shareing an interrupt and the
>>> other doesn't?
>>>
>>> David Lang
>> Other than looking into proc, is there another way to determine
>> this? The BIOS CMOS setup isn't that forthcoming with any
>> information -- this is an older board and has very limited settings
>> on it.
>>
>> In proc/interrupts I'm seeing nothing but serial on 4.
>>
>> Do you know if the kernel preforms any type of init on the
>> /dev/console before it writes each time? IE, from the BusyBox code,
>> I cannot see that it mucks with the /dev/console before it writes,
>> but the code is so thick I may have missed something.
>
> I don't know the answers to these questions, sorry. I'm not a kernel
> hacker, just an experianced user, and since this problem sounded
> familiar I spoke up. at this point we are getting out of my depth.
>
> David Lang
Me neither David. . . but thanks for you help.
Another piece of the puzzle (sorry I left this off before, didn't think):
SERIAL PORT TYPE: TI16750
In printk(), when something is sent from the kernel to the console, is
there an initialization that occurs prior to the actual write to the
console? How does the console interact with ttyS0 when console=ttyS0 is
supplied as command line parameter? When an init interfaces the
console, should it also send the setup information if it detects that
console=<serial device>? OR. . . could there be something specific to
this hardware that requires additional coding to get the console to work
the correct way (i.e. some form of force send, etc)?
Before, I explained how the printk comes out perfectly, then BusyBox
hoses the connection, then another printk will reset the input. The
following is a snippet of that:
> Using IPI Shortcut mode
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> Time: pit clocksource has been installed.
> Freeing unused kernel memory: 536k freed
> :l
> a l
> tr'
> z ye
> .
> gg et dil
> t'
>
>
>
>
>
> g input: AT Translated Set 2 keyboard as /class/input/input0
>
I'm in way over my head on this one since I don't know the underling
driver for the serial port on Linux. Sorry again for polluting your list
and thanks in advance (again) for any assistance you can provide me on
this issue.
Andy Kennedy
In a previous post I incorrectly stated that my serial port is a
TI16750, as this is what /proc/tty/... revealed to me. After
re-reading the product manual, I see that this is actually a 16550.
Since Linux is seeing this port as a 16750, could that explain why I'm
seeing missing characters in the transmission. After doing some
research, I found that the 16750 has a 64-byte buffer, whereas I know
this to only have a 16-byte buffer.
If my assumptions are correct and Linux is detecting this serial port
incorrectly, how can I force the serial driver to see this a 16550?
Thanks again for any assistance you can provide,
Andy Kennedy
On Wed, 14 Feb 2007 16:11:14 -0700
[email protected] wrote:
> In a previous post I incorrectly stated that my serial port is a
> TI16750, as this is what /proc/tty/... revealed to me. After
> re-reading the product manual, I see that this is actually a 16550.
> Since Linux is seeing this port as a 16750, could that explain why I'm
> seeing missing characters in the transmission. After doing some
> research, I found that the 16750 has a 64-byte buffer, whereas I know
> this to only have a 16-byte buffer.
The autodetect is pretty solid so you may well find the chip is 16750
compatible, 16550A is what is usually listed because it is what people
look for.
> If my assumptions are correct and Linux is detecting this serial port
> incorrectly, how can I force the serial driver to see this a 16550?
man setserial
> > In a previous post I incorrectly stated that my serial port is a
> > TI16750, as this is what /proc/tty/... revealed to me. After
> > re-reading the product manual, I see that this is actually a 16550.
> > Since Linux is seeing this port as a 16750, could that explain why I'm
> > seeing missing characters in the transmission. After doing some
> > research, I found that the 16750 has a 64-byte buffer, whereas I know
> > this to only have a 16-byte buffer.
>
> The autodetect is pretty solid so you may well find the chip is 16750
> compatible, 16550A is what is usually listed because it is what people
> look for.
>
> > If my assumptions are correct and Linux is detecting this serial port
> > incorrectly, how can I force the serial driver to see this a 16550?
>
> man setserial
Well, this is the most bastardized sucker I've ever seen. . . I have had
no end of trouble with it (couldn't even get a boot loader to work with
it - had to write my own). And, as luck would have it, the serial port
is no different. Using setserial, I changed the type of this port to a
16550A and all my problems went away. The question now remains: How
can I FORCE the Linux serial driver to see this as a 16550A -- As I
before stated, I know that this has a 16-byte buffer. Therefore, the
16750 with its mammoth buffer size is killing this serial port. Short
of modifying the kernel (which I'd rather not do) or including the
setserial with the kernel image (also I'd rather not do as I only have
2.3 MB of storage on this device) I need a command line parameter to
control the serial line -- is there one? A build option? PLEASE
SOMETHING???
Andy
On Wed, Feb 14, 2007 at 05:39:22PM -0700, [email protected] wrote:
> Well, this is the most bastardized sucker I've ever seen. . . I have had
> no end of trouble with it (couldn't even get a boot loader to work with
> it - had to write my own). And, as luck would have it, the serial port
> is no different. Using setserial, I changed the type of this port to a
> 16550A and all my problems went away. The question now remains: How
> can I FORCE the Linux serial driver to see this as a 16550A -- As I
> before stated, I know that this has a 16-byte buffer. Therefore, the
> 16750 with its mammoth buffer size is killing this serial port. Short
> of modifying the kernel (which I'd rather not do) or including the
> setserial with the kernel image (also I'd rather not do as I only have
> 2.3 MB of storage on this device) I need a command line parameter to
> control the serial line -- is there one? A build option? PLEASE
> SOMETHING???
No. Use setserial which is a small tool to achieve what you require.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: