PL (programmable logic) uses FCLK0..FCLK3 as a clock sources.
Normally they're configured by first stage boot loader (FSBL)
and normal user never has to touch them. These sysctls may come
useful for hardware developers
hw.fpga.fclk.N.source: clock source (IO, DDR, ARM)
hw.fpga.fclk.N.freq: requested frequency in Hz
hw.fpga.fclk.N.actual_freq: actual frequency in Hz (R/O)
hw.fgpa.level_shifters: 0/1 to enable/disable PS-PL level shifters,
normally they're enabled either by FSBL or after programming
FPGA through devcfg(4)
- Add no_dad and ignoreloop per-IF knob. no_dad disables DAD completely,
and ignoreloop is to prevent infinite loop in loopback probing state when
loopback is permanently expected.
emulate the instructions used in function entry and exit.
For function entry ARM will use a push instruction to push up to 16
registers to the stack. While we don't expect all 16 to be used we need to
handle any combination the compiler may generate, even if it doesn't make
sense (e.g. pushing the program counter).
On function return we will either have a pop or branch instruction. The
former is similar to the push instruction, but with care to make sure we
update the stack pointer and program counter correctly in the cases they
are either in the list of registers or not. For branch we need to take the
24-bit offset, sign-extend it, and add that number of 4-byte words to the
program counter. Care needs to be taken as, due to historical reasons, the
address the branch is relative to is not the current instruction, but 8
bytes later.
This allows us to use the following probes on ARM boards:
dtrace -n 'fbt::malloc:entry { stack() }'
and
dtrace -n 'fbt:🆓return { stack() }'
Differential Revision: https://reviews.freebsd.org/D2007
Reviewed by: gnn, rpaulo
Sponsored by: ABT Systems Ltd
Implement a small enhancement to the original qsort implementation:
If the data is 32 bit aligned we can side-step the long type
version and use int instead.
The change brings a modest but significant improvement in
32 bit workloads.
Relnotes: yes
PR: 135718
Taken from: ache
Passing through physical block size/offset from underlying storage allows
guest to manage proper data and I/O alignment to improve performance.
MFC after: 2 weeks
rework the code a little bit to use this function consistently to cleanup
all the changes made as part of the probe phase.
This fixes an issue where a FDT child node without a matching driver could
leave the GPIO pins mapped and prevent the further use of them.
This prints a warning when your system have a hinted child or a FDT child
node for which you don't have a matching driver:
gpiobus0: <unknown device> at pin(s) 24 irq 24
have the same meaning and occupy the same memory address in the trapframe
courtesy of union. Avoid some pointless #ifdef by spelling them both 'DAR'
in the trapframe.
-mno-align-long-strings when compiling with base gcc. This is checked
by comparing the version number against 4.2.1, which is not exactly
right, but good enough. (There is no other way to check whether we are
using the non-standard gcc in base, as far as I know.)
Reported by: rodrigc
MFC after: 3 days
Support includes surrounded by '"' or '<' '>'
Print warnings about bad syntax
Correctly navigate through include directories to find calendar files
Correctly support multiple includes
Tested by: gjb
MFC after: 1 week
While it may have little sense, text and logout requests can be queued.
If they are, they consume cmdsn, so we should increment our conn_cmdsn.
MFC after: 1 week
When several threads are trying to send datagram to the same destination,
but fragmentation is disabled and datagram size exceeds link MTU,
ip6_output() calls pfctlinput2(PRC_MSGSIZE). It does notify all
sockets wanted to know MTU to this destination. And since all threads
hold PCB lock while sending, taking the lock for each PCB in the
in6_pcbnotify() leads to deadlock.
RFC 3542 p.11.3 suggests notify all application wanted to receive
IPV6_PATHMTU ancillary data for each ICMPv6 packet too big message.
But it doesn't require this, when we don't receive ICMPv6 message.
Change ip6_notify_pmtu() function to be able use it directly from
ip6_output() to notify only one socket, and to notify all sockets
when ICMPv6 packet too big message received.
PR: 197059
Differential Revision: https://reviews.freebsd.org/D1949
Reviewed by: no objection from #network
Obtained from: Yandex LLC
MFC after: 1 week
Sponsored by: Yandex LLC
> List of fixes:
* use correct format for GID printouts
* double array indexing
* spelling in printouts
* void pointer arithmetic
* allow more receive rings
* correct maximum number of transmit rings
* use "const" instead of "static" for constants
* check for invalid VLAN tags
* check for lack of IRQ resources
> Added more hardware specific defines
> Added more verbose printouts of firmware status codes
Sponsored by: Mellanox Technologies
MFC after: 3 days
* Force the arge0 interface to not use a PHY for speed negotiation
for now. It'd be nice to do it, but right now the RGMII interface
to the switch needs to stay at 1000/full in order to match what
the switch side of the port is programmed as.
So until that's all sorted out, disconnect arge0 from the PHY
and leave it at fixed at 1000/full.
I noticed this when I tried using a busted ethernet cable that
forced the PHY to negotiate 100/full. The switch was fine and
it negotiated to 100/full, but then arge0 saw the link update
and set the speed to 100/full when the switch side of that
hook up was set to 1000/full. Tsk.
* When using argemdio, the mdio device resets and initialises
the MAC, /not/ the arge_attach (or, as I discovered, arge_init.)
So arge1 wasn't being fully initialised and thus no traffic
would ever flow.
So until I tidy up that mess, just create an argemdio bus for
arge1. It's totally fine; it won't do anything or find anything
attached to it.
Tested:
* AP135 reference board - both arge0 and arge1 now work.
Safetly belt can be disabled with the -F flag
Additionally, add the --not-running-from-cron flag they bypasses the TTY requirement, and allows freebsd-update to be invoked by orchestration frameworks, scripts, or otherwise.
PR: 196760
Differential Revision: https://reviews.freebsd.org/D1550
Reviewed by: cperciva, delphij
Approved by: bcr (mentor), rodrigc (src)
MFC after: 1 month
Relnotes: yes
Sponsored by: ScaleEngine Inc.
As it turns out, the density code for DAT-160 (0x48) is the same
as for SDLT220. Since the SDLT values are already in the table,
we will leave them in place.
Thanks to Harald Schmalzbauer for confirming the DAT-72 density code.
lib/libmt/mtlib.c:
Add DAT-72 density code, and commented out DAT-160 density
code. Explain why DAT-160 is commented out. Add notes
explaining where the bpi values for these formats came from.
usr.bin/mt/mt.1:
Add DAT-72 density code, and add a note explaining that
the SDLTTapeI(110) density code (0x48) is the same as
DAT-160.
Sponsored by: Spectra Logic
MFC after: 3 weeks
