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.
|