Date: Tue, 2 Sep 2003 00:06:42 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: sparc64@freebsd.org Subject: Re: Req review: OF_decode_addr() Message-ID: <20030902070642.GA659@athlon.pn.xcllnt.net> In-Reply-To: <20030902064956.GA16766@funkthat.com> References: <20030902021813.GA2300@dhcp01.pn.xcllnt.net> <20030902064956.GA16766@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 01, 2003 at 11:49:56PM -0700, John-Mark Gurney wrote: > Marcel Moolenaar wrote this message on Mon, Sep 01, 2003 at 19:18 -0700: > > Attached a patch to add function OF_decode_addr(). The function > > takes a package handle (phandle_t) and returns the physical > > (decoded) address at which it resides as well as it space. > > You mean physical address as viewed by the CPU, correct? Yes. > > This function is needed by uart(4) to for low-level console > > access. > > > > There's one thing I'm not happy about and that's the call to > > ofw_isa_map_iorange(). It makes it impossible to create a kernel > > without isa. It makes sense to move the bulk of the code in > > OF_decode_addr() to the respective bus drivers and have some > > linker set to tie bus name to function pointer. I'm not sure > > it's important to have that right away or if we can commit this > > and deal with that later? > > Why don't you wrap the ebus/isa part around an #if defined(NISA) || > defined(NEBUS) to prevent the inclusion of isa when not necessary? That would work. The sbus part is sufficiently seperated from the ebus part. > I would like to see this code in a more general format instead of in > a MD file. OpenFirmware is quite specific on how each bus lists it's > registers and ranges. We should leverage this so that other platforms > don't have to have lots of special code to implement the same thing. Good point. PowerPC immediately comes to mind. However, there's a pitfall: The prototype uses both phandle_t and bus_addr_t. A lot of files include OFW headers, but most do not have both types visible. A more generic implementation will have a cost: We need to do a more extensive shuffling/cleaning to get something that builds. That definitely is beyond my scope. > I don't have an OFW dump handy, so I can't verify correctness of code. The code has been tested on an U2 (sbus) and an U5 (ebus/pci). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030902070642.GA659>