Since the DPAA code is from a third party, with minimal edits, there is no
intent to fix these specific warnings at this time. Hide these warnings to
prevent the noise from hiding real warnings.
This involved several changes:
* Since lld does not like text relocations, replace SMP boot page text relocs
in booke/locore.S with position-independent math, and track the virtual base
in the SMP boot page header.
* As some SPRs are interpreted differently on clang due to the way it handles
platform-specific SPRs, switch m*dear and m*esr mnemonics out for regular
m*spr. Add both forms of SPR_DEAR to spr.h so the correct encoding is selected.
* Change some hardcoded 32 bit things in the boot page to be pointer-sized, and
fix alignment.
* Fix 64-bit build of booke/pmap.c when enabling pmap debugging.
Additionally, I took the opportunity to document how the SMP boot page works.
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D21999
Many arm kernel configs bogusly specified WERROR=-Werror. There's no
reason for this because the default is that and there's no reason to
override. These date from a time when we needed to add additional
warning->error suppression. They are obsolete and were cut and paste
propagated from file to file.
Comment out all the WERROR=.... lines in powerpc. They aren't bogus,
but were appropriate for the old defaults for gcc4.2.1. Now that we've
made the policy decision to suppress -Werror by default on these
platforms, it is appropriate to comment these out. People wishing to
fix these errors can still un-comment them out, or say WERROR=-Werror
on the command line.
Fix two instances (cut and paste propagation) of hard-coded -Werror
in x86 code. Replace with ${WERROR} instead. This is a no-op change
except for people who build WERROR=-Wno-error :).
This should fix tinderbox / CI breakage.
iflib is already a module, but it is unconditionally compiled into the
kernel. There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.
Reviewed by: marius
Discussed with: erj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19041
This adds some support for ARM as well as 64-bit. 64-bit on PowerPC is
currently not working, and ARM support has not been completed or tested on the
FreeBSD side.
As this was imported from a Linux tree, it includes some Linux-isms
(ioread/iowrite), so compile with the LinuxKPI for now. This may change in the
future.
Linux has a slightly different device tree definition for DPAA than originally
done in the FreeBSD driver. This changes the driver to be mostly compatible
with the Linux device tree definitions. Currently the differences are:
bman-portals: compatible = "fsl,bman-portals" (Linux is "simple-bus")
qman-portals: compatible = "fsl,qman-portals" (Linux is "simple-bus")
fman: compatible = "fsl,fman" (Linux is "simple-bus")
The Linux device tree doesn't specify anything for rgmii in the mdio. This
change still requires the device tree to specify the phy-handle, and doesn't yet
support tbi.
Instead replace it with a different hack, that turns fman into a simplebus
subclass, and maps its children within its address space.
Since all PHY communication is done through dtsec0's mdio space, the FDT
contains a reference to the dtsec0 mdio handle in all nodes that need it.
Instead of using Freescale's implementation for MII access, use our own (copied
loosely from the eTSEC driver, and could possibly be merged eventually). This
lets us access the registers directly rather than needing a full dtsec interface
just to access the registers.
Future directions will include turning fman into more of a simplebus, and not
mapping the region and playing games. This will require changes to the dtsec
driver to make it a child of fman, and possibly other drivers as well.
Summary:
MPC85XX and QorIQ are very similar. When the DPAA dTSEC driver was
added, QORIQ_DPAA was brought in as a config option to support the differences
in hardware register settings between QorIQ (e500mc-, e5500- based) SoCs and
QUICC (e500v1/e500v2-based) SoCs, particularly in the Local Access Window (LAW)
target settings.
Unify these settings using macros to hide details and ease porting, and use a
new function (mpc85xx_is_qoriq()) to distinguish between QorIQ and QUICC SoCs at
runtime.
An alternative to using the function could be to use a variable initialized at
platform attach time, which may incur less overhead at runtime. Since it's not
in the critical path once booted, this optimization doesn't seem necessary at
first pass.
Reviewed by: nwhitehorn
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D7294
Freescale's QorIQ line includes a new ethernet controller, based on their
Datapath Acceleration Architecture (DPAA). This uses a combination of a Frame
manager, Buffer manager, and Queue manager to improve performance across all
interfaces by being able to pass data directly between hardware acceleration
interfaces.
As part of this import, Freescale's Netcomm Software (ncsw) driver is imported.
This was an attempt by Freescale to create an OS-agnostic sub-driver for
managing the hardware, using shims to interface to the OS-specific APIs. This
work was abandoned, and Freescale's primary work is in the Linux driver (dual
BSD/GPL license). Hence, this was imported directly to sys/contrib, rather than
going through the vendor area. Going forward, FreeBSD-specific changes may be
made to the ncsw code, diverging from the upstream in potentially incompatible
ways. An alternative could be to import the Linux driver itself, using the
linuxKPI layer, as that would maintain parity with the vendor-maintained driver.
However, the Linux driver has not been evaluated for reliability yet, and may
have issues with the import, whereas the ncsw-based driver in this commit was
completed by Semihalf 4 years ago, and is very stable.
Other SoC modules based on DPAA, which could be added in the future:
* Security and Encryption engine (SEC4.x, SEC5.x)
* RAID engine
Additional work to be done:
* Implement polling mode
* Test vlan support
* Add support for the Pattern Matching Engine, which can do regular expression
matching on packets.
This driver has been tested on the P5020 QorIQ SoC. Others listed in the
dtsec(4) manual page are expected to work as the same DPAA engine is included in
all.
Obtained from: Semihalf
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
