Date: Wed, 22 Jan 2003 23:12:32 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Nicolas Souchu <nsouch@free.fr> Cc: arch@FreeBSD.ORG, Rodolphe Ortalo <ortalo@laas.fr> Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> In-Reply-To: <20030123075556.A10370@armor.fastether> References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030122220029.GD590@dhcp01.pn.xcllnt.net> <20030123075556.A10370@armor.fastether>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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). Goto http://people.freebsd.org/~peter/ia64.diff and search for sio_machdep.c and vga_machdep.c. The low-level console code for sio(4) is in sio_cons.c in the diff. So far it works out well, but I don't yet have sparc64 specific feedback on the approach... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030123071232.GA80532>