General PTY and CONSOLE question

[Joel Sherrill]

Gene Smith wrote:
> 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.
>
>   
Can you dump the print[fk] output into a ring buffer so we
can look at it?
> 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.
>
>   
Do you get a backtrace?

If you call printf from the wrong context (ISR or dispatching
disabled), you can get a fatal error.

--joel
>> + 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
>>>>         
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985