From owner-freebsd-i386@FreeBSD.ORG Thu Aug 3 22:16:50 2006 Return-Path: X-Original-To: freebsd-i386@freebsd.org Delivered-To: freebsd-i386@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA5E216A4E8; Thu, 3 Aug 2006 22:16:50 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E749F43D77; Thu, 3 Aug 2006 22:16:40 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.5.252] (dhcp52.wlan.xcllnt.net [192.168.5.252]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k73MGYXM025585; Thu, 3 Aug 2006 15:16:34 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20060803.152816.112545225.imp@bsdimp.com> References: <44D151DF.10000@root.org> <20060803.111243.74675763.imp@bsdimp.com> <4D601BDF-4D76-43CB-A565-30837492E3DE@xcllnt.net> <20060803.152816.112545225.imp@bsdimp.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D55A079-32B9-49B4-998C-7B5E67A2E434@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 3 Aug 2006 15:16:22 -0700 To: Warner Losh X-Mailer: Apple Mail (2.752.2) Cc: jrhett@svcolo.com, freebsd-gnats-submit@freebsd.org, freebsd-i386@freebsd.org, nate@root.org Subject: Re: i386/100831: sio ignores BIOS information about serial ports - bounty offered X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 22:16:50 -0000 On Aug 3, 2006, at 2:28 PM, Warner Losh wrote: > Agreed. However, the sio flags to designate a unit as console is the > only thing that doesn't fit well with hints, as presently implemented. > It should really be something like: console.type={serial,video} > console.location= > > so that would could use a video card not mapped to the default address > as the console, etc. It would be up to the driver at attach time to > look at the available console meta-information to see if this driver > matches that information. Then it wouldn't matter for a serial > console point of view what driver unit is assigned. It might matter > for other reasons... This is exactly what I implemented for uart(4). As long as the I/O location used by the low-level console is actually being "found" during bus-enumeration and the right driver is being attached, then you always have a working console for going to single-user mode. Not to mention that the firmware typically exports console information in terms of I/O location (see DIG64 HCDP or Microsoft SPCR), so you can trivially use that too (see for a real example src/sys/dev/uart/uart_cpu_ia64.c). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net