r366058 bdragon Sept. 23, 2020, 2:37 a.m.
* powerpc time_t is 64 bit, not 32 bit.

* Add definition for powerpc64le.

With this, powerpc64le ntpd and ntpdate operate correctly instead of
corrupting the clock and exiting.

Tested on powerpc64, powerpc64le, and powerpc.

No feedback from cy@.

I am a bit confused as to how SIZEOF_TIME_T being wrong ever worked on
powerpc, it being big endian and all.

Sponsored by:	Tag1 Consulting, Inc.
Differential Revision:	https://reviews.freebsd.org/D26379
r366057 bdragon Sept. 23, 2020, 2:28 a.m.
Due to enter_idle_powerx fabricating a MSR from scratch, it is necessary
for it to care about the endianness, so we don't accidentally switch
endian the first time we idle a thread.

Took about five seconds to spot after seeing an unmangled backtrace.

The hard bit was needing to temporarily set up a mutex to sort out the
logjam that happens when every thread simultaneously wakes up in the wrong
endian due to the panic IPI and panics, leaving what I can best describe as
"alphabet soup" on the console.

Luckily, I already had a patch sitting around to do that.

This brings POWER8 up to equivilence with POWER9 on PPC64LE.

Sponsored by:	Tag1 Consulting, Inc.
r366056 bdragon Sept. 23, 2020, 2:17 a.m.
Due to the sqlite3 endian detection code preferring to check platform defines
instead of checking endian defines, it is necessary to manually set
the endianness on PowerPC64LE.

Unlike other bi-endian platforms, PowerPC64LE relies entirely on the
generic endianness macros like __BYTE_ORDER__ and has no platform-specific
define to denote little endian.

Add -DSQLITE_BYTEORDER=1234 to the CFLAGS when building libsqlite3 on

Fixes runtime operation of sqlite on PowerPC64LE.

Sponsored by:	Tag1 Consulting, Inc.
r366055 bdragon Sept. 23, 2020, 2:11 a.m.
* Add missing _kvm16toh() function.
* Teach libkvm about powerpc64le.

Sponsored by:	Tag1 Consulting, Inc.
r366054 bdragon Sept. 23, 2020, 2:05 a.m.
gdtoa wins the award for "most outdated endianness naming convention"
with its IEEE_8087 vs IEEE_MC68k defines. I had a good chuckle.

Update softfloat and arith.h to adjust to BE or LE automatically
based on the low level preprocessor defines.

Fixes printf/scanf on PowerPC64LE, although there is still a problem
lurking regarding Signalling NaNs...

Sponsored by:	Tag1 Consulting, Inc.
r366053 bdragon Sept. 23, 2020, 1:56 a.m.
OPAL unconditionally enters secondary CPUs with only HV and SF set.

I tried writing a secondary entry point instead, but OPAL rejected it
and I am unsure why, so I resorted to making the system reset interrupt

This means we take a slight performance hit on wakeup on LE, but it is
a good stopgap until we can figure out a reliable way to make OPAL enter
where we want it to.

It probably makes sense to have it around anyway, because I can imagine
scenarios where the cpu resets itself to BE and does a software reset.

Sponsored by:	Tag1 Consulting, Inc.
r366051 bdragon Sept. 23, 2020, 1:51 a.m.
Another boring one. We need to endian swap before checking flags.

Sponsored by:	Tag1 Consulting, Inc.
r366049 bdragon Sept. 23, 2020, 1:49 a.m.
More endian conversion.

* Install TCEs correctly (i.e. in big endian)

* Convert to big endian and back when setting up queue pages and IRQs.

Sponsored by:	Tag1 Consulting, Inc.
r366048 bdragon Sept. 23, 2020, 1:41 a.m.
Not much to say here, another missing be64toh() in memory that was written
from OPAL.

Sponsored by:	Tag1 Consulting, Inc.
r366047 bdragon Sept. 23, 2020, 1:37 a.m.
Since OPAL runs in big endian, any data being passed back and forth
via memory instead of registers needs to be byteswapped.

From my notes during development:

"A good way to find candidates is to look for vtophys() in opal_call()
parameters. The memory being passed will be written into in BE."

Sponsored by:	Tag1 Consulting, Inc.
r366046 bdragon Sept. 23, 2020, 1:33 a.m.
It's much easier to implement this in an endian-independent way when we
don't also have to worry about masking half of the dword off.

Given that this code ran on a machine that ran a poudriere bulk with no
kernel oddities, I am relatively certain it is correctly implemented. ;)

This should be a minor performance boost on BE as well.

Sponsored by:	Tag1 Consulting, Inc.
r366045 bdragon Sept. 23, 2020, 1:29 a.m.
For a body of code that had its endian conversion bits written blind without
the ability to test, moea64 was VERY close to being correct.

There were only four instances where the existing code was getting it wrong.

Sponsored by:	Tag1 Consulting, Inc.
r366044 bdragon Sept. 23, 2020, 1:13 a.m.
This was originally part of the initial commit, but after discussion in
D26399, I split it out into its own commit after the kernel config file.

Sponsored by:	Tag1 Consulting, Inc.
r366043 bdragon Sept. 23, 2020, 1:07 a.m.
This is slightly stripped down from GENERIC64, as PowerMac G5 machines
are incapable of running in LE mode (so we can skip the Mac drivers.)

While technically POWER6 and POWER7 have the hardware capability of running
in LE mode, they have a tendency to trap excessively when a load/store is
misaligned. (an extremely common occurrence in LE code, and one of the main
reasons I consider BE to be superior, as it turns potential security issues
into immediately obvious mangled numbers.)

Additionally, there was no mechanism to control what endian interrupts
are delivered in, so supporting LE operation on POWER6 and POWER7 involves
some really dirty tricks in the interrupt vectors that I would rather

IBM drew the line in the sand at POWER8 some time around 2013, embracing
full support for LE in the platform, and making a push across the board
for LE code to target POWER8 as a minimum requirement. As such, usage of
LE kernels on POWER6 and POWER7 is practically nil, despite it being
technically possible to do.

The so-called "TRUELE" feature bit which is the baseline requirement for
 needed for PowerPC64LE was introduced in POWER8.

Sponsored by:	Tag1 Consulting, Inc.
r366042 imp Sept. 23, 2020, 1:04 a.m.
There was a small window cp was broken. Work around this by using :>
instead of cp /dev/null. Ideally, we'd keep the cp /dev/null in the
build as a regression test, but doing so breaks people that upgraded
during the cp breakage and this is simpler than bootstrapping a
working cp since there's no good __FreeBSD_version sign posts for

Suggested by: lots of people
Too stubborn for his own good: imp