Open Firmware-centric:
- Keep the static list of regions in platform.c instead of ofw_machdep.c
- Move various merging and sorting operations to platform.c as well
- Move apple_hacks code out of ofw_machdep.c and into platform_powermac.c,
where it belongs
- Move CHRP-specific dynamic-reconfiguration memory parsing into
platform_chrp.c instead of pretending it is shared code
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
requires process descriptors to work and having PROCDESC in GENERIC
seems not enough, especially that we hope to have more and more consumers
in the base.
MFC after: 3 days
from OF. Linux does it similar, means they also read the OF values and
display them.
Tested under qemu and real hardware:
cpu0: IBM POWER5+ revision 2.0, 1898.10 MHz
preserve any existing fault buffer. RTAS calls are meant to be safe from
interrupt context (and are indeed used there to implement the xics PIC
drvier). Without this, calling into RTAS in interrupt context would have
the effect of clearing any existing onfault state of the interrupted
thread, potentially leading to a panic.
option, unbreak the lock tracing release semantic by embedding
calls to LOCKSTAT_PROFILE_RELEASE_LOCK() direclty in the inlined
version of the releasing functions for mutex, rwlock and sxlock.
Failing to do so skips the lockstat_probe_func invokation for
unlocking.
- As part of the LOCKSTAT support is inlined in mutex operation, for
kernel compiled without lock debugging options, potentially every
consumer must be compiled including opt_kdtrace.h.
Fix this by moving KDTRACE_HOOKS into opt_global.h and remove the
dependency by opt_kdtrace.h for all files, as now only KDTRACE_FRAMES
is linked there and it is only used as a compile-time stub [0].
[0] immediately shows some new bug as DTRACE-derived support for debug
in sfxge is broken and it was never really tested. As it was not
including correctly opt_kdtrace.h before it was never enabled so it
was kept broken for a while. Fix this by using a protection stub,
leaving sfxge driver authors the responsibility for fixing it
appropriately [1].
Sponsored by: EMC / Isilon storage division
Discussed with: rstone
[0] Reported by: rstone
[1] Discussed with: philip
It turned out that on pSeries machines the call into OF modified the trap
vectors and this made further behaviour unpredictable.
With this commit I'm now able to boot multi user on a network booted
environment on my IntelliStation 285. This is a POWER5+ machine.
Discussed with: nwhitehorn
MFC after: 1 week
ibm,dma-window properties. This is especially a concern when
#ibm,dma-address-cells is not specified and we have to use the regular
#address-cells property.
MFC after: 1 week
On some machines (G5 with lots of RAM), entering OF sometimes causes the
machine to hang. Once the machine is booted, currently the only entry point
into OF is through resetting the framebuffer on mode switch on these machines.
Disabling this allows the machine to stay up at the expense of less usable
consoles after X is started.
MFC after: Never, this is only a hack
some comment I wrote about these values "lying" in the negative diff, which
referes to an earlier misunderstanding about which node to read them from.
This gets at least the PPC64 kernel booting in the mac99 system model in
QEMU after bypassing the MacIO ATA driver, which apparently still has
problems.
allows FPU emulation on AIM as well as providing support for the mfpvr
and lwsync instructions from userland on e500 cores. lwsync, in particular,
is required for many C++ programs to work correctly.
MFC after: 1 week
the actual FPU is enabled, while PCB_FPREGS indicates that the FPU state
structure in the PCB is valid. This separation reflects the situation on
FPU-less systems in which the FP state is used by the emulator but we don't
actually want to try to turn on the non-existant FPU.
Use this flag to save and restore FP regs properly on both AIM and Book-E.
As a side effect, this sets up hard-FP and Altivec on Book-E CPUs with such
abilities except for a trap handler to call enable_fpu()/enable_altivec().
it never did -- and fix an obvious missing line. Floating point emulation
on Book-E still needs some work but this gets it basically functional on
soft-FPU systems (hard FPU for Book-E is not yet implemented).
MFC after: 1 week
it more flexible about how the CCSR range is found. With this change, the
stock MPC85XX will boot on a Routerboard 800.
Hardware donated by: Benjamin Perrault
I found a stack overflow when a coredump was taken onto a ZFS volume with
heavy network activity. 2 DSI traps, plus one DECR trap, along with several
function calls in the stack, overflowed the 4 pages. 8 page stack fixes this.
Discussed with: nwhitehorn
MFC after: 1 week
a variant PCI bus instead of trying to shoehorn it into the PCI host bridge
adapter. Besides matching better the architecture on other platforms, this
also allows systems with multiple partitionable endpoints per PCI host
bridge to work correctly.
PCPU fields for curthread, by doing the same to Book-E. This closes
some potential races switching between CPUs. As a side effect, it turns out
the AIM and Book-E swtch.S implementations were the same to within a few
registers, so move that to powerpc/powerpc.
MFC after: 3 months
add actual platform probing based on PVR. Still needs a little more work:
in particular, the CCRS setup should move here.
Also turn "bare" into a truly bare platform that doesn't pretend to know how
to do anything except get the memory map. This should also be enhanced to
process the FDT reserved memory list, but that is for another day.
assumed that the MDIO bus was a direct child of the Ethernet interface. It
may not be and indeed on many device trees is not. While here, add proper
locking for MII transactions, which may be on a bus shared by several MACs.
Hardware donated by: Benjamin Perrault
words, every architecture is now auto-sizing the kmem arena. This revision
changes kmeminit() so that the definition of VM_KMEM_SIZE_SCALE becomes
mandatory and the definition of VM_KMEM_SIZE becomes optional.
Replace or eliminate all existing definitions of VM_KMEM_SIZE. With
auto-sizing enabled, VM_KMEM_SIZE effectively became an alternate spelling
for VM_KMEM_SIZE_MIN on most architectures. Use VM_KMEM_SIZE_MIN for
clarity.
Change kmeminit() so that the effect of defining VM_KMEM_SIZE is similar to
that of setting the tunable vm.kmem_size. Whereas the macros
VM_KMEM_SIZE_{MAX,MIN,SCALE} have had the same effect as the tunables
vm.kmem_size_{max,min,scale}, the effects of VM_KMEM_SIZE and vm.kmem_size
have been distinct. In particular, whereas VM_KMEM_SIZE was overridden by
VM_KMEM_SIZE_{MAX,MIN,SCALE} and vm.kmem_size_{max,min,scale}, vm.kmem_size
was not. Remedy this inconsistency. Now, VM_KMEM_SIZE can be used to set
the size of the kmem arena at compile-time without that value being
overridden by auto-sizing.
Update the nearby comments to reflect the kmem submap being replaced by the
kmem arena. Stop duplicating the auto-sizing formula in every machine-
dependent vmparam.h and place it in kmeminit() where auto-sizing takes
place.
Reviewed by: kib (an earlier version)
Sponsored by: EMC / Isilon Storage Division
