History log of /freebsd/sys/powerpc/include/vmparam.h (Results 26 – 50 of 133)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 7e792cb8 03-Jan-2018 Andreas Tobler <andreast@FreeBSD.org>

The recent bump of MAXDSIZ made 32-bit binary execution on 64-bit powerpc fail.
The data segement was too big.

Add a fix-up function like on ia32 for MAXDSIZ.

While here, bring also the MAXSSIZ clo

The recent bump of MAXDSIZ made 32-bit binary execution on 64-bit powerpc fail.
The data segement was too big.

Add a fix-up function like on ia32 for MAXDSIZ.

While here, bring also the MAXSSIZ closer to amd64 and add an equal fix-up
function for MAXSSIZ.

Reviewed by: jhibbits@
Obtained from: jhibbits@
Differential Revision: https://reviews.freebsd.org/D13753

show more ...


# 70f65499 29-Dec-2017 Nathan Whitehorn <nwhitehorn@FreeBSD.org>

Add support for 64-bit PowerPC kernels to be directly loaded by kexec, which
is used as the bootloader on a number of PPC64 platforms. This involves the
following pieces:
- Making the first instructi

Add support for 64-bit PowerPC kernels to be directly loaded by kexec, which
is used as the bootloader on a number of PPC64 platforms. This involves the
following pieces:
- Making the first instruction a valid kernel entry point, since kexec
ignores the ELF entry value. This requires a separate section and linker
magic to prevent the linker from filling the beginning of the section
with stubs.
- Adding an entry point at 0x60 past the first instruction for systems
lacking firmware CPU shutdown support (notably PS3).
- Linker script changes to support the above.

MFC after: 1 month

show more ...


# 54b4b13c 24-Dec-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r326936 through r327149.


# 87879ba8 20-Dec-2017 Justin Hibbits <jhibbits@FreeBSD.org>

Increase default MAXDSIZ to 32G on powerpc64

Linking LLVM now seems to require more than 1GB data size, so increase the
default to 32G, which matches amd64.

Reviewed by: nwhitehorn


# 82725ba9 23-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r325999 through r326131.


# 51369649 20-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

show more ...


Revision tags: release/10.4.0, release/11.1.0
# e683c328 17-Mar-2017 Justin Hibbits <jhibbits@FreeBSD.org>

Introduce 64-bit PowerPC Book-E support

Extend the Book-E pmap to support 64-bit operation. Much of this was taken from
Juniper's Junos FreeBSD port. It uses a 3-level page table (page directory
l

Introduce 64-bit PowerPC Book-E support

Extend the Book-E pmap to support 64-bit operation. Much of this was taken from
Juniper's Junos FreeBSD port. It uses a 3-level page table (page directory
list -- PP2D, page directory, page table), but has gaps in the page directory
list where regions will repeat, due to the design of the PP2D hash (a 20-bit gap
between the two parts of the index). In practice this may not be a problem
given the expanded address space. However, an alternative to this would be to
use a 4-level page table, like Linux, and possibly reduce the available address
space; Linux appears to use a 46-bit address space. Alternatively, a cache of
page directory pointers could be used to keep the overall design as-is, but
remove the gaps in the address space.

This includes a new kernel config for 64-bit QorIQ SoCs, based on MPC85XX, with
the following notes:
* The DPAA driver has not yet been ported to 64-bit so is not included in the
kernel config.
* This has been tested on the AmigaOne X5000, using a MD_ROOT compiled in
(total size kernel+mdroot must be under 64MB).
* This can run both 32-bit and 64-bit processes, and has even been tested to run
a 32-bit init with 64-bit children.

Many thanks to stevek and marcel for getting Juniper's FreeBSD patches open
sourced to be used here, and to stevek for reviewing, and providing some
historical contexts on quirks of the code.

Reviewed by: stevek
Obtained from: Juniper (in part)
MFC after: 2 months
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D9433

show more ...


# b0cc56ed 09-Jan-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r311692 through r311807.


# 009dedab 08-Jan-2017 Justin Hibbits <jhibbits@FreeBSD.org>

Knock a page off VM_MAX_KERNEL_ADDRESS

There are places where checks are made against VM_MAX_KERNEL_ADDRESS, or
virtual_end (set to VM_MAX_KERNEL_ADDRESS). With 32-bit checks, an address will
alway

Knock a page off VM_MAX_KERNEL_ADDRESS

There are places where checks are made against VM_MAX_KERNEL_ADDRESS, or
virtual_end (set to VM_MAX_KERNEL_ADDRESS). With 32-bit checks, an address will
always be less than or equal to 0xffffffff. Drop a page, so those checks can
terminate loops safely.

show more ...


Revision tags: release/11.0.1, release/11.0.0
# 876d357f 11-Apr-2016 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: The FreeBSD Foundation


# f2c3b7f2 10-Apr-2016 Justin Hibbits <jhibbits@FreeBSD.org>

Restructure device mappings for Book-E.

Summary:
There is currently a 1GB hole between user and kernel address spaces
into which direct (1:1 PA:VA) device mappings go. This appears to go largely
un

Restructure device mappings for Book-E.

Summary:
There is currently a 1GB hole between user and kernel address spaces
into which direct (1:1 PA:VA) device mappings go. This appears to go largely
unused, leaving all devices to contend with the 128MB block at the end of the
32-bit space (0xf8000000-0xffffffff). This easily fills up, and needs to be
densely packed. However, dense packing wastes precious TLB1 space, of which
there are only 16 (e500v2) or 64(e5500) entries available.

Change this by using the 1GB space for all device mappings, and allow the kernel
to use the entire upper 1GB for KVA. This also allows us to use sparse device
mappings, freeing up TLB entries.

Test Plan: Boot tested on p5020.

Differential Revision: https://reviews.freebsd.org/D5832

show more ...


Revision tags: release/10.3.0
# d9b9dae1 22-Jan-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r294169 through r294598.


# 009e81b1 22-Jan-2016 Bjoern A. Zeeb <bz@FreeBSD.org>

MFH @r294567


# 59d43d11 20-Jan-2016 Glen Barber <gjb@FreeBSD.org>

MFH

Sponsored by: The FreeBSD Foundation


# 6d4bd090 16-Jan-2016 Justin Hibbits <jhibbits@FreeBSD.org>

Partially revert r294055.

This part was a botched revert of a test change.

Spotted by: alc


# 7f38eb34 15-Jan-2016 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r293850 through r294089.


# b16ddb39 15-Jan-2016 Justin Hibbits <jhibbits@FreeBSD.org>

Adjust VM_MAX_KERNEL_ADDRESS to the max address, not the minimum next.

VM_MAX_KERNEL_ADDERESS is the maximum KVA address. 0xf8000000 is the start of
device mapping space. Since several conditional

Adjust VM_MAX_KERNEL_ADDRESS to the max address, not the minimum next.

VM_MAX_KERNEL_ADDERESS is the maximum KVA address. 0xf8000000 is the start of
device mapping space. Since several conditional checks use '<=' against
VM_MAX_KERNEL_ADDRESS, bad things could feasibly happen.

show more ...


Revision tags: release/10.2.0
# 416ba5c7 22-Jun-2015 Navdeep Parhar <np@FreeBSD.org>

Catch up with HEAD (r280229-r284686).


# dad2fb7e 15-Jun-2015 Baptiste Daroussin <bapt@FreeBSD.org>

Merge from head


# 3adc74c7 09-Jun-2015 Dimitry Andric <dim@FreeBSD.org>

Merged ^/head r283871 through r284187.


# 966272ca 08-Jun-2015 Alan Cox <alc@FreeBSD.org>

Retire VM_FREEPOOL_CACHE as the next step in eliminating PG_CACHE pages.

Differential Revision: https://reviews.freebsd.org/D2712
Reviewed by: kib
Sponsored by: EMC / Isilon Storage Division


# 98e0ffae 27-May-2015 Simon J. Gerraty <sjg@FreeBSD.org>

Merge sync of head


# 51dd214c 19-Jan-2015 Enji Cooper <ngie@FreeBSD.org>

MFhead @ r277403


# d899be7d 19-Jan-2015 Glen Barber <gjb@FreeBSD.org>

Reintegrate head: r274132-r277384

Sponsored by: The FreeBSD Foundation


# 8f0ea33f 13-Jan-2015 Glen Barber <gjb@FreeBSD.org>

Reintegrate head revisions r273096-r277147

Sponsored by: The FreeBSD Foundation


123456