From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 12:58:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB7E16A4CE; Sun, 26 Sep 2004 12:58:42 +0000 (GMT) Received: from tora.nunu.org (YahooBB219003182047.bbtec.net [219.3.182.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70ADE43D1F; Sun, 26 Sep 2004 12:58:42 +0000 (GMT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from tora.nunu.org (unknown [192.168.1.2]) by tora.nunu.org (Postfix) with ESMTP id 4FADE4CC89; Sun, 26 Sep 2004 21:58:41 +0900 (JST) Date: Sun, 26 Sep 2004 21:58:41 +0900 Message-ID: <87ekkpmbjy.wl@tora.nunu.org> From: Hidetoshi Shimokawa To: Bruce M Simpson In-Reply-To: <20040720034256.GA826@empiric.dek.spc.org> References: <16634.47272.768935.436137@grasshopper.cs.duke.edu> <200407182039.10773.dfr@nlsystems.com> <16634.54674.966908.540880@grasshopper.cs.duke.edu> <200407182104.53221.dfr@nlsystems.com> <87hds3pfgv.wl@tora.nunu.org> <20040720034256.GA826@empiric.dek.spc.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 14) (Reasonable Discussion) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: Andrew Gallatin cc: nork@freebsd.org cc: freebsd-current@freebsd.org cc: simokawa@freebsd.org cc: jhb@feebsd.org Subject: FireWire/dcons support in loader (Re: Excellent job on the firewire support!) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 12:58:43 -0000 OK, I spent this weekend to implement dcons in i386 loader and experimental loader binary is available at: http://www.freebsd.org/~simokawa/firewire/loader/loader.fw-20040926 Though there are still some limitations, you can interact with loader using dconschat(8). - FireWire OHIC is detected using PCI BIOS and initialized. - dcons(4) is enabled in loader as an additional console by default. This means that you can use both dcons and vidconsole or comconsole simultaneously as usual dcons(4) in kernel. If you want to use this dual console, please make sure you don't have 'console=XXXconsole' line in loader.conf. This overrides dual console settings. If you want to use serial console and dcons simulataneously, put /boot.config with '-h' or ' '-hD'. - I recommand you to use dconschat(8) with '-r' (replay) option. - dcons(4) in loader and kernel use different buffer. This means that dcons(4) is disconnected since loader executes kernel until fwohci/dcons is initialized in kernel. See below for detail. - This depends on PCI BIOS to detect FireWire OHCI. If we can share loader binary between i386 and amd64, I assumes that this loader can work well on amd64 too. Any volunteers for test? - I need some more work to clean up the source tree, but I can send the current source tree to interested people. Please contact me. At Tue, 20 Jul 2004 04:42:56 +0100, Bruce M Simpson wrote: > > On Tue, Jul 20, 2004 at 11:41:52AM +0900, Hidetoshi Shimokawa wrote: > > It is not enough :-< I lack the knowledge of BIOS/PCI(and ACPI?). > > Once we can access the OHCI register via PCI in the loader, > > the remaining part is relatively easy as you described. > > I need some help for this part. I suppose that implementing dcons > > in the loader is architecture dependent. > > Very much so, to begin with. Let's consider the i386 case. > > libi386/biospci.c wants FireWire device classes added to it for its probe. > Some BIOS wrapper functions to manipulate PCI configuration registers need > to be added too. I have added some functions to biospci.c. > Then a fwconsole driver much like comconsole could be written, i.e. > fwc_probe(), fwc_init() etc. I believe it's safe to assume that V==P > for address space at this point. I guess this could act as a shim before Unfortunately, V!=P. I need PTOV() to access OHCI registers. > the driver actually gets loaded. kenv could be used to tell dcons where > the loader had allocated the buffer before the kernel actually starts. Yes, kenv can pass the address. > There would have to be a comfortable handover between loader and dcons > in the kernel, but because it just uses a ring buffer, I imagine this is > somewhat easier than it would be otherwise. The most messy part is that console in kernel is initialize before VM subsystem is initialized. We can easily locate physical address of dcons buffer but we have some problems. - What is the virtual address of the buffer BEFORE VM is initialized? - What is the virtual address of the buffer AFTER VM is initialized? - Can we make above two addresses to be same? - What is the best way to prevent the OS to reuse the physical pages for other purpose? > I am about to get some long overdue sleep, otherwise I'd begin hacking this > myself. ;-) > > BMS Have a fun, /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html