From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 7 14:05:56 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1B2537B409 for ; Mon, 7 Jul 2003 14:05:56 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FCFB43FBD for ; Mon, 7 Jul 2003 14:05:49 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h67L5hv1029554 for ; Mon, 7 Jul 2003 14:05:43 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.9/8.12.9/Submit) id h67L5hDn029553 for sparc64@FreeBSD.org; Mon, 7 Jul 2003 14:05:43 -0700 (PDT) (envelope-from marcel) Date: Mon, 7 Jul 2003 14:05:43 -0700 From: Marcel Moolenaar To: sparc64@FreeBSD.org Message-ID: <20030707210543.GA29440@ns1.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Subject: pre-newbus address decoding X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 21:05:57 -0000 [this probably applies to PowerPC as well. Not CC'd however] I have a current need and a possible future need to talk to hardware before newbus has been initialized properly. Yes, we're talking low- level console code (again :-), but also remote debugging for example. Using OFW it's easy enough to get the phandle of the the serial console (if the console is serial) and read the "reg" property. The address obtained that way is not (yet) suitable for actual I/O, because we need to decode it (I expect you know this, but it makes a nice introduction :-) Q1: Is there an OFW client interface that decodes the unit address, much like the decode-unit method? The following applies only when the answer to the previous question is no. If OFW does not have an interface for this, then we have to do it the hard way. Q2: Am I correct that the basic logic is to traverse to the root and decode the address at each intermediate parent, until we end up with what is then the physical address? Q3: Is there an upper bound to the space needed for the value of the "address-ranges" property so that we can obtain the necessary information from OFW, without having to allocate memory and thus make it possible to decode before the VM is up and running? Q4: Given the above, does it make sense to add decoding functionality to the bus drivers as a low-level interface between low-level console drivers and OFW (ie not using newbus data structures)? Thanks, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net