On 948857715 seconds since the Beginning of the UNIX epoch
Miles Nordin wrote:
>
>It might actually be worse than that.  My Sun's continue using OpenPROM
>for output until the framebuffer attach, which happens fairly late in the
>boot process (although, still before things like the ``root on?'' prompt).
>Much of the kernel boot info might render too late for said info to
>usefully diagnose panics or freezes. But, it's better than nothing, and
>might be the best that can be done under the circumstances.

Actually on alpha, the TGA attach routines run early and initialize the
frame buffer before any text is output, IIRC.  So, they don't go through
firmware at all.

>For example, on the alpha port it might be needed, as there is no
>proven-good way to initialize an arbitrary chip--Digital tries to do it by
>running the x86 VGA BIOS under emulation.  When/if XF86-4.0 inspires VGA
>console support on the alpha, the lucky implementor may find himself or
>herself convinced it's better to support a limited subset of chips by
>direct programming than to rely on the srm console's hit-or-miss x86
>emulation that's as likely to lock a box hard as actually initialize the
>card. (i'm a bit _beyond_ convinced of this, personally.  frankly i think
>even a meager effort would improve the number of cards that work over what
>srm provides.) in which case, the bitmap console would end up being less
>work since the Sane Framebuffer Architecture uses it anyway.

The problem with not using the VGA emulation is how do you talk to the
SRM (well, I guess serial console), but you need to convince the SRM to
not do its thing and NetBSD doesn't have control of things early enough
to do that.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==