From owner-freebsd-arch Thu Jan 23 15:16:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A102037B401 for ; Thu, 23 Jan 2003 15:16:23 -0800 (PST) Received: from laas.laas.fr (laas.laas.fr [140.93.0.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7C843EB2 for ; Thu, 23 Jan 2003 15:16:22 -0800 (PST) (envelope-from ortalo@laas.fr) Received: by laas.laas.fr (8.12.7/8.12.7) with ESMTP id h0NNGE0j026837; Fri, 24 Jan 2003 00:16:15 +0100 (CET) Date: Thu, 23 Jan 2003 23:53:55 +0100 (CET) From: Rodolphe Ortalo To: Marcel Moolenaar Cc: Nicolas Souchu , arch@freebsd.org, Rodolphe Ortalo Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) In-Reply-To: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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