Date: Tue, 8 Jul 2003 15:28:15 +0200 From: Thomas Moestl <t.moestl@tu-bs.de> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: sparc64@freebsd.org Subject: Re: pre-newbus address decoding Message-ID: <20030708132815.GA659@crow.dom2ip.de> In-Reply-To: <20030707210543.GA29440@ns1.xcllnt.net> References: <20030707210543.GA29440@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003/07/07 at 14:05:43 -0700, Marcel Moolenaar wrote: > [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? Not that I know of. There is "map-in" for fcode programs, but we cannot use it once the kernel has started. > 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? Yes. I've put some old sio patches which I use at http://people.freebsd.org/~tmm/sio-s64-20030612.diff in case you are interested (this is a quick and dirty hack; the code I use to attach the console is at the very end). As you can see, I special-cased the register mapping at PCI and ISA/EBus level (which I guess you want to avoid to be more generic). As jmg already remarked, the rest of the sparc64-specific console drivers attach as soon as the driver attaches via newbus, taking over from ofwcons; this avoids this hassle, but can get in the way when debugging problems before the console driver has attached. > 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? 4 * sizeof(struct ofw_pci_register) (= 80) should suffice with some headroom. The code should probably just panic when insufficient space was reserved. > 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)? I guess a generic mapping function would be preferable if it is possible and all firmware implementation are close enough to the standard to allow this. The bus drivers will mostly just do the same, but attaching them early would probably be more trouble. - Thomas -- Thomas Moestl <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030708132815.GA659>