marius at alchemy.franken.de
Fri Oct 25 17:17:44 UTC 2013
On Thu, Oct 24, 2013 at 11:49:33AM -0500, Nathan Whitehorn wrote:
> On 10/24/13 10:51, Marius Strobl wrote:
> >> Patch at: http://people.freebsd.org/~nwhitehorn/sparc64-nexus-unify.diff
> > 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
> Odd. The resource allocation code is an exact copy of the one from
> sparc64/nexus.c. I'll power up my SPARC machine and try to debug.
Given that the resources actually are added correctly, I'd suspect
that some of the expected parent/child relations break when deriving
nexus_driver from ofw_nexus_driver but I don't get why this should
have anything to do with the runtime hierarchy in the first place;
this _could_ be a bug in newbus, though.
> The only exception has to do with interrupt
> numbering. SPARC doesn't seem to follow the Open Firmware
> interrupt-mapping standard as far as I can tell
That highly depends on the specific machine model; some are perfectly
in line with the OFW standard, most but not all at least conform with
it beneath the host-PCI-bridge level and a few are just odd here and
there. The code in the tree mostly uses OFW means starting at the PCI
level with some fallback and does interrupt numbering above always
partially in a "manual" way, with the latter working on all models
regardless of what information they provide in the respective OFW
> Aside from resource allocation (which is maintained by the patch in MD
> code) and this nit with IRQs, the PowerPC nexus is at present a
> line-for-line copy of the sparc64 one. It seems a shame to maintain that
Well, on the other hand it's not that much additional code compared to
other nexus(4) implementations that are more or less duplicated in the
tree. Also, this stuff doesn't actually change that much over time.
However, one thing that's currently missing on sparc64 is obtaining
NUMA information; that again very likely will need additional tweaks
to nexus(4) similar to what's already there for topologies involving
ssm(4) given that OFW nodes representing single cores also are found
in different spots in the device tree hierarchy depending on the
All that said, IMO we're actually rather good at factoring out common
OFW code into dev/ofw to the extent it really makes sense, apart from
the fact that some FDT bits and stuff could make better (re-)use of
the existing "true" OFW code, which you've already fixed recently or
apparently are planning to do.
> > 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,
> This could be restored, though I can't imagine it adds much.
At least in the past such "implicit" range checks turned out to be
useful when adding support for new classes of sparc64 machines.
> > o devices without at least memory resources get added as children,
> > while previously they were skipped.
> Does it harm anything to add these? I'll try to fix the bugs in any
> case, and then we can revisit the patch.
No real "harm"; it just wastes a bit of memory to have devices in the
FreeBSD device tree that no driver ever will attach to and the associated
message the sparc64 nexus(4) emits when detecting such even registerless
devices helps to identify nodes that are better added to the exclusion
More information about the freebsd-sparc64