Nexus improvements

Marius Strobl marius at
Thu Oct 24 16:15:14 UTC 2013

On Wed, Oct 23, 2013 at 03:35:54PM -0500, Nathan Whitehorn wrote:
> I've been trying for the last few days to clean up some of our OF/FDT 
> code, in particular related to reducing code duplication. There is a 
> 12-year-old comment in sparc64/sparc64/nexus.c that "this code should 
> get into dev/ofw to some extent". Most of the code has been moved now 
> and the PowerPC nexus device has been replaced by the pieces of the 
> sparc64 one that now do live in dev/ofw. The following (almost entirely 
> negative) patch moves sparc64 to use it as well. Since it is just a copy 
> of the sparc64 code, this should involve no functional changes, and I 
> will commit it in a few days unless someone raises an objection. The 
> patch is only compile tested for the time being, so hardware tests would 
> be appreciated.
> Patch at:

Well, as is this patch breaks resource allocation in a strange way:
nexus0: <Open Firmware Nexus device>
pcib0: <Sun Host-PCIe bridge> mem 0x4000f600000-0x4000f6effff,0x4000f410000-0x4000f473fff irq 1983,1982 on nexus0
panic: fire_attach: could not allocate register bank 0

I didn't try to figure out what's going on as I'm still not very fond
of sharing that code across platforms. The comment you are referring to
is - as you are also pointing out - rather old and applied to a sparc64
nexus(4) that was quite different than the current version and f. e.
didn't do resource management of its children based on OFW information.
In particular, "true" MI code shouldn't have #ifdefs with very MD code
like the one your patch would introduce. Similarly, the device exclude
lists shouldn't be shared across all platforms as one might want to
exclude a specific device whilst another does not. Having the whole
lists in unconditionally also just wastes memory on embedded machinery.
Also, switching sparc64 to use the current dev/ofw/ofw_nexus.c would
introduce some subtle differences compared to how things currently
work with the MD nexus(4). At a quick glance that would be:
o the interrupts RMAN range gets extended from IV_MAX - 1 to ~0,
  which means no longer sanity checking for out-of-range interrupts,
o devices without at least memory resources get added as children,
  while previously they were skipped.


More information about the freebsd-sparc64 mailing list