From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 27 14:16:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92C4F106568B for ; Thu, 27 Aug 2009 14:16:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 659B28FC2C for ; Thu, 27 Aug 2009 14:16:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E1E0046B03; Thu, 27 Aug 2009 10:16:43 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 500DD8A02E; Thu, 27 Aug 2009 10:16:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Thu, 27 Aug 2009 08:08:09 -0400 User-Agent: KMail/1.9.7 References: <20090826204513.M28384@alentogroup.org> In-Reply-To: <20090826204513.M28384@alentogroup.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908270808.09790.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 27 Aug 2009 10:16:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: remodeler Subject: Re: MBR hack for serial console X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:16:44 -0000 On Wednesday 26 August 2009 5:07:16 pm remodeler wrote: > I am hoping for input on a patch I want to apply to the MBR of a FreeBSD > 8-BETA3 AMD64 server. I need a serial console on this server. The ASUS > motherboard (amibios) has PCI and PCI-e expansion slots, and a Moschip MCS9820 > UART (serial board) is installed at pci0:3:5:0. The amibios can be configured > to do the plug-and-play enumeration, or this feature turned off, but there is > no way to assign a particular i/o port to a PCI device in the BIOS, and I > cannot get source for the BIOS to change this behavior. The serial board has a > single Base Address Register at 10h in its pci configuration space. Whether > the PCI bus is probed by the BIOS or FreeBSD, the UART BAR is assigned the > i386 I/O port address of 0xe800. It must be COM1-COM4 (i.e. 0x3F8) to work in > the boot sequence. I need access to the serial console before loader. Hmm, is 60 bytes enough to read the current value of the BAR instead and use that address? Writing 0x3f8 will not work if the BAR has a length > 8, though it sounds like that isn't the case. Still, if the device is behind a PCI-PCI bridge (which it probably is if it is on bus 3) you have the problem that 0x3f8 is probably not in the IO range decoded by the parent bridge. Given that I really think reading the current value and using that instead of 0x3f8 is probably more reliable. > I do not expect the hardware configuration to change so a hack is ok. My plan > is to patch the MBR to override the serial card's BAR with 0x3F8. My reasoning > is that the CPU is still in Real mode (allowing direct hardware access) until > loader executes, and the serial console would work for the boot0 and boot2 > calls to the terminal. I have experimented with using pciconf to change the > BAR from a command line; curiously the command: > > pciconf -w pci0:3:5:0 16 1016 > > loads 0x3F9 into the serial card's PCI configuration space instead of 0x3F8, > and I don't understand why. I've worked up this patch and hope someone can > tell me why this would or wouldn't work: You would read back 0x3f9 because the lower 3 bits of a BAR are various flags. bit 0 indicates if a BAR is for I/O (1) or memory (0) hence why you read back 0x3f8 | 0x1. -- John Baldwin