Re: BeagleBone Black doesn't boot without serial console (10.0 release)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> What he meant was that he removed the console cable.
> And the reconnecting of the console probably caused a "break", making
> the kernel enter ddb.

Actually, in my experience (with other hardware), _dis_connecting the
cable often drops into ddb.  (I haven't investigated enough to be sure
whether a framing error is enough or whether it requires a break
condition; it may even depend on which port (NetBSD port, not serial
port) is in use.)

> Since with a 3 wire serial connection there is no way for the
> hardware to detect presence or abscence of the connection

This is not actually true, though most hardware doesn't take advantage
of it.  (The way is to weakly pull the receive-data line to ground and
measure whether it's driven away from ground.  You could in theory do
the same by sensing whether the transmit-data line is loaded, but IIRC
there is no maximum input impedance specified for RS-232 input pins, so
that can't be reliable.)

> it is unclear what happened while the console cable was disconnected.

Well, note that the original post said

< If i remove the searial console from the J1
< and i poweroff + remove power + give power, the boot stops,
< i reconnect the serial console and i see this:

which I read as saying that a powercycle with the cable disconnected
freezes during boot and doesn't continue until the cable is reconnected
and the user tells ddb to quit - but with the cable connected, it works
fine.

This seems very odd to me.  I have trouble believing that a BeagleBone
is actually designed to be able to sense whether a cable is connected;
I've never seen a serial port that is.  It's even less plausible that
the NetBSD kernel boot sequence actually uses such a facility.  This
then makes me wonder what *is* going on.

The most plausible explanation I can think of is that the cable has
only three wires but the connector has additional pins jumpered, such
as connecting RTS to CTS.  But of course I don't know how plausible
that is in this case.  (For example, if the "connector" consists of
wires stuck into holes on .1" connector block, it's not plausible.)

If it were my problem, and I'd made certain it weren't something like
in-connector null-modem jumpering, I'd rig the kernel to dedicate a
chunk of memory (stolen very early in boot) to saving all console
output, a chunk large enough to not overflow before reaching a login
prompt, then examine it after boot to see what was printed before
connecting the cable.  (I'd expect this to work because it looks to me
as though the kernel is loaded and running enough to run ddb.)  I don't
know BeagleBones enough to know where I'd tap off console output, but
I'd do it as close to the hardware output as feasible, to make sure of
getting everything of interest.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B