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>