for i386, and from the code inspection, nothing in the
arm/mips/sparc64 implementations depends on it.
Discussed with: imp, nwhitehorn
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
This avoids universe trying to build MALTA_COMMON and fail due to
the problem addressed in r276773.
Include std.MALTA from the MALTA mipsel and MALTA64 mips64el config files,
where the machine lines exist.
code in sys/kern/kern_dump.c. Most dumpsys() implementations are nearly
identical and simply redefine a number of constants and helper subroutines;
a generic implementation will make it easier to implement features around
kernel core dumps. This change does not alter any minidump code and should
have no functional impact.
PR: 193873
Differential Revision: https://reviews.freebsd.org/D904
Submitted by: Conrad Meyer <conrad.meyer@isilon.com>
Reviewed by: jhibbits (earlier version)
Sponsored by: EMC / Isilon Storage Division
socket-buffer implementations, introduce a return value for MCLGET()
(and m_cljget() that underlies it) to allow the caller to avoid testing
M_EXT itself. Update all callers to use the return value.
With this change, very few network device drivers remain aware of
M_EXT; the primary exceptions lie in mbuf-chain pretty printers for
debugging, and in a few cases, custom mbuf and cluster allocation
implementations.
NB: This is a difficult-to-test change as it touches many drivers for
which I don't have physical devices. Instead we've gone for intensive
review, but further post-commit review would definitely be appreciated
to spot errors where changes could not easily be made mechanically,
but were largely mechanical in nature.
Differential Revision: https://reviews.freebsd.org/D1440
Reviewed by: adrian, bz, gnn
Sponsored by: EMC / Isilon Storage Division
The QCA955x has more mux interrupts going on - and the AR934x actually does,
but I cheated and assigned wlan and pcie to the same interrupt line.
They are, there's just a status register mux that I should've been using.
Luckily this isn't too bad a change in itself - almost all of the
Atheros MIPS configurations use a _BASE file to inherit from.
Except PB92, which I should really fix up at some point.
The AR934x will use the legacy apb for now until I write its replacement.
The QCA955x SoC I'm doing bring-up on will have a separate qca955x_apb.c
implementation that includes hooking into IP2/IP3 and doing further
interrupt demuxing as appropriate.
APB mux.
It's larger than the AR71xx because it needs to replace the nexus
for some devices (notably wifi) and the wifi driver (if_ath_ahb.c)
reads the SPI data directly at early boot whilst it's memory mapped
in.
I'm eventually going to rip it out and replace it with a firmware
interface similar to what exists for the if_ath_pci.c path -
something early on (likely something new that I'll write) will
suck in the calibration data into a firmware API blob and that'll
be accessed from if_ath_ahb.c.
But, one thing at a time.
Tested:
* QCA955x SoC, AP135 development board
This adds the initial frequency poking and configures up enough
for it to boot and spit out data over the console.
There's still a whole bunch of work to do in the reset path
and devices to support this thing, but hey, it's alive!
ath> go 0x80050100
## Starting application at 0x80050100 ...
CPU platform: Atheros AR9558 rev 0
CPU Frequency=720 MHz
CPU DDR Frequency=600 MHz
CPU AHB Frequency=200 MHz
platform frequency: 720 MHz
CPU reference clock: 0 MHz
CPU MDIO clock: 40 MHz
Done at: hackathon
Obtained from: Linux OpenWRT, Qualcomm Atheros
There's likely a bunch of register offsets that I have to add the
register window base to before I use them.
Done at: Hackathon
Obtained from: Linux OpenWRT
The AR934x and later (which will turn up eventually) have a new GPIO
output configuration option - a real MUX rather than a "GPIO or this
function."
For now I'm squirreling it away in the CPU code just so it's done -
I may move this to the GPIO layer later.
Specifically, this is required for setting up some boards that have
external receive side LNA (low noise amplifier) that gets switched on/off
by the on-chip wireless MAC. If we don't add this support for those
boards then we'll end up with really poor performance.
(I don't yet have one of those APs, but it'll likely show up in a week.)
Obtained from: Linux OpenWRT
The elftoolchain project includes these additional defines for various
userland programs. Given that arch-specific defines are still interesting
in the context of userland programs reading or writing ELF metadata, they
should be included in top-level ELF headers.
Remove duplicate defines from ARM and MIPS elf headers.
Submitted by: will (initial version)
Reviewed by: imp, will
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D844
managing pages from different address ranges. Generally speaking, this
feature is used to increase the likelihood that physical pages are
available that can meet special DMA requirements or can be accessed through
a limited-coverage direct mapping (e.g., MIPS). However, prior to this
change, the configuration of the free lists was static, i.e., it was
determined at compile time. Consequentally, free lists could be created
for address ranges that held no actual pages, for example, on 32-bit MIPS-
based systems with 512 MB or less of physical memory. This change makes
the creation of the free lists dynamic, i.e., it is based on the available
physical memory at boot time.
On 64-bit x86-based systems with 64 GB or more of physical memory, create
free lists for managing pages with physical addresses below 4 GB. This
change is to address reported problems with initializing devices that
require the allocation of physical pages below 4 GB on some systems with
128 GB or more of physical memory.
PR: 185727
Differential Revision: https://reviews.freebsd.org/D1274
Reviewed by: jhb, kib
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
It's redundant at the moment since it can be obtained from the trapframe
on the architectures where DTrace is supported, but this won't be the case
with ARM.
for counter mode), and AES-GCM. Both of these modes have been added to
the aesni module.
Included is a set of tests to validate that the software and aesni
module calculate the correct values. These use the NIST KAT test
vectors. To run the test, you will need to install a soon to be
committed port, nist-kat that will install the vectors. Using a port
is necessary as the test vectors are around 25MB.
All the man pages were updated. I have added a new man page, crypto.7,
which includes a description of how to use each mode. All the new modes
and some other AES modes are present. It would be good for someone
else to go through and document the other modes.
A new ioctl was added to support AEAD modes which AES-GCM is one of them.
Without this ioctl, it is not possible to test AEAD modes from userland.
Add a timing safe bcmp for use to compare MACs. Previously we were using
bcmp which could leak timing info and result in the ability to forge
messages.
Add a minor optimization to the aesni module so that single segment
mbufs don't get copied and instead are updated in place. The aesni
module needs to be updated to support blocked IO so segmented mbufs
don't have to be copied.
We require that the IV be specified for all calls for both GCM and ICM.
This is to ensure proper use of these functions.
Obtained from: p4: //depot/projects/opencrypto
Relnotes: yes
Sponsored by: FreeBSD Foundation
Sponsored by: NetGate
Special thanks to Nicholas Esborn for the loaner router to get this
target bootstrapped.
Review: D777
Reviewed by: adrian
Sponsored by: Nicholas Esborn <nick@desert.net>
commit 6d3c4c09226ad6bdd662e3e52489ef294a6ce298
Add terasic_mtl vt(4) framebuffer driver
terasic_mtl can be built with syscons(4) and vt(4) attachments, selected
at compile time.
commit 33240259b47a7c990a5a88a19f133a5600432a4c
Clear terasic_mtl text buffer on attach
commit d188c2d2412953f949624aa35cd07082830943c9
Update terasic vt(4) driver for FreeBSD r269783
commit d1cc54eee852fa4fc9d359d5bb2171d24ec73369
Safety belt to ensure vt(4) fb parameters are correct
commit 76e6d468ef45711d7952786095fc4791289ebb4b
Improve terasic_mtl_vt fdt parsing
- Use OF_getencprop to avoid need for explicit endian handling
(submitted by ray@freebsd.org)
- Check for expected length and correct pointer type
commit 3e2524b8995ab66e8a9295e4c87cbc7126eeddf4
Correct device_printf usage
commit 9e53e3c8e0766414e25662c95b09cc51c92443b0
Switch framebuffer to match host endianness
Xorg and xf86-video-scfb work much better with a native-endian
framebuffer.
commit 0f49259d596321ed85288ac0e1fb4ee1c966df48
Switch DE4 to vt(4) and enable kbdmux
commit 5bc96ebc89db7d134ad478335090c8477c1677c7
Add missing \n in device_printf calls
Submitted by: emaste
Sponsored by: DARPA, AFRL
This change saves/restores the callee-saved MIPS floating point
registers as documented by the o32/n32/n64 spec ("MIPSpro N32
ABI Handbook", Table 2-1) for the _setjmp(3), _longjmp(3),
setjmp(3) and longjmp(3) C library functions. This is only
included when the C library is built with hardware floating point
support (or when "SOFTFLOAT" is not defined).
Submitted by: sson
MFC after: 1 month
Sponsored by: DARPA, AFRL
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
and casuword(9), but do not mix value read and indication of fault.
I know (or remember) enough assembly to handle x86 and powerpc. For
arm, mips and sparc64, implement fueword() and casueword() as wrappers
around fuword() and casuword(), which means that the functions cannot
distinguish between -1 and fault.
On architectures where fueword() and casueword() are native, implement
fuword() and casuword() using fueword() and casuword(), to reduce
assembly code duplication.
Sponsored by: The FreeBSD Foundation
Tested by: pho
MFC after: 2 weeks (ia64 needs treating)
- Wrong integer type was specified.
- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.
- Logical OR where binary OR was expected.
- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.
- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.
- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.
- Updated "EXAMPLES" section in SYSCTL manual page.
MFC after: 3 days
Sponsored by: Mellanox Technologies
