Subject: Re: Console: Basic Kernel Interface Point
To: None <tech-kern@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: tech-kern
Date: 11/08/2003 20:02:59
anand lalgondar asked;

> Can anyone tell me how the following modules are related:
> 1. cntab
> 2. consdev
> 3. consinit function call.

There is a global pointer variable named "cn_tab"  This points
a consdev structure which holds console I/O routines (See
dev/cons.h.  Switching console is nothing other than to
change which cn_tab points to.
Your machdep.c will follow a scenario like this;

mach_init( ...)
{
    At this point your serial chip is likely working since
    your ROM monitor PMON initialized and used it for a while.
    If you want to see output on serial port at this very early
    stage of booting process (for DEBUG purpose), you need :-
    cn_tab = &txsio_cons;
    Note that txsio_cons must be written in such a way that it
    can work without any help of standard runtime (like malloc).
    So this is to be written in KSEG0 for local storage.
    Then you need to initialize some to use MIPS processor and
    kernel foundation.  It should be just ok to copy another MIPS
    port.
    Then you get a choice.  If you go the standard WSCONS way,
    All you need is to call your local ABCcnattach() here.

ABCcnattach()
{
    Do video hardware initialization first.  This part will be
    a tough task since your PMON did nothing for this
    hardware.  I hope the hardware addresses are predetermined
    and it's easy to run the whole task.
    When completed, the following is to be called :-
    wsdisplay_cnattach(&bahbahbah , ...);
    This will setup and prepare all the things to work whole
    WSCONS display subsystem.  It concludes its code path with
    cn_tab = &wsdisplay_cons. (See dev/wscons/wsdisplay.c)
    At this point no input is available.  If you just want to see NetBSD
    booting message, it's ok to end your ABCcnattach here.  I guess you
    will spend much time until your kernel gets mature enough to prompt
    any input.

    Then, if your computer had desktop style keyboard, you would
    call here :-
    wskbd_cnattach(&blablahblah ,...);
    to bind your keyboard input stream with WSCONS keyboard subsystem.
    However, you want to continue to use TXSIO instead.  What's a twist.
    As a kludge solution,
    cn_tab->cn_getc = txsio_getc;
    I think this will work as long as input is prompted in polled mode.
}

Now, I have to confess; later on whole system must swallow interrupt
driven input stream. Is there a good way to do with, say, pretending
wskbd with "raw ASCII input stream -> wskbd_input()" data path?

Toru Nishimura/ALKYL Technology