pre-newbus address decoding
t.moestl at tu-bs.de
Tue Jul 8 06:26:46 PDT 2003
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
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
> 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 Moestl <t.moestl at tu-bs.de> http://www.tu-bs.de/~y0015675/
<tmm at FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
More information about the freebsd-sparc64