[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
General PTY and CONSOLE question
- Date: Fri, 19 Sep 2008 18:51:47 -0400
- From: gds at chartertn.net (Gene Smith)
- Subject: General PTY and CONSOLE question
Joel Sherrill wrote:
> Thomas Doerfler wrote:
>> during startup RTEMS tries to open "dev/console". If you don't a device
>> of this name, you will run into trouble. PTY will be initialized later
>> (AFAIK), so this can't be a replacement.
> Depends on the RTEMS version. This is the
> progression right:
> + in 4.6 /dev/console was required and if open() on it
> failed, it was a fatal error.
> + in 4.7.1, the open could fail without causing a fatal error.
> This made the console optional but open() always got
> pulled in.
> + In 4.8, this routine was refactored so there could be
> a "no-console.c" optional stub to avoid open() being
I'm still at 4.8 right now but having a problem when I don't include
CONSOLE_DRIVER_TABLE_ENTRY in my Device_drivers array. I don't see
open() being called since dbgu_init() is not called (and dbgu_init() is
called when CONSOLE_DRIVER_TABLE_ENTRY present). However, I can see
RTEMS detect a fatal error of some sort and shut down. Also, can't
telnet to RTEMS. Only when I include the CONSOLE... driver entry does
RTEMS keep running and I can telnet in.
My BSP (modified csb337) still includes the uart code (in dbgu.c,
customized for my uart) but it is basically a NOP right now. The
dbgu_init() function does nothing to the h/w. The dbgu_write() just
returns 1 (indicating the char was sent) while dbgu_read() just returns
-1 (indicating that nothing received). Those are the only functions that
touch the uart so print[fk] must call them.
I can't really tell exactly where the RTEMS shutdown (rtems_panic
called) is occurring because I have no serial port printing and my debug
environment is still kind of flaky. However, I think it might be
occurring during a printf from what I can tell (but not necessarily the
1st printf). Also, while stepping with gdb in a printf call, somehow I
*seemed* to end up in some networking/socket code (this is with console
driver disabled). Like I said, my debugger is flaky so not sure if this
was real or not.
> + Basically the same in 4.9.
>> Maybe the NULL device can help you as a dummy replacement of the console?
> When you had to have /dev/console, you could link /dev/console
> to /dev/null and get by. Now you only need to do that if you print
> to stdout and assume that it is automatically setup for you.
>> Gene Smith wrote:
>>> Does a PTY driver require the console driver? When I remove
>>> CONSOLE_DRIVER_TABLE_ENTRY from the Device_drivers array I get no pty
>>> login. Are they somehow tied together? Examples I have seen on the list
>>> have the both.
>>> I need to run with my UART h/w disabled (I can't have it on, I need its
>>> I/O ports for other functions). However I would still like the PTY
>>> login/shell to be working (for now).
>>> The other problem also might be that print[kf] calls are still present
>>> in the code. printk still tries to send chars to the uart even when
>>> CONSOLE is gone. I am not sure about printf.