From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 7 15:32:02 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 DEB4437B401 for ; Mon, 7 Jul 2003 15:32:01 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC97043F75 for ; Mon, 7 Jul 2003 15:32:00 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h67MuuMa025801; Mon, 7 Jul 2003 18:56:56 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h67MWHVm076107; Mon, 7 Jul 2003 15:32:17 -0700 (PDT) (envelope-from jmg) Date: Mon, 7 Jul 2003 15:32:17 -0700 From: John-Mark Gurney To: Marcel Moolenaar Message-ID: <20030707223217.GK44762@funkthat.com> Mail-Followup-To: Marcel Moolenaar , sparc64@freebsd.org References: <20030707210543.GA29440@ns1.xcllnt.net> <20030707213416.GG44762@funkthat.com> <20030707220139.GB29689@ns1.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030707220139.GB29689@ns1.xcllnt.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: sparc64@freebsd.org Subject: Re: pre-newbus address decoding X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney 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 22:32:02 -0000 Marcel Moolenaar wrote this message on Mon, Jul 07, 2003 at 15:01 -0700: > On Mon, Jul 07, 2003 at 02:34:16PM -0700, John-Mark Gurney wrote: > > Marcel Moolenaar wrote this message on Mon, Jul 07, 2003 at 14:05 -0700: > > > 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 :-) > > > > What exactly are you trying to do with this? Why can't you interact > > with the OFW interface to the device instead of trying to twiddle the > > bits yourself? > > 3 reasons: > > 1. Portability. I'm working on a new UART driver that's going to support is this UART driver going to be generic enough that it will support ALL serial devices? Don't forget that VERY few sparc64 machines have a NS16550 compatible UART. > all platforms (especially ia64 and sparc64) and most hardware. The > low-level console code uses the newbus functions for I/O, but since > newbus itself hasn't been initialized, needs machine dependent code > to construct tags and handles. See also sparc64_fake_bustag() in > sys/sparc64/sparc64/bus_machdep.c for how this is expected to work > on sparc64. sparc64 users OFW for low-level console IO until newbus is initalized and the proper driver is loaded. Currently sio doesn't know when it's console and requires manual setting unlike the zs driver. Personally, supporting OFW for console code like this will make it more portable. > 2. Consistency. All platforms are capable of supporting remote debugging > using a serial interface and have the kernel drop into the debugger > immediately after setting up the console. Not all platforms have this > implemented. Clearly, we cannot use OFW to communicate over debug > ports. Why do you say clearly? OFW was specificly designed to be able to be used for debugging. Heck, the low level OFW console code can still output to sio even once the sio driver is loaded. > 3. Extensibility. Our console code (ie pcvt and syscons) is in need for > a replacement. It's too PC specific and is not going to work when > UGA is the defacto standard on newer (EFI based) amd64, ia32 and ia64 > machines. A possible future console framework is likely to be graphical > to allow it to work with newer non-textual hardware. > A similar argument applies to low-level console and/or debug port code > that needs pre-newbus access to devices for with the OFW interfaces > are not suitable. I still don't understand. Because OFW interface provides text drawing on graphical frame buffers. So far you haven't said one feature that OFW doesn't already support. > > Get a copy of P1275/D12 (P1275 draft 12) that is freely available. It > > will tell you ALL you need to know about it. > > I have it. It's not answering my questions, specifically, it's not > answering Q1. Q2 and on are FreeBSD specific, so clearly those are > not answered... Q1 is bus specific and you need to look at the related bus attachment documentation. I don't have a url handy for that, but it shouldn't be hard to find using google. Really, all of your questions are OS independant since you are assuming that newbus (which makes FreeBSD, "FreeBSD") isn't initalized. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."