In message <200208202145.g7KLjZW01118@fearless-vampire-killer.waterside.net>, 
I wrote:

[...new SAB driver not being happy on my U5...]

-> Right, that part I know is the fault of my term server... I haven't yet
-> figured out how to do hardware flow control w/out also getting the drop-
-> on-loss-of-DTR behaviour.  For this port it shouldn't matter, but I did
-> it globally when setting up, so it inherited this behaviour.
-> 
-> However, the drop of the line by the term server seems to hang the boot
-> process (though DTR does come back up, since I re-connect); when I connect
-> again, the port is frozen, and moreover, the machine does not come up to
-> the point where I can get at the network, either (I'd say I have a getty
-> misconfiguration if the boot continued, I was able to get in via the 'net
-> but not serial console, but in this case the box doesn't even answer ARPs).
-> 
-> I'll take the term server out of the picture tonight (or at least try it
-> with modem-control disabled) to see if that helps any.

So I poked at it tonight (when I really should have been doing stuff for
work, alas 8-), and here's what I found.

First, I'm running with console on ttyb (needed a nine-pin connector as I
had no 9<->25 converters and both my termserver adaptors and null-modem
cables all had 9-pin ends, in case anyone cares 8-), which *is* the one
significant fact here.  I did turn off the "drop-on-DTR behaviour" on my
term server, and it (unsurprisingly) made no difference...

What happens is that sabtty_console_flags() gets confused by the lack of
"input-device" / "output-device" properties on "/chosen", and then by
default declares ttya to be the console... I'm not yet sure why that
causes the boot process to wedge, but changing the default channel to
a "1" (ie, ttyb), makes my machine boot succesfully, since it now defaults
to console on ttyb.

A conversation with Matt Green and Valeriy Ushakov (where much clue was
impated to me on the magick world of OFW 8-), concluded that we should
probably use the OFW stdin/stdout instead of the "input-device" and 
"output-device" properties, since those are more static and stdin/stdout
can be redirected more easily.  From the instance handles of the stdin
and/or stdout, we should be able to map back to a path, and then check
if the path ends in ":a" or ":b" for ttya/ttyb respectively (assuming
the package matches our node as the code checks now).

For example, the path to my console device, as reported by consinit.c
is: "/pci@1f,0/pci@1,1/ebus@1/se@14,400000:b"

[As a side note, there are no "input-device" nor "output-device" props
 on "/chosen"... Those were probably meant to come from "/options", 
 which would have probably fixed this as well, but is likely not the
 long-term desirable fix...]

If I get a chance in the next few days, I'll try and implement this and
see that it works; if not, I'll at least file it as a PR with the above
commentary (it's bedtime for me now).

--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill