From owner-freebsd-arch Thu Jan 23 13:41:51 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 9A9C537B405 for ; Thu, 23 Jan 2003 13:41:49 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3061843EB2 for ; Thu, 23 Jan 2003 13:41:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NLflMW036139; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0NLflSx001267; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0NLfljZ001266; Thu, 23 Jan 2003 13:41:47 -0800 (PST) (envelope-from marcel) Date: Thu, 23 Jan 2003 13:41:47 -0800 From: Marcel Moolenaar To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123214147.GA1218@dhcp01.pn.xcllnt.net> 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> <20030123071232.GA80532@dhcp01.pn.xcllnt.net> <20030123205808.GA17281@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123205808.GA17281@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.3i 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 Fri, Jan 24, 2003 at 07:58:08AM +1100, Peter Jeremy wrote: > On Wed, Jan 22, 2003 at 11:12:32PM -0800, Marcel Moolenaar wrote: > >On Thu, Jan 23, 2003 at 07:55:56AM +0100, Nicolas Souchu wrote: > >> 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... > > I think this is only true of VGA devices. Yes, true. > Definitely the DEC TGA > does not have any legacy address support - it has to be initialised > as a generic PCI device and then written to using its proprietary > command set. If there's no firmware support for an early console, or even just firmware support for getting the console device addresses, this would mean that you need to have an early bus enumeration phase just to get output devices. I don't know how feasible this would be. See also below. > And based on other comments in this thread, I think > that USB keyboards don't have legacy AT-keyboard support either. Input devices have the advantage that we won't use them before we do bus enumeration, if we exclude the debugger for a moment. I think we can exclude the debugger because we don't have an obligation to support any and all kinds for input devices or necessarily need a "perfect" infrastructure to make it work... For input devices I think it would suffice if we could have zero or more of them attached during bus enumeration. Especially if the keyboard is attached to something non-trivial as USB... > >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. > > Whilst I don't see any alternative, this is a fairly expensive approach > since the number of MD files starts growing alarmingly as the number of > architectures and console devices increases. (Though it's definitely > better than having lots of MD code buried in supposedly MI files). Agreed. I though about a single con_machdep.c in which you put the MD code for all possible console devices, but it doesn't really fit in well with the way we configure our kernel and the ease with which we can include/exclude source files. It's a possibility though and if we guarantee conditional compilation, a good alternative to avoid a large number of source files. -- 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