src/sys/powerpc, branch mainFreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=main2026-05-27T13:45:26Zsys: Consistently use ptoa() with td_kstack_pages2026-05-27T13:45:26ZJohn Baldwinjhb@FreeBSD.org2026-04-27T19:05:54Zurn:sha1:dcae0f7d7aa67ed6ec6b8da5e1b444a828898595
Suggested by: kib
Reviewed by: kib, andrew (arm changes)
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
sys: Add td_kstack_top inline helper function2026-05-27T13:45:26ZJohn Baldwinjhb@FreeBSD.org2026-04-27T19:04:22Zurn:sha1:8b9023cfc1851a18518111d286ebd59b573008c1
This function returns a pointer to the top of the kstack.
Reviewed by: kib, andrew (arm changes)
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
cpu_thread_new_kstack: Introduce new MD callback2026-05-27T13:45:22ZJohn Baldwinjhb@FreeBSD.org2026-03-28T13:56:24Zurn:sha1:2893bb741b4bb67bde9ee27e5f18ea5715e3f0e9
Previously, the cpu_thread_alloc callback was invoked each time a
kernel stack was allocated for a thread. This included thread
creation, but it was also invoked if a recycled thread had to allocate
a new kstack. This means that cpu_thread_alloc could be called
multiple times for a single thread, but cpu_thread_free is only called
once. Not only that, but the cpu_thread_alloc callback can't tell if
it is being invoked on a new thread object, or a recycled thread.
Calling *_alloc multiple times on an object is also atypical for
kernel APIs.
As a result of this confusion, amd64 was potentially leaking an XSAVE
buffer each time a new kstack was allocated for an existing thread,
since cpu_thread_alloc for amd64 always allocated a new XSAVE buffer.
In practice, this edge case is probably rare. A process object needs
to be recycled where either the new or old process is a kernel process
with a non-default kernel stack size.
Nevertheless, to ease the confusion, redefine cpu_thread_alloc to only
be called once when a new thread is allocated. The new callback,
cpu_thread_new_kstack is invoked each time a kstack is allocated for a
thread, including both at thread creation time and if a recycled
thread allocates a new kstack. The new callback should set any fields
whose value is dependent on td_kstack (e.g. the user frame in
td_frame, or td_pcb if the PCB is allocated on the kstack).
Reviewed by: kib, andrew (arm changes)
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
cpu_fork: Remove redundant assignments to td_pcb and td_frame2026-05-27T13:43:43ZJohn Baldwinjhb@FreeBSD.org2026-03-26T17:39:52Zurn:sha1:187b46e1c4d761efe2e92f662d68c0f49cd04b44
cpu_thread_alloc() already sets these fields anytime td_kstack changes.
Reviewed by: kib, andrew (arm changes)
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
powerpc: Remove stale include line from MPC85XX2026-05-19T19:53:46ZJohn Baldwinjhb@FreeBSD.org2026-05-19T19:53:46Zurn:sha1:d84a691a3590c85a4068dd23644efa478c368a03
The stale include line caused config -m to fail with an error trying
to parse the config file during make universe/tinderbox which in turn
caused universe/tinderbox to abort without building any powerpc
kernels (or subsequent architectures such as riscv64) with the error:
make[2]: freebsd/main/Makefile:767: Target architecture for powerpc/conf/MPC85XX unknown. config(8) likely too old.
in .for loop from freebsd/main/Makefile:761 with kernel = MPC85XX
in make[2] in directory "freebsd/main"
make[2]: stopped making "universe_kernels" in freebsd/main
*** Error code 1
Reported by: npn, many others
Fixes: fd8d34ce272b ("dpaa: Migrate from NCSW base to a home-grown driver")
types: provide __SIZEOF_{INT{8,16,32,64},TIME,TIME32}_T2026-05-08T19:37:24ZRyan Libbyrlibby@FreeBSD.org2026-05-08T19:37:24Zurn:sha1:94323513dd5070bf1fc3c191c560bd7e17da8931
Suggested by: kib
Reviewed by: imp, kib
Discussed with: emaste, jrtc27
Differential Revision: https://reviews.freebsd.org/D56783
dpaa: Migrate from NCSW base to a home-grown driver2026-05-03T19:09:29ZJustin Hibbitsjhibbits@FreeBSD.org2026-04-24T03:38:19Zurn:sha1:fd8d34ce272ba40f3e0218198ba542a29c390a4a
The NCSW reference base requires tuning for each target, and currently
is configured for FMANv2. This doesn't readily work on FMANv3 devices,
such as the T-series powerpc, or the LS1043 ARM. Since Freescale/NXP
abandoned the NCSW driver a decade ago, it makes sense to abandon it
ourselves as well. This new driver uses a combination of the NCSW
driver and the Linux driver (BSD/GPL dual licensed) as a reference, but
contains no actual code from them.
The DPAA (Data Path Acceleration Architecture) subsystem consists of the
following components:
* BMan -- Buffer Manager. Manages buffer pools of different sizes (one
size per pool, up to 64 pools)
* QMan -- Queue Manager. Manages the interfaces between DPAA-based
components and the CPU(s).
* FMan -- Frame Manager. Responsible for all ethernet-related
processing. Consists itself of the following components:
* Ports -- interfaces to the QMan. An ethernet interface consists of
2 ports.
Ports use "Next-invoked action" (NIA) descriptors to form a pipeline
for processing on receive and transmit.
* Parser -- performs protocol header parsing and validation. Both
hardware and software parsers are available.
* KeyGen -- Key generator, used to start the classification process
(for the Policer), generating FQIDs and other keys based on the
frame input.
* Policer -- performs traffic shaping and classification
* MAC -- SoC specific ethernet MAC (dTSEC, TGEC, mEMAC). Currently
supports dTSEC and mEMAC, along with their MDIO blocks.
Additional components not yet handled:
SEC -- Security engine (crypto)
RE -- RAID engine
RapidIO
DCE -- Decompression/Compression engine, supports ZLIB, DEFLATE, and
GZIP, as well as base64 encoding and decoding.
BMan and QMan are accessed via cache-coherent portals, using ring
buffers as I/O. The intent is for portals to be per-CPU (core/thread)
to reduce locking contention and improve performance. This driver pins
interrupt handlers to the CPU "owning" a given portal, and uses critical
sections to prevent switching while accessing the portal.
powerpc: refactor dmamap setup; free dmamap in error paths2026-05-01T21:15:06ZAdrian Chaddadrian@FreeBSD.org2026-04-01T05:21:15Zurn:sha1:0de6295af231aa5c13e1da2f40b29106962b6363
* refactor the dmamap allocation / setup path for future code changes
to align with arm64 busdma code;
* free the dmamap allocation if the dma segment list can't be allocated;
* free the dmamap allocation during the busdma dmamem allocation path
if the actual memory allocation itself fails.
Locally tested:
* POWER9 ppc64le native boot, Raptor Engineering Blackbird
* POWER8 ppc6le, IBM POWER S822LC
https://reviews.freebsd.org/D56244
powerpc: busdma declaration shuffling2026-05-01T21:14:59ZAdrian Chaddadrian@FreeBSD.org2026-04-01T00:23:56Zurn:sha1:c7040d3eaa03a9dd27fde69ccf585a76dfbb2c6c
Shuffle some of the declarations around to match other implementations.
Expected to be a no-op.
Differential Revision: https://reviews.freebsd.org/D56243
powerpc: use local flags for bounce buffers instead of common flags2026-05-01T21:14:52ZAdrian Chaddadrian@FreeBSD.org2026-04-01T00:04:28Zurn:sha1:7c57d2499ceee81aa386430d4d9e6d9080d50f94
Migrate to using local flags for bounce buffers instead of the
common flag field.
Differential Revision: https://reviews.freebsd.org/D56208