Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jan 2003 23:53:55 +0100 (CET)
From:      Rodolphe Ortalo <ortalo@laas.fr>
To:        Marcel Moolenaar <marcel@xcllnt.net>
Cc:        Nicolas Souchu <nsouch@free.fr>, arch@freebsd.org, Rodolphe Ortalo <ortalo@laas.fr>
Subject:   Re: the mythical syscons redesign document ( was Re: Porting wscons )
Message-ID:  <Pine.LNX.4.21.0301232326380.485-100000@tempest.rod.fr>
In-Reply-To: <20030123071232.GA80532@dhcp01.pn.xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 22 Jan 2003, Marcel Moolenaar wrote:

> On Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote:
> > > > The approach of KGI is to provide a very basic/minimal driver for console boot
> > > > that can be overlaped later by fully probed graphic board drivers. This is
> > > > somehow how VGA adapter is organized, with the video_switch used immediatly
> > > > and later the vga_isa.c glue-code for newbus full attachement.
> > > 
> > > This is what makes it non-portable and why we have problems getting
> > > it to work in non-PC, non-ISA environments.
> > 
> > Not because of a minimal driver, but because syscons and even more pcvt
> > make assumptions on the features provided by the driver (font, text modes...)
> 
> Ok. I didn't look at that specific part of the problem space. I mostly
> worry about the use of memory addresses and I/O ports that are specific
> to a platform or configuration and thus non-portable.

Indeed, I think that the VGA boot driver of KGI is really VGA-specific
(maybe i386-specific then in fact). On a Sun for example, I guess a boot
driver using the open firmware should be needed.

> > > Booting a notebook in text mode looks ugly and I can imagine that
> > > early boot environments can be graphical as well. I prefer not to
> > > fixate on text-only video modes for the low-level console, even
> > > though we probably won't use it for anything but text.
> > 
> > I agree. But booting a true PCI/AGP (and not ISA) graphic card without
> > the bus stuff initialized seems very hard.
> 
> Yes and no. The PCI standard has defined the legacy memory address of
> the frame buffer and the legacy I/O port range for compatibility. I
> expect that we can safely probe that. I don't know how this works in
> non-PCI system though...
> 
> The approach I took on the ia64 branch is to have a xxx_machdep.c in
> sys/$ARCH/$ARCH for every device xxx that can be a low level console.
> In the file xxx_machdep.c you do whatever MD specific thing you need
> to do to construct a tag and handle for use by the MI code for device
> xxx. When bus enumeration happens, you compare the tag and handle of
> the low-level console with the tag and handle of the device that's
> being probed if you want to know if the device that's being probed is
> the console or not (you don't want to reset the device if it's the
> console for example).

Why do you want to take so much care wrt the initial boot device?
 If you want to preserve the console display across the switch to a new
display driver isn't it possible to do this at a higher level? E.g.: save
the console output somewhere, close() the boot driver, open the new
driver(), set an adequate text (or text-on-graphic) mode, restore the
console output, and then proceed.
 Are there other reasons that motivated a more careful approach?

Rodolphe


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0301232326380.485-100000>