From owner-freebsd-i386@FreeBSD.ORG Sat Aug 5 23:33:53 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 8250C16A4DF for ; Sat, 5 Aug 2006 23:33:53 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id E068143D69 for ; Sat, 5 Aug 2006 23:33:52 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 60F641291F4; Sun, 6 Aug 2006 09:33:18 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k75NXFqv014758; Sun, 6 Aug 2006 09:33:16 +1000 Date: Sun, 6 Aug 2006 09:33:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jo Rhett In-Reply-To: <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> Message-ID: <20060806085626.S2624@delplex.bde.org> References: <200608022150.k72LoQtn098666@freefall.freebsd.org> <20060804223000.P97440@delplex.bde.org> <5F770D91-34A1-4406-AEF8-719E29AFFA87@svcolo.com> <3FB8BF25-F047-427C-9062-07ADF85D5169@svcolo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-i386@freebsd.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: Sat, 05 Aug 2006 23:33:53 -0000 [freebsd-gnats-sbmit somewhat intentionally lost from the Cc] On Fri, 4 Aug 2006, Jo Rhett wrote: > On Aug 4, 2006, at 11:40 AM, Jo Rhett wrote: >>> Just avoid inconsistencies by making all the hints match the unit number >>> assignments that you get although these are not the unit number >>> assignments >>> that you want. >> >> I haven't the foggiest idea what you mean by this. Exact instructions >> please? I'm not kidding, this statement doesn't make sense to me. >> Everything is fine right now except where the console is directed. >> >> I have no problem with the console being sio1, as long as sio1 is the >> console for all parts of the boot/run/shutdown process. Therefore the >> console flags are the only thing I know to change. > > Maybe I was being dense when I wrote this. Rethinking "making all the hints > match" comment I swapped the io port and irq assignments in device.hints to > match what is actually happening, rebooted, and it seems to work: > > hint.sio.0.at="isa" > hint.sio.0.port="0x2F8" > #hint.sio.0.flags="0x10" > hint.sio.0.irq="3" > hint.sio.1.at="isa" > hint.sio.1.port="0x3F8" > hint.sio.1.irq="4" > hint.sio.1.flags="0x90" Good. I only tested it by understanding the source. COM1 might mean 0x3F8 in DOS, but in FreeBSD sio0 just means whatever port is mapped to unit 0 by hints or by another mechanism. The hints give more control over the mapping than in DOS, but don't always work now that there is ACPI etc. COM1 doesn't mean 0x3F8 in WinXP like you claimed in another reply and I expected before I tested it. Maybe WinXP would have mapped 0x3F8 to COM1 if I had reinstalled WinXP or if WinXP had rebuilt its driver database, but when I just swapped COM1 with COM2 in the BIOS and rebooted, WinXP didn't say that it was rebuilding its driver database and the ports were just swapped in WinXP too. My BIOS's labels for the ports are also inconsistent with COM1 meaning 0x3F8 -- the first port is named COM1 (not COMA) and that port can be set to an address != 0x3F8, etc. When COM1 and COM2 were on ISA cards (especially when they were on separate cards), it made much more sense for DOS to map the port at 0x3F8 to COM1, etc. ISTR that DOS has fixed mappings for COM1-COM4 but not for COM5 up, and that it has magic mappings which don't work as well for LPT1-LPT2. > Okay, so if this works then I'm guessing that boot0 or boot2 or both were > determining console based on the IO address from device.hints? Can we use > what we know now to improve the documentation? boot0 uses BIOS COM1 and boot2 uses non-BIOS whatever i/o address is configured (default 0x3F8). At least in man pages, the documentation for this is hard to find. I could only find it in boot0cfg(8) for boot0 and and make.conf(5) for boot2. > boot0 determines console how? Compiled in...? Can device.hints influence > that? Since we don't yet have sio numbers assigned, how does it know which > port to use? IO address? As above; yes; no; hard-coded in assembler; BIOS unit number 0 (= COM1). > boot2 determines console how? (repeat all questions above) As above; yes; no; soft-hard-coded in makefiles; i/o address. > loader determines console how? (repeat all questions above) Same as boot2 (?). Hopefully for everything except the port address, it inherits settings (speed and parity etc.) from boot2. > If I didn't name a process in the boot, add it to the list. Kernel part of the boot. Now uses hints. Normally inherits all settings from the previous stage provides it agrees on the port address (it reads the settings from the port). Bruce