Date: Thu, 23 Jan 2003 13:41:47 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123214147.GA1218@dhcp01.pn.xcllnt.net> In-Reply-To: <20030123205808.GA17281@cirb503493.alcatel.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030123214147.GA1218>