Date: Tue, 8 Jul 2003 21:39:34 +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: <20030708193934.GB878@crow.dom2ip.de> In-Reply-To: <20030708181526.GA31152@dhcp01.pn.xcllnt.net> References: <20030707210543.GA29440@ns1.xcllnt.net> <20030708132815.GA659@crow.dom2ip.de> <20030708181526.GA31152@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2003/07/08 at 11:15:26 -0700, Marcel Moolenaar wrote: > On Tue, Jul 08, 2003 at 03:28:15PM +0200, Thomas Moestl wrote: > > > > > > 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). > > Cool. This is exactly what I'm looking for. > > > > 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. > > Ok. I'll add one on the uart branch. At first it'll be a copy of what > you have in the sio patch, but it'll probably evolve. Unfortunately > all my UARTs are on EBUS. Then again, a PCI multi I/O card shouldn't > be that expensive... EBus is very much like ISA (it was designed to allow easy adaption of devices designed for ISA); this includes the firmware properties, so the sparc64 EBus and ISA code share functions to handle them. > Last questions: Since I create a fake bustag, I need to have a valid > bus space type (bus_space_asi index). > Am I correct that the PCI types use little endian reads and writes? > If so, can I avoid the problem by always using 8-byte reads/writes > and just use type 0 or is the magic slightly more complex and do I > need to keep track of a proper type while traversing to the root? At the moment, there is no more magic. It should also be easy to track the types though; the PCI ones also apply to EBus and ISA. - 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?20030708193934.GB878>