General PTY and CONSOLE question

[Gene Smith]

Joel Sherrill wrote:
> Thomas Doerfler wrote:
>> Gene,
>>
>> 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
>    referenced.

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.
> 
> --joel
>> wkr,
>> Thomas.
>>
>>
>> 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.
>>>
>>> Thanks,
>>> -gene