Re: Boot (i386) hangs in absence of video hardware

[Scrap Happy <scrap%GMX.com@localhost>]

Hi Martin,

On 3/4/2011 2:19 PM, Martin Husemann wrote:
> On Fri, Mar 04, 2011 at 02:04:56PM -0700, Scrap Happy wrote:
> > I would prefer to understand what the problem really *is*
> > than to go flailing at possible fixes.  I.e., knowing
> > how the kernel is talking *to* the hardware at various
> > stages of the process (since the boot process begins AS IF
> > the console has already been redirected to the serial port;
> > so, how orderly will the handoff -- BIOS to kernel -- be
> > when/if it happens?).  Otherwise, I'll just waste time
> > getting back to exactly the same problem...  :<
>
> Well, as you describe it, it looks like this:
>
>   - BIOS emulates the vga (int 10) output functions by talking to the
>     serial console

Agreed.  While it would be *possible* that the Windows OS intended
for this box (CoA claims "Windows 2000 Svr No Clstr SAK 2.0 1-4 CPU)
could have been mangled to talk directly to this hardware, the
fact that the NetBSD bootloader *also* likes talking to it
(without any prior knowledge of its existence!) suggests it is
some ISA mechanism.

>   - the bootloader only uses bios calls to do input/output

OK, as above.

>   - bootloader loads kernel (output works so far), then passes console
>     device used, disk where it loaded the kernel from, etc., to the kernel

The "problem" being that it is passing "VGA" as the device
since it can't see beyond the BIOS hooks to know what *real*
hardware it has been talking to.

>   - kernel takes over and imediately talks directly to hardware - assuming,
>     as it has been told by the bootloader, that there is a functional vga
>     device

So, the only output that the kernel sends through the BIOS
is the initial segment size information?  I.e., all of the
probe information etc. is sent directly to the "hardware"?

Why would the kernel flinch if the hardware was *absent*?
(does it expect to *see* something, someplace, and get
confused when that something isn't there?)

If that is the case, then the boot process should hang at
the first (?) "VGA" access, right?  (I can time when the
disk activity indicators go silent in the "won't boot"
configuration)

> Now the problem with "consdev com0" could either be serial port
> parameters, or the bios not allowing access to com0 - as it is busy
> with the vga emulation.

When does the switch to the specified consdev take place -- right
after the \n terminating "consdev com0"?  If so, then I should be
able to change the laptop (serial terminal) serial port parameters
and continue to interact with the boot loader.  I.e., "help"
should still emit some canned text over that serial interface.

Of course, being a bastard box, the BIOS is also a bastard.  So,
its settings for "Console Redirection" and "COM0" are magical
(as are any potential interactions between them).  Perhaps I will
try disabling the console (in the BIOS) entirely and see what
the kernel thinks the real console was?

[I should grep the bootloader sources to see what it passes to
the kernel in this "default" case]

> My bet would be: once you get the bootloader to pass "console is com0 at
> speed ...." to the kernel, everything should work fine. A pretty common
> hardware with similar bios emulation is the Soekris stuff, maybe you can
> find some hints in the mailing list archives googling for that.

Thanks, I'll poke around.

--don