linux-mips-fnet
[Top] [All Lists]

dz console serial

To: linux-mips@fnet.fr
Subject: dz console serial
From: Thomas Riemer <triemer@apt4g.a3nyc.com>
Date: Mon, 7 Sep 1998 22:08:25 -0400 (EDT)
I think that I seriously misjudged the output of my tests.
I think it comes down to me judging the stuff that was coming through
printk on the console/serial as coming through my serial driver.
When I set up my console - I chose an osconsole that was
both console and serial port - which effectively meant that I couldn't
tell which was which (duh!).   
(FYI - I'm feeling profoundly stupid at this point)

I've been working through trying to get the serial stuff to output
stuff to the serial line - once I realized that I was serously
mistaken. 

So here's how far I've gotten:

1. I wrote the sercons.c stuff - and went through the 
   compilation to make sure that it really does compile
   with all three options set/ not set. (prom,tc,dz) 
   I made the changes in promcon.c, decserial.c and dz.c
   to make them all happy.

2. This caused problems due to the fact that the serial console
   was created before the dz driver was initialized.  
   The dz driver code uses kmalloc (slab.c) - which isn't 
   allocated until the init code of the driver.  (making it 
   difficult to create a console)

3. I turned off all the promcon stuff - ripped out some of the
   basic prom routines out of promcon.c for debugging purposes...
   and have verified that when I do a printk it really is 
   hitting my dz_console_print routine.  

4. Nothing I do seems to actually generate characters to the serial
   line.  I think it comes down to me not appropriatedly initilizing
   the line - but I can't seem to see it.   

5. I know my physical serial line is fine because the prom code talks over
   the serial line just fine.  I get the "KN01 V7.0 .... etc stuff".

Here's a couple of more bits of information:
1. the connector symbols on the back of the decstation 2100 are
   misleading.  There is one that has a symbol that looks like a
   communications port   and there is another that looks like a printer
   symbol.  The communications port seems just flaky.  The prom code
   stuff just isn't
   happy talking to it.  The printer/console port works like a charm.
   I don't yet know why - nothing in the docs indicates why this would
   be so - but the docs have this disturbing property of having two
   interpretations.

2. Anyone know how to force the decstation prom back to the console?
   One of my two decstations seems to be talking permanently to the 
   communications port.  I can send it a control C and it really does 
   reboot - It goes through the process of the counting memory and then
   does nothing - and accepts nothing.   It never comes up with ">>" - 
   which is a bummer.   The other machine - I was smart enough not 
   to set to the same setting.  (unplugging keyboards/mouse/monitor
   combos just doesn't seem to have any impact at all).

3. Every single time that I've compiled kermit under linux in the 
   past 3 years - it has invariably been a hairy mangling job. 
   I've never gotten kermit to compile straight out of the box. 

4. To get the serial line to work as a console you need to 
   "enable" it from the prom console.  Just typing enable 
   at the prom lists the things that are defined as available 
   for consoles. 
   
So here's a question:

   All of the serial driver procedures that I've been looking at
uses a struct tty_struct * to get at the member driverdata.
Why is it that the console does not have a tty_struct associated with it?

I never realized how difficult the stuff under the hood can be.

-Tom
-----------------------------------------------------------------------
Given enough eyeballs all bugs seem shallow.

<Prev in Thread] Current Thread [Next in Thread>