Upstream GCC and devel/mips64-gcc use "octeon+" as the CPU setting for
the Octeon processor in the EdgeRouter Lite. As of r312899 the base
system GCC 4.2.1 accepts octeon+ as an alias for the Octeon support
added in r208737 for the same CPU.
Sponsored by: The FreeBSD Foundation
This patch adds missing hints for ath0 (eepromaddr) and GPIO (mask & leds).
ath0 doesn't work without eeprom hints, so this commit should make wifi
works on Onion Omega.
GPIO mask is required if you want to use gpiobus and GPIO pins on your
board. Onion Omega has several leds connected to gpio pins (one on board,
one color on dock).
This commit adds mask for gpiobus and allow you to turn off/on leds via
/dev/leds/{board,blue,green,red} (on by default).
Tested on Onion Omega 1.
Reviewed by: adrian
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D9107
- em(4) igb(4) and lem(4)
- deprecate the igb device from kernel configurations
- create a symbolic link in /boot/kernel from if_em.ko to if_igb.ko
Devices tested:
- 82574L
- I218-LM
- 82546GB
- 82579LM
- I350
- I217
Please report problems to freebsd-net@freebsd.org
Partial review from jhb and suggestions on how to *not* brick folks who
originally would have lost their igbX device.
Submitted by: mmacy@nextbsd.org
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Limelight Networks and Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D8299
Build and install an o32 set of libraries on mips64 suitable for
running o32 binaries via COMPAT_FREEBSD32. Enable COMPAT_FREEBSD32 in
MALTA64.
Reviewed by: jmallett, imp
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D9032
The format strings weren't checked when stacksave_subr() used a function
pointer for printf instead of directly using db_printf().
Reported by: kib
Sponsored by: DARPA / AFRL
Previously, the stack unwinder tried to locate the start of the function
in each frame by walking backwards until it found an instruction that
modified the stack pointer and then assumed that was the first instruction
in a function. The unwinder would only print a function name if the
starting instruction's address was an exact match for a symbol name.
However, not all functions generated by modern compilers start off functions
with that instruction. For those functions, the unwinder would fail to
find a matching function name. As a result, most frames in a stack
trace would be printed as raw hex PC's instead of a function name.
Stop depending on this incorrect assumption and just use db_printsym()
like other platforms to display the function name and offset for each
frame. This generates a far more useful stack trace.
While here, don't print out curproc's pid at the end of the trace. The
pid was always from curproc even if tracing some other process.
In addition, remove some rotted comments about hardcoded constants that
are no longer hardcoded.
Sponsored by: DARPA / AFRL
There was a single call to stacktrace() under an #ifdef DEBUG to obtain
a stack trace during a fault that resulted in a function pointer to a
printf function being passed to stacktrace_subr() in db_trace.c. The
kernel now has existing interfaces for obtaining a stack trace outside
of DDB (kdb_backtrace(), or the stack_*() API) that should be used instead.
Rather than fix the one call however, remove it since the kernel will
dump a trace anyway once it panics.
Make stacktrace_subr() static, remove the function pointer and change it
to use db_printf() explicitly.
Discussed with: kan
Sponsored by: DARPA / AFRL
Use the trapframe unwinder recently added for kernel stack overflow
panics for frames crossing MipsKernGenException and MipsKernIntr.
This provides more reliably unwinding across nested interrupts and
exceptions in the kernel.
While here, dump the value of the CAUSE and BADVADDR registers when
crossing a trapframe.
Submitted by: rwatson (original version)
Obtained from: CheriBSD
Sponsored by: DARPA / AFRL
Recognize new MACHINE_ARCH names now as we have added hardfloat support.
Switch JZ4780 to mipselhf and remove all uses of TARGET_ARCH in kernel
.mk files.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8989
Ingenic CPUs treat plain cache writeback as local-only operation and do
nothing if that is a remote CPU that holds the dirty cache line. They
do broadcast invalidate and write-and-invalidate to other cores though,
so take advantage of that and use wbinv in place of wb as this still gives
us required busdma semantics. Otherwise we'd have to do IPI to remote CPU
ourselves.
transmitter, but not both at the same time. This patch:
- Adds a dev.pcm.0.internal_codec sysctl node for selecting between
internal and external codec
- Changes playback sample rate from 96 kHz to 48 kHz for HDMI compatibility
- Enables i2s clock on codec access
Reviewed by: br
Differential Revision: https://reviews.freebsd.org/D8960
Some MIPS revisions do implement uncached-accelerate caching
attribute, but place extra requirement on access, such as
partial-word or out-of-sequence writes potentially having an
“unpredictable” effects.
On platforms that have uncached-accelerate cache attribute, map it
to VM_MEMATTR_WRITE_COMBINING. Otherwise, leave write comining
undefined.
Reviewed by: adrian, jhb (glance)
Differential Revision: https://reviews.freebsd.org/D8894
Kernel stack overflows in MIPS call panic() directly from an assembly
handler after storing the interrupted context's registers in a
trapframe. Rather than inferring the location of ra, sp, and pc from
the instruction stream, recognize the pc of a kernel stack overflow
and pull the registers from the trapframe.
Sponsored by: DARPA / AFRL
- Honor PG_NODUMP by not dumping pages with this flag set.
- Pat the watchdog during dumps to avoid a watchdog reset while writing
out a dump.
- Reformat the output during a dump to update every 10% done rather than
every 2MB dumped.
- Include UMA small pages and pages holding PV entries in minidumps.
Sponsored by: DARPA / AFRL
dump_avail[] is supposed to be a superset of phys_avail[] that
describes all of the memory ranges that should be included in a full
dump. minidumps don't consider pages described by dump_avail[] to be
valid and thus they are excluded via the is_dumpable() function. Most
MIPS platforms (including MALTA) set dump_avail[] to be identical to
phys_avail[]. In particular, phys_avail[] doesn't include the kernel
itself, so pages for the kernel and it's global variables are not
considered dumpable and not included in the dump. Fix this by setting
dump_avail[0] to the first memory address (0) rather than the end of
the kernel.
Several other MIPS platforms have the same bug, though I am only able
to test malta in qemu. The correct fix is to set dump_avail[] to
describe RAM and in particular to not set dump_avail[0] to the end of
the kernel (kernel_kseg0_end).
Sponsored by: DARPA / AFRL
As cs is stored in a uint32_t, use the last bit to store the
active high flag as it's unlikely that we will have that much CS.
Reviewed by: loos
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8614
When the kernel debugger is entered, makectx() is called to store
appropriate state from the trapframe for the debugger into a global
kdb_pcb used as the thread context of the thread entering the
debugger. Stack unwinders for DDB called via db_trace_thread() are
supposed to then use this saved context so that the stack trace for
the current thread starts at the location of the event that triggered
debugger entry.
MIPS was instead starting the stack trace of the current thread from
the context of db_trace_thread itself and unwinding back out through
the debugger to the original frame. Fix a couple of things to bring
MIPS inline with other platforms:
- Fix makectx() to store the PC, SP, and RA in the right portion of
the PCB used by db_trace_thread().
- Fix db_trace_thread() to always use kdb_thr_ctx() (and thus kdb_pcb
for the debugger thread).
- Move the logic for tracing curthread from within the current
function into db_trace_self() to match other architectures.
Sponsored by: DARPA / AFRL
This fixes backtraces from DDB in n32 kernels as uintptr_t is only a
uint32_t. In particular, the upper 32-bits of each register value were
treated as the register's value breaking both the output of register
values, but also the values of 'ra' and 'sp' required to walk up to the
previous frame.
Sponsored by: DARPA / AFRL
This commit corrects print of nomatch (newline was too early) and fix
unit number for new child in ar5315_spi (was 0, now is -1 to calculate it
according to actual system state)
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: ray, loos, mizhka
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8749
Changes include modifications in kernel crash dump routines, dumpon(8) and
savecore(8). A new tool called decryptcore(8) was added.
A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump
configuration in the diocskerneldump_arg structure to the kernel.
The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for
backward ABI compatibility.
dumpon(8) generates an one-time random symmetric key and encrypts it using
an RSA public key in capability mode. Currently only AES-256-CBC is supported
but EKCD was designed to implement support for other algorithms in the future.
The public key is chosen using the -k flag. The dumpon rc(8) script can do this
automatically during startup using the dumppubkey rc.conf(5) variable. Once the
keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O
control.
When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random
IV and sets up the key schedule for the specified algorithm. Each time the
kernel tries to write a crash dump to the dump device, the IV is replaced by
a SHA-256 hash of the previous value. This is intended to make a possible
differential cryptanalysis harder since it is possible to write multiple crash
dumps without reboot by repeating the following commands:
# sysctl debug.kdb.enter=1
db> call doadump(0)
db> continue
# savecore
A kernel dump key consists of an algorithm identifier, an IV and an encrypted
symmetric key. The kernel dump key size is included in a kernel dump header.
The size is an unsigned 32-bit integer and it is aligned to a block size.
The header structure has 512 bytes to match the block size so it was required to
make a panic string 4 bytes shorter to add a new field to the header structure.
If the kernel dump key size in the header is nonzero it is assumed that the
kernel dump key is placed after the first header on the dump device and the core
dump is encrypted.
Separate functions were implemented to write the kernel dump header and the
kernel dump key as they need to be unencrypted. The dump_write function encrypts
data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps
are not supported due to the way they are constructed which makes it impossible
to use the CBC mode for encryption. It should be also noted that textdumps don't
contain sensitive data by design as a user decides what information should be
dumped.
savecore(8) writes the kernel dump key to a key.# file if its size in the header
is nonzero. # is the number of the current core dump.
decryptcore(8) decrypts the core dump using a private RSA key and the kernel
dump key. This is performed by a child process in capability mode.
If the decryption was not successful the parent process removes a partially
decrypted core dump.
Description on how to encrypt crash dumps was added to the decryptcore(8),
dumpon(8), rc.conf(5) and savecore(8) manual pages.
EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU.
The feature still has to be tested on arm and arm64 as it wasn't possible to run
FreeBSD due to the problems with QEMU emulation and lack of hardware.
Designed by: def, pjd
Reviewed by: cem, oshogbo, pjd
Partial review: delphij, emaste, jhb, kib
Approved by: pjd (mentor)
Differential Revision: https://reviews.freebsd.org/D4712
- Defined an abstract NVRAM I/O API (bhnd_nvram_io), decoupling NVRAM/SPROM
parsing from the actual underlying NVRAM data provider (e.g. CFE firmware
devices).
- Defined an abstract NVRAM data API (bhnd_nvram_data), decoupling
higher-level NVRAM operations (indexed lookup, data conversion, etc) from
the underlying NVRAM file format parsing/serialization.
- Implemented a new high-level bhnd_nvram_store API, providing indexed
variable lookup, pending write tracking, etc on top of an arbitrary
bhnd_nvram_data instance.
- Migrated all bhnd(4) NVRAM device drivers to the common bhnd_nvram_store
API.
- Implemented a common bhnd_nvram_val API for parsing/encoding NVRAM
variable values, including applying format-specific behavior when
converting to/from the NVRAM string representations.
- Dropped the now unnecessary bhnd_nvram driver, and moved the
broadcom/mips-specific CFE NVRAM driver out into sys/mips/broadcom.
- Implemented a new nvram_map file format:
- Variable definitions are now defined separately from the SPROM
layout. This will also allow us to define CIS tuple NVRAM
mappings referencing the common NVRAM variable definitions.
- Variables can now be defined within arbitrary named groups.
- Textual descriptions and help information can be defined inline
for both variables and variable groups.
- Implemented a new, compact encoding of SPROM image layout
offsets.
- Source-level (but not build system) support for building the NVRAM file
format APIs (bhnd_nvram_io, bhnd_nvram_data, bhnd_nvram_store) as a
userspace library.
The new compact SPROM image layout encoding is loosely modeled on Apple
dyld compressed LINKEDIT symbol binding opcodes; it provides a compact
state-machine encoding of the mapping between NVRAM variables and the SPROM
image offset, mask, and shift instructions necessary to decode or encode
the SPROM variable data.
The compact encoding reduces the size of the generated SPROM layout data
from roughly 60KB to 3KB. The sequential nature SPROM layout opcode tables
also simplify iteration of the SPROM variables, as it's no longer
neccessary to iterate the full NVRAM variable definition table, but
instead simply scan the SPROM revision's layout opcode table.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8645
