RPi3 not using SMP?

[Mark Millard]

[I've dropped Jeff from this note not having
additional evidence.]

On 2020-Feb-7, at 20:24, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, Feb 07, 2020 at 07:10:58PM -0800, Mark Millard wrote:
>>> 
>>> psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
>>> psci0: PSCI version number 0 mismatched with DT, default 2
>>> device_attach: psci0 attach returned 6
>>> 
> 
> Is the "DT" in the boot message a reference to the Device Tree (blob)?
> If not then my question is on the wrong foot. I meant to wonder if the
> problem is simply using a wrong dtb file. 
> 
> It does seem clear that one or more things are somewhat amiss.
> Are they adequately advertised in existing bug reports, or should
> more noises be made? A search for psci on bugs.freebsd.org finds
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243118
> but to the untrained eye it seems unrelated.

If you want a working system, use a system based on
head -r356767 (and an appropriately matching world).
No device tree change required.

Nothing about -r356776 is supposed to involve determining
which Device Tree is used. The changes are not to
architecture specific code.

But I'm not making claims about possibilities like an
inaccurate Excluded Memory Regions list or the code
ignoring that list in some way and allocating with
an overlap with such a region.

Mostly I'm looking at this in case there is a FreeBSD
problem that the RPi3/4's just happen to expose. If
it proves to be a RPi3/4 error and FreeBSD should be
okay as it is in -r356776 and later, then I'm not sure
there are many folks with the appropriate skills that
would want to deal with making things work.

But, if it turns out that FreeBSD has a problem that
RPi3/4's just happen to expose, I'm sure folks with
the skills would deal with that.

I'm unlikely to figure out which it is. But some of
the evidence I provide might prove useful.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)