all public firmwares for all chips since the last release (1.15.37.0)
follows (it's a straight copy-paste from the Release Notes for the
12/30/2016 Unified Wire release on Chelsio's website).
T6 Firmware
++++++++++++
Version : 1.16.26.0
Date : 12/28/2016
Fixes
-----
BASE:
- Max number of egress and control queues adjusted to accomodate
co-processor mode queues.
- Fixed intermittent DDR3/4 ECC errors.
- Fixed a traffic stall when ETS BW is configured as 0%.
- Max number of ethctrl queue in VF set to 1.
ETH:
- Added a new config file option 'speed' under port section to set the
port speed. Use only when auto negotiation is off.
- FEC option removed from firmware config file. cxgbtool can be used to
change the fec setting.
- CPL_TX_TNL_LSO cpl handling added in ETH_TX_PKT_VM handler. This fixes
large tunnel tcp packet support for VxLAN.
Version : 1.16.22.0
Date : 12/05/2016
Fixes
-----
BASE:
- fw_port_type updated in fw API to match kernel.org definitions.
- Saved power by disaling unused MAC lanes.
- Configures correct power bin.
- Enhanced DDR4 performance.
- Enabled interrupts.
- Fixed an issue where filter rule for 'unicast hash' is not working.
ETH:
- Disabled auto negotiation by default because most of 100G switches do
not support AN as of today.
- Fixed flow control not getting disabled problem.
- Fixed an issue where port0 doesn't come up sometimes.
- Fixed 10G link not coming up issue.
- Fixed an issue with promiscuous mode when dcbx disabled.
OFLD:
- Fixed a connection stuck issue when abort is received during out of tx
pages backpressure.
ENHANCEMENTS
------------
BASE:
- Added inline TLS mode support.
Version : 1.16.12.0
Date : 11/11/2016
ENHANCEMENTS
------------
BASE:
- Added T6 support.
- Added T6 1G/10G/25G/40G/100G link speeds.
- Added T6 co-processor mode crypto support.
- Added facility to increase link AN+AEC timeout.
OFLD:
- Added support for all T5 offload protocols except FCoE.
iSCSI:
- iscsi completion moderation enabled.
=======================================================================
T5 Firmware
++++++++++++
Version : 1.16.26.0
Date : 12/28/2016
FIXES
-----
BASE:
- Max number of ethctrl queue in VF set to 1.
Version : 1.16.22.0
Date : 12/05/2016
FIXES
-----
BASE:
- Fixed an issue where filter rule for 'unicast hash' is not working.
ETH:
- Fixed an issue with promiscuous mode when dcbx disabled.
ENHANCEMENTS
------------
ETH:
- Added 40G-KR support.
Version : 1.16.12.0
Date : 11/11/2016
FIXES
-----
BASE:
- Fixed multiple issues related with VFs FLR processing.
- Fixed channel assignment based on number of ports in adapter.
- Fixed a crash when VM having PF assigned as passthrough mode is
rebooted.
- Handled 2nd HELLO command from the same PF without seeing BYE from the
same PF and if that is the only PF.
- A warning is printed in firmware log if PCI-E cookie generation is
enabled in serial initialization file.
- Fixed multiple issues related with Filtering.
- Enabled DSGL memory write for iscsi and rdma.
- Added new FW_PARAMS_CMD[DEV] options to retrieve Serial Configuration
and VPD version numbers.
- Fixed an issue where LVDS output was not getting enabled using vpd.
DCBX:
- Fixed DCBX CEE Incorrect class to pririty mapping.
- Fixed incorrect interpretation of DCBX IEEE PFC.
ETH:
- Adjusted the link related delay timings according to the QSFP spec.
- Improved 40G link bringup time with few switches.
OFLD:
- Do not reserve qp/cq if rdma capability is not enabled.
- Fixed an issue where approx 1600+ TOE connections were causing a
firmware fatal error.
FOiSCSI:
- Fixed an issue where unloading foiscsi driver causes mailbox timeout.
ENHANCEMENTS
------------
BASE:
- Added 10G KR/KX support.
- Added T540-BT adapter support.
- Added 4 new rss key modes for PFs and VFs.
OFLD:
- Added new WR FW_RI_FR_NSMR_TPTE_WR to improve fast MR write
performance in RDMA.
Version : 1.16.5.0
Date : 10/26/2016
FIXES
-----
BASE:
- Fixed multiple issues where FLR from multiple VFs can cause firmware
crash.
- Fixed channel assignment based on number of ports in adapter.
- Fixed the HELLO command master force api to handle the 2nd HELLO
correctly without getting BYE from the PF driver.
- Added facility to retrieve Serial configuration and VPD version. Two
new FW_PARAMS_CMD[DEV] options added to retrieve these values.
- Fixed multiple issues where FLR from multiple VFs are not completing.
- Added new RSS hash secret key modes.
- Fixed an issue where LVDS output was not getting enabled using vpd.
DCBX:
- Fixed an issue where iscsi tlv is sent incorrectly to host (DCBX CEE).
- Fixed an issue where app priority values are not handled correctly
in fw (DCBX IEEE).
ETH:
- Adjusts the link related delay timings according to the QSFP spec.
- Changed 2.5G mac speed bit to 25G mac speed bit in fw API.
- Improvement in 40G link bringup time with few switches.
OFLD:
- Do not reserve qp/cq if rdma capability is not enabled.
- Fixed an issue where approx 1600+ TOE connections were causing a
firmware fatal error.
- Fixed DSGL memory write in T5. Now iwarp and iscsi can use DSGL to do
memory write.
- Fixed multiple issues in hash filter mode where incorrect protocol
mask was getting used and affecting hash filter functionality.
- New fastpath WR FW_RI_FR_NSMR_TPTE_WR (with fully populated TPTE) is
added for small REG_MR operations.
FOiSCSI:
- Fixed an issue in foiscsi recovery path.
- Fixed an issue where foiscsi (in VM in PCIE passthrough mode) didn't
come up after VM FLR.
ENHANCEMENTS
------------
ETH:
- Implemented 1G/10G KR/KX ability.
- Implemented T540-BT adapter support.
=======================================================================
T4 Firmware
+++++++++++
Version : 1.16.12.0
Date : 11/11/2016
FIXES
-----
BASE:
- Fixed an issue where reading temperature sesors using ldst command
causes mailbox timeout.
- Added new FW_PARAMS_CMD[DEV] options to retrieve Serial Configuration
and VPD version numbers.
ETH:
- Fixed DCBX CEE Incorrect class to pririty mapping.
FOiSCSI:
- Fixed an issue where unloading foiscsi driver causes mailbox timeout.
MFC after: 3 days
Sponsored by: Chelsio Communications
(disabled by default).
To enable it, dev.rtwn.%d.radar_detection tunable need to be set
to a nonzero value.
Tested with RTL8821AU, AP mode (no radar events were seen - so,
I have no idea if it is really correct / working)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D8903
Wake-on-lan is not supported in production on any of our adapters, as
they don't have the required AUX power connector. (It's possible that
AUX power is supplied to some of our ALOM or mezz adapters, but if so
then we've never implemented or tested WoL support.)
Reviewed by: gnn
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8972
Add SPI mode (PIO-only) support for Intel Synchronous Serial Port that
can be found in several Intel's products starting from PXA family.
Most of implementations have slight differences in behavior and in
addresses for registers subset. This driver covers only BayTrail SoC
implementation for it's the only hardware I have to test it on.
Driver attaches to ACPI bus only and does not have PCI or FDT support
for now due to lack of hardware to test it on.
"intelspi" is the best name I've managed to come up with. Linux driver
name (spi-pxa2xx) does not make sense because current implementation
does not support actual PXA2xx SoCs. And as far as I know there is no
codename assigned to Intel SSP chip.
Reviewed by: br, manu
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D8896
Add ACPI part for ig4 driver to make it work on Intel BayTrail SoC where
ig4 device is available only through ACPI
Reviewed by: avg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8742
This adds support for:
- Serializing an bhnd_nvram_plist (as exported from bhnd_nvram_store, etc) to
an arbitrary NVRAM data format.
- Generating a serialized representation of the current NVRAM store's state
suitable for writing back to flash, or re-encoding for upload to a
FullMAC device.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8762
Implements bhnd_nvram_store support for parsing and operating over NVRAM
device paths, and device path aliases, as well as tracking per-path NVRAM
variable writes.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8760
This adds support for bhnd_nvram_val_convert_init() and
bhnd_nvram_val_convert_new(), which may be used to perform value
format-aware encoding of an NVRAM value to a new target format/type.
This will be used to simplify converting to/from serialized
format-specific NVRAM value representations to common external
representations.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8757
representing arbitrary Broadcom NVRAM key/value pairs.
This will be used to track pending changes in bhnd_nvram_store, and
provide support for exporting all or a device subpath for NVRAM (as
required by some fullmac wifi chipsets).
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D8756
For whatever reason, smapi, smbios, vpd are all under the "bios" directory.
smapi is only for i386, so the entire "bios" directory is only built for
i386. Break smapi out, and make only it i386-specific. Then, build the
"bios" directory for both amd64 and i386.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D8609
If bufring is used for per-TX ring descs, don't update "available"
counter, which is only used to help debugging.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8674
- 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
on the AES-NI code, and modified as needed for use on ARMv8. When loaded
the driver will check the appropriate field in the id_aa64isar0_el1
register to see if AES is supported, and if so the probe function will
signal the driver should attach.
With this I have seen up to 2000Mb/s from the cryptotest test with a single
thread on a ThunderX Pass 2.0.
Reviewed by: imp
Obtained from: ABT Systems Ltd
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8297
This makes the file name and the variable naming in the file consistent.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 1 week
Sponsored by: Microsoft
Add the dependency on pci explicitly for the pcib and vmbus drivers.
The related Makefiles are updated accordingly too.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 1 week
Sponsored by: Microsoft
Hardfloat is now default (use riscv64sf as TARGET_ARCH
for softfloat).
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8529
The feature enables us to pass through physical PCIe devices to FreeBSD VM
running on Hyper-V (Windows Server 2016) to get near-native performance with
low CPU utilization.
The patch implements a PCI bridge driver to support the feature:
1) The pcib driver talks to the host to discover device(s) and presents
the device(s) to FreeBSD's pci driver via PCI configuration space (note:
to access the configuration space, we don't use the standard I/O port
0xCF8/CFC method; instead, we use an MMIO-based method supplied by Hyper-V,
which is very similar to the 0xCF8/CFC method).
2) The pcib driver allocates resources for the device(s) and initialize
the related BARs, when the device driver's attach method is invoked;
3) The pcib driver talks to the host to create MSI/MSI-X interrupt
remapping between the guest and the host;
4) The pcib driver supports device hot add/remove.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8332
To enable event sourcing from kbdmux(4) kern.evdev.rcpt_mask value
should have bit 1 set (this is default)
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8437
VSS stands for "Volume Shadow Copy Service". Unlike virtual machine
snapshot, it only takes snapshot for the virtual disks, so both
filesystem and applications have to aware of it, and cooperate the
whole VSS process.
This driver exposes two device files to the userland:
/dev/hv_fsvss_dev
Normally userland programs should _not_ mess with this device file.
It is currently used by the hv_vss_daemon(8), which freezes and
thaws the filesystem. NOTE: currently only UFS is supported, if
the system mounts _any_ other filesystems, the hv_vss_daemon(8)
will veto the VSS process.
If hv_vss_daemon(8) was disabled, then this device file must be
opened, and proper ioctls must be issued to keep the VSS working.
/dev/hv_appvss_dev
Userland application can opened this device file to receive the
VSS freeze notification, hold the VSS for a while (mainly to flush
application data to filesystem), release the VSS process, and
receive the VSS thaw notification i.e. applications can run again.
The VSS will still work, even if this device file is not opened.
However, only filesystem consistency is promised, if this device
file is not opened or is not operated properly.
hv_vss_daemon(8) is started by devd(8) by default. It can be disabled
by editting /etc/devd/hyperv.conf.
Submitted by: Hongjiang Zhang <honzhan microsoft com>
Reviewed by: kib, mckusick
MFC after: 3 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8224
- Split driver in two parts: FDT and non-FDT
- Instead of reattach gpioled nodes to GPIO bus use
gpio_pin_get_by_ofw_idx and add ofwbus and simplebus as parrent buses
Reviewed by: loos
Differential Revision: https://reviews.freebsd.org/D8233
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
The driver currently supports chips that are fully compliant with the
JEDEC SPD / EEPROM / TS standard (JEDEC Standard 21-C,
TSE2002 Specification, frequenlty referred to as JEDEC JC 42.4).
Additionally some chips from STMicroelectronics are supported as well.
They are compliant except for their Device ID pattern.
Given the continued lack of any common sensor infrastructure, the driver
uses an ad-hoc sysctl to report the temperature.
Reviewed by: wblock (documentation)
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8174
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- multi-bss support:
* for RTL8821AU: 2 VAPs at the same time;
* other: 1 any VAP + 1 sta VAP.
RTL8188CE:
- fix IQ calibration bug (reason of significant speed degradation);
- add h/w crypto acceleration support.
USB:
- A-MPDU Tx support;
- short GI support;
Other:
- add support for RTL8812AU / RTL8821AU chipsets
(a/b/g/n only; no ac yet);
- split merged code into subparts:
* bus glue (usb/*, pci/*, rtl*/usb/*, rtl*/pci/*)
* common (if_rtwn*)
* chip-specific (rtl*/*)
- various other bugfixes.
Due to code reorganization, module names / requirements were changed too:
urtwn urtwnfw -> rtwn rtwn_usb rtwnfw
rtwn rtwnfw -> rtwn rtwn_pci rtwnfw
Tested with RTL8188CE, RTL8188CUS, RTL8188EU and RTL8821AU.
Tested by: kevlo, garga,
Peter Garshtja <peter.garshtja@ambient-md.com>,
Kevin McAleavey <kevin.mcaleavey@knosproject.com>,
Ilias-Dimitrios Vrachnis <id@vrachnis.com>,
<otacilio.neto@bsd.com.br>
Relnotes: yes
This commit, long overdue, contains contributions in the last 2 years
from Stefano Garzarella, Giuseppe Lettieri, Vincenzo Maffione, including:
+ fixes on monitor ports
+ the 'ptnet' virtual device driver, and ptnetmap backend, for
high speed virtual passthrough on VMs (bhyve fixes in an upcoming commit)
+ improved emulated netmap mode
+ more robust error handling
+ removal of stale code
+ various fixes to code and documentation (some mixup between RX and TX
parameters, and private and public variables)
We also include an additional tool, nmreplay, which is functionally
equivalent to tcpreplay but operating on netmap ports.
to add actions that run when a TCP frame is sent or received on a TCP
session in the ESTABLISHED state. In the base tree, this functionality is
only used for the h_ertt module, which is used by the cc_cdg, cc_chd, cc_hd,
and cc_vegas congestion control modules.
Presently, we incur overhead to check for hooks each time a TCP frame is
sent or received on an ESTABLISHED TCP session.
This change adds a new compile-time option (TCP_HHOOK) to determine whether
to include the hhook(9) framework for TCP. To retain backwards
compatibility, I added the TCP_HHOOK option to every configuration file that
already defined "options INET". (Therefore, this patch introduces no
functional change. In order to see a functional difference, you need to
compile a custom kernel without the TCP_HHOOK option.) This change will
allow users to easily exclude this functionality from their kernel, should
they wish to do so.
Note that any users who use a custom kernel configuration and use one of the
congestion control modules listed above will need to add the TCP_HHOOK
option to their kernel configuration.
Reviewed by: rrs, lstewart, hiren (previous version), sjg (makefiles only)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D8185
userland. It supports userland interfaces to UEFI Runtime Services. This is
indended to the the MI portion of EFI RuntimeServices support.
Differential Revision: https://reviews.freebsd.org/D8128
Reviewed by: kib@, wblock@, Ganael Laplanche
- Convert "options EVDEV" to "device evdev" and "device uinput", add
modules for both new devices. They are isolated subsystems and do not
require any compile-time changes to general kernel subsytems
- For hybrid drivers that have evdev as an optional way to deliver input
events add option EVDEV_SUPPORT. Update all existing hybrid drivers
to use it instead of EVDEV
- Remove no-op DECLARE_MODULE in evdev, it's not required, MODULE_VERSION
is enough
- Add evdev module dependency to uinput
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
like other PCI network drivers. The sys/ofed directory is now mainly
reserved for generic infiniband code, with exception of the mthca driver.
- Add new manual page, mlx4en(4), describing how to configure and load
mlx4en.
- All relevant driver C-files are now prefixed mlx4, mlx4_en and
mlx4_ib respectivly to avoid object filename collisions when compiling
the kernel. This also fixes an issue with proper dependency file
generation for the C-files in question.
- Device mlxen is now device mlx4en and depends on device mlx4, see
mlx4en(4). Only the network device name remains unchanged.
- The mlx4 and mlx4en modules are now built by default on i386 and
amd64 targets. Only building the mlx4ib module depends on
WITH_OFED=YES .
Sponsored by: Mellanox Technologies
- The original 'disengage' ATA controller model does not work properly
for all possible disk configurations. Use the newly added ATA disk
veto eventhandler to fit into all possible disk configuration.
- If the 'invalid LUN' happens on blkvsc controllers, return
CAM_DEV_NOT_THERE so that CAM will not destroy attached disks under
the blkvsc controllers.
Submitted by: Hongjiang Zhang <honzhan microsoft com>
Discussed with: mav
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7693
- Added bhnd(4) bus APIs for per-core ioctl/iost register access.
- Updated reset/suspend bhnd(4) APIs for compatibility with ioctl/iost
changes.
- Implemented core reset/suspend support for both bcma(4) and siba(4).
- Implemented explicit release of all outstanding PMU requests at the bus
level when putting a core into reset.
Approved by: adrian (mentor, implicit)
Differential Revision: https://reviews.freebsd.org/D8009
Now that all of the necessary bits for ARMv6 support for CloudABI have
been checked in, let's hook the kernel module up to the build and
document its existence.
event generation is disabled by default in favour of sysmouse. This
behavoiur is controlled by kern.evdev.rcpt_mask sysctl, bit 2 should
be set to give priority to hw over sysmouse
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
Reviewed by: hans
Differential Revision: https://reviews.freebsd.org/D7863
event generation is disabled by default in favour of kbdmux. This
behavoiur is controlled by kern.evdev.rcpt_mask sysctl, bit 3 should
be set to give priority to hw over mux
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
Reviewed by: hans
Differential Revision: https://reviews.freebsd.org/D7957
Runtime services require special execution environment for the call.
Besides that, OS must inform firmware about runtime virtual memory map
which will be active during the calls, with the SetVirtualAddressMap()
runtime call, done while the 1:1 mapping is still used. There are two
complication: the SetVirtualAddressMap() effectively must be done from
loader, which needs to know kernel address map in advance. More,
despite not explicitely mentioned in the specification, both 1:1 and
the map passed to SetVirtualAddressMap() must be active during the
SetVirtualAddressMap() call. Second, there are buggy BIOSes which
require both mappings active during runtime calls as well, most likely
because they fail to identify all relocations to perform.
On amd64, we can get rid of both problems by providing 1:1 mapping for
the duration of runtime calls, by temprorary remapping user addresses.
As result, we avoid the need for loader to know about future kernel
address map, and avoid bugs in BIOSes. Typically BIOS only maps
something in low 4G. If not runtime bugs, we would take advantage of
the DMAP, as previous versions of this patch did.
Similar but more complicated trick can be used even for i386 and 32bit
runtime, if and when the EFI boot on i386 is supported. We would need
a trampoline page, since potentially whole 4G of VA would be switched
on calls, instead of only userspace portion on amd64.
Context switches are disabled for the duration of the call, FPU access
is granted, and interrupts are not disabled. The later is possible
because kernel is mapped during calls.
To test, the sysctl mib debug.efi_time is provided, setting it to 1
makes one call to EFI get_time() runtime service, on success the efitm
structure is printed to the control terminal. Load efirt.ko, or add
EFIRT option to the kernel config, to enable code.
Discussed with: emaste, imp
Tested by: emaste (mac, qemu)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
come up as 't6nex' nexus devices with 'cc' ports hanging off them.
The T6 firmware and configuration files will be added as soon as they
are released. For now the driver will try to work with whatever
firmware and configuration is on the card's flash.
Sponsored by: Chelsio Communications
The cxgbev/cxlv driver supports Virtual Function devices for Chelsio
T4 and T4 adapters. The VF devices share most of their code with the
existing PF4 driver (cxgbe/cxl) and as such the VF device driver
currently depends on the PF4 driver.
Similar to the cxgbe/cxl drivers, the VF driver includes a t4vf/t5vf
PCI device driver that attaches to the VF device. It then creates
child cxgbev/cxlv devices representing ports assigned to the VF.
By default, the PF driver assigns a single port to each VF.
t4vf_hw.c contains VF-specific routines from the shared code used to
fetch VF-specific parameters from the firmware.
t4_vf.c contains the VF-specific PCI device driver and includes its
own attach routine.
VF devices are required to use a different firmware request when
transmitting packets (which in turn requires a different CPL message
to encapsulate messages). This alternate firmware request does not
permit chaining multiple packets in a single message, so each packet
results in a firmware request. In addition, the different CPL message
requires more detailed information when enabling hardware checksums,
so parse_pkt() on VF devices must examine L2 and L3 headers for all
packets (not just TSO packets) for VF devices. Finally, L2 checksums
on non-UDP/non-TCP packets do not work reliably (the firmware trashes
the IPv4 fragment field), so IPv4 checksums for such packets are
calculated in software.
Most of the other changes in the non-VF-specific code are to expose
various variables and functions private to the PF driver so that they
can be used by the VF driver.
Note that a limited subset of cxgbetool functions are supported on VF
devices including register dumps, scheduler classes, and clearing of
statistics. In addition, TOE is not supported on VF devices, only for
the PF interfaces.
Reviewed by: np
MFC after: 2 months
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7599
Adds support for probing and initializing bhndb(4) bridge state using
the bhnd_erom API, ensuring that full bridge configuration is available
*prior* to actually attaching and enumerating the bhnd(4) child device,
allowing us to safely allocate bus-level agent/device resources during
bhnd(4) bus enumeration.
- Add a bhnd_erom_probe() method usable by bhndb(4). This is an analogue
to the existing bhnd_erom_probe_static() method, and allows the bhndb
bridge to discover the best available erom parser class prior to newbus
probing of its children.
- Add support for supplying identification hints when probing erom
devices. This is required on early EXTIF-only chipsets, where chip
identification registers are not available.
- Migrate bhndb over to the new bhnd_erom API, using bhnd_core_info
records rather than bridged bhnd(4) device_t references to determine
the bridged chipsets' capability/bridge configuration.
- The bhndb parent (e.g. if_bwn) is now required to supply a hardware
priority table to the bridge. The default table is currently sufficient
for our supported devices.
- Drop the two-pass attach approach we used for compatibility with bhndb(4) in
the bhnd(4) bus drivers, and instead perform bus enumeration immediately,
and allocate bridged per-child bus-level resources during that enumeration.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7768
This defines a new bhnd_erom_if API, providing a common interface to device
enumeration on siba(4) and bcma(4) devices, for use both in the bhndb bridge
and SoC early boot contexts, and migrates mips/broadcom over to the new API.
This also replaces the previous adhoc device enumeration support implemented
for mips/broadcom.
Migration of bhndb to the new API will be implemented in a follow-up commit.
- Defined new bhnd_erom_if interface for bhnd(4) device enumeration, along
with bcma(4) and siba(4)-specific implementations.
- Fixed a minor bug in bhndb that logged an error when we attempted to map the
full siba(4) bus space (18000000-17FFFFFF) in the siba EROM parser.
- Reverted use of the resource's start address as the ChipCommon enum_addr in
bhnd_read_chipid(). When called from bhndb, this address is found within the
host address space, resulting in an invalid bridged enum_addr.
- Added support for falling back on standard bus_activate_resource() in
bhnd_bus_generic_activate_resource(), enabling allocation of the bhnd_erom's
bhnd_resource directly from a nexus-attached bhnd(4) device.
- Removed BHND_BUS_GET_CORE_TABLE(); it has been replaced by the erom API.
- Added support for statically initializing bhnd_erom instances, for use prior
to malloc availability. The statically allocated buffer size is verified both
at runtime, and via a compile-time assertion (see BHND_EROM_STATIC_BYTES).
- bhnd_erom classes are registered within a module via a linker set, allowing
mips/broadcom to probe available EROM parser instances without creating a
strong reference to bcma/siba-specific symbols.
- Migrated mips/broadcom to bhnd_erom_if, replacing the previous MIPS-specific
device enumeration implementation.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7748
routines available in t4_tom to manage the iSCSI DDP page pod region.
This adds the ability to use multiple DDP page sizes to the iSCSI
driver, among other improvements.
Sponsored by: Chelsio Communications
When fixing this module to build on PC98, I actually broke the build on
ARM64. On PC98 we need to pull in the sources from the MACHINE_CPUARCH
(i386), but on ARM64 we need to use the MACHINE, as MACHINE_CPUARCH is
set to aarch64 instead of just arm64.
- Added bhnd_pmu driver implementations for PMU and PWRCTL chipsets,
derived from Broadcom's ISC-licensed HND code.
- Added bhnd bus-level support for routing per-core clock and resource
power requests to the PMU device.
- Lift ChipCommon support out into the bhnd module, dropping
bhnd_chipc.
Reviewed by: mizhka
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7492
Where the cloudabi64 kernel can be used to execute 64-bit CloudABI
binaries, this one should be used for 32-bit binaries. Right now it
works on i386 and amd64.
The reason why the old vDSOs were written in C using inline assembly was
purely because they were embedded in the C library directly as static
inline functions. This was practical during development, because it
meant you could invoke system calls without any library dependencies.
The vDSO was simply a copy of these functions.
Now that we require the use of the vDSO, there is no longer any need for
embedding them in C code directly. Rewriting them in assembly has the
advantage that they are closer to ideal (less useless branching, less
assumptions about registers remaining unclobbered by the kernel, etc).
They are also easier to build, as they no longer depend on the C type
information for CloudABI.
Obtained from: https://github.com/NuxiNL/cloudabi
This driver only supports 10Mb Ethernet using PIO (the hardware supports
DMA, but the driver only does PIO). There are not any PCCard adapters
supported by this driver, only ISA cards. In addition, it does not use
bus_space but instead uses bcopy with volatile pointers triggering a
host of warnings. (if_ie.c is one of 3 files always built with
-Wno-error)
Relnotes: yes
The wl(4) driver supports pre-802.11 PCCard wireless adapters that
are slower than 802.11b. They do not work with any of the 802.11
framework and the driver hasn't been reported to actually work in a
long time.
Relnotes: yes
The si(4) driver supported multiport serial adapters for ISA, EISA, and
PCI buses. This driver does not use bus_space, instead it depends on
direct use of the pointer returned by rman_get_virtual(). It is also
still locked by Giant and calls for patch testing to convert it to use
bus_space were unanswered.
Relnotes: yes
- Added a generic bhnd_nvram_parser API, with support for the TLV format
used on WGT634U devices, the standard BCM NVRAM format used on most
modern devices, and the "board text file" format used on some hardware
to supply external NVRAM data at runtime (e.g. via an EFI variable).
- Extended the bhnd_bus_if and bhnd_nvram_if interfaces to support both
string-based and primitive data type variable access, required for
common behavior across both SPROM and NVRAM data sources.
- Extended the existing SPROM implementation to support the new
string-based NVRAM APIs.
- Added an abstract bhnd_nvram driver, implementing the bhnd_nvram_if
atop the bhnd_nvram_parser API.
- Added a CFE-based bhnd_nvram driver to provide read-only access to
NVRAM data on MIPS SoCs, pending implementation of a flash-aware
bhnd_nvram driver.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7489
This is a driver for a pre-ATAPI ISA CD-ROM adapter. As noted in
the manpage, this driver is only useful as a backend to cdcontrol to
play audio CDs since it doesn't use DMA, so its data performance is
"abysmal" (and that was true in the mid 90's).
The module works together with ipfw(4) and implemented as its external
action module.
Stateless NAT64 registers external action with name nat64stl. This
keyword should be used to create NAT64 instance and to address this
instance in rules. Stateless NAT64 uses two lookup tables with mapped
IPv4->IPv6 and IPv6->IPv4 addresses to perform translation.
A configuration of instance should looks like this:
1. Create lookup tables:
# ipfw table T46 create type addr valtype ipv6
# ipfw table T64 create type addr valtype ipv4
2. Fill T46 and T64 tables.
3. Add rule to allow neighbor solicitation and advertisement:
# ipfw add allow icmp6 from any to any icmp6types 135,136
4. Create NAT64 instance:
# ipfw nat64stl NAT create table4 T46 table6 T64
5. Add rules that matches the traffic:
# ipfw add nat64stl NAT ip from any to table(T46)
# ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96
6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96
via NAT64 host.
Stateful NAT64 registers external action with name nat64lsn. The only
one option required to create nat64lsn instance - prefix4. It defines
the pool of IPv4 addresses used for translation.
A configuration of instance should looks like this:
1. Add rule to allow neighbor solicitation and advertisement:
# ipfw add allow icmp6 from any to any icmp6types 135,136
2. Create NAT64 instance:
# ipfw nat64lsn NAT create prefix4 A.B.C.D/28
3. Add rules that matches the traffic:
# ipfw add nat64lsn NAT ip from any to A.B.C.D/28
# ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96
4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96
via NAT64 host.
Obtained from: Yandex LLC
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D6434
* make interface cloner VNET-aware;
* simplify cloner code and use if_clone_simple();
* migrate LOGIF_LOCK() to rmlock;
* add ipfw_bpf_mtap2() function to pass mbuf to BPF;
* introduce new additional ipfwlog0 pseudo interface. It differs from
ipfw0 by DLT type used in bpfattach. This interface is intended to
used by ipfw modules to dump packets with additional info attached.
Currently pflog format is used. ipfw_bpf_mtap2() function uses second
argument to determine which interface use for dumping. If dlen is equal
to ETHER_HDR_LEN it uses old ipfw0 interface, if dlen is equal to
PFLOG_HDRLEN - ipfwlog0 will be used.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
The only difference between 3 and 3B is the size of the RJ45 port.
And now we have a uboot port that expect pcduino3.dts to be present.
Reported by: imp
CloudABI executables already provide support for passing in vDSOs. This
functionality is used by the emulator for OS X to inject system call
handlers. On FreeBSD, we could use it to optimize calls to
gettimeofday(), etc.
Though I don't have any plans to optimize any system calls right now,
let's go ahead and already pass in a vDSO. This will allow us to
simplify the executables, as the traditional "syscall" shims can be
removed entirely. It also means that we gain more flexibility with
regards to adding and removing system calls.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D7438
driver. This change significantly increases the overall RX aggregation
ratio for heavily loaded networks handling 10-80 thousand simultaneous
connections.
Remove the turbo LRO code and all references to it which has now been
superceeded by the tcp_lro_queue_mbuf() function.
Tested by: Netflix
Sponsored by: Mellanox Technologies
MFC after: 1 week
f/w for the other devices supported by this driver.
Patch linked in https://reviews.freebsd.org/D6967 but not actually
a part of the review.
Obtained from DragonflyBSD.
Submitted by: Kevin Bowling <kev009@kev009.com>
MFC after: 2 weeks
Relnotes: yes
Chelsio NICs are a bit unique compared to some other NICs in that they
expose different functionality on different physical functions. In
particular, PF4 is used to manage the NIC interfaces ('t4nex' and 't5nex').
However, PF4 is not able to create VF devices. Instead, VFs are only
supported by physical functions 0 through 3. This commit adds 't4iov'
and 't5iov' drivers that attach to PF0-3.
One extra wrinkle is that the iov devices cannot enable SR-IOV until the
firwmare has been initialized by the main PF4 driver. To handle this
case, a new t4_if kobj interface has been added to permit cross-calls
between the PF drivers. The PF4 driver notifies sibling drivers when it
is fully attached. It also requests sibling drivers to detach before it
detaches. Sibling drivers query the PF4 driver during their attach
routine to see if it is attached. If not, the sibling drivers defer
their attach actions until the PF4 driver informs them it is attached.
VF devices are associated with a single port on the NIC. VF devices
created from PF0 are associated with the first port on the NIC, VFs
from PF1 are associated with the second port, etc. VF devices can
only be created from a PF device that has an associated port. Thus,
on a 2-port card, VFs are only supported on PF0 and PF1.
Reviewed by: np (earlier versions)
MFC after: 1 month
Sponsored by: Chelsio Communications
* Add acpi_if.h to the SRC list in the uart module
* Only include new acpi headers when they are needed
Obtained from: ABT Systems Ltd
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
as defined in RFC 6296. The module works together with ipfw(4) and
implemented as its external action module. When it is loaded, it registers
as eaction and can be used in rules. The usage pattern is similar to
ipfw_nat(4). All matched by rule traffic goes to the NPT module.
Reviewed by: hrs
Obtained from: Yandex LLC
MFC after: 1 month
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D6420
Instead of global variable, vmbus version is accessed through
a vmbus DEVMETHOD now.
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6953
FreeBSD support NX bit on X86_64 processors out of the box, for i386 emulation
use READ_IMPLIES_EXEC flag, introduced in r302515.
While here move common part of mmap() and mprotect() code to the files in compat/linux
to reduce code dupcliation between Linuxulator's.
Reported by: Johannes Jost Meixner, Shawn Webb
MFC after: 1 week
XMFC with: r302515, r302516
This follows NTB subsystem modularization in Linux, tuning it to FreeBSD
native NewBus interfaces. This change allows to support different types
of hardware with different drivers, support multiple NTB instances in a
system, ntb_transport module use for needs other then if_ntb, etc.
Sponsored by: iXsystems, Inc.
default. At least initially, the feature to support multiple TCP stacks is
aimed at supporting advanced use cases and TCP development, but it is not
necessarily aimed at a wide audience. Therefore, there is no need to build
and install the extra TCP stacks by default. Instead, the people who are
using or developing this functionality can add the extra option to build/
install the extra TCP stacks.
However, we do want to build the extra TCP stacks as part of test builds
(e.g. LINT or tinderbox) to ensure that developers who are testing their
changes will know that their changes do not break the additional TCP
stack modules.
After this change, a user will need to add WITH_EXTRA_TCP_STACKS=1 to
make.conf or the kernel config in order to build the extra TCP modules.
Differential Revision: https://reviews.freebsd.org/D6795
Reviewed by: sjg
Approved by: re (kib)
Support for compression has been available from July 2007 but it
was never imported due to concerns with patents once held by
STAC/HiFn. The issues have clearly been resolved so bring it
in now.
Special thanks to Brett Glass for preserving the code and
pointing documentation for the expiration case.
Obtained from: mav (through Brett Glass)
Relnotes: yes
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6739
This change is needed because 'opt_rss.h' is included by multiple source
files and RSS macro is defined as 1 within the file during build process
if option RSS is enabled in the kernel.
Submitted by: Ivan Malov <Ivan.Malov at oktetlabs.ru>
Reviewed by: gnn
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D6718
This is the initial framework to call into the MCI HAL routines and drive
the basic state engine.
The MCI bluetooth coex model uses a command channel between wlan and
bluetooth, rather than a 2-wire or 3-wire signaling protocol to control things.
This means the wlan and bluetooth chip exchange a lot more information and
signaling, even at the per-packet level. The NICs in question can share
the input LNA and output PA on the die, so they absolutely can't stomp
on each other in a silly fashion. It also allows for the bluetooth side
to signal when profiles come and go, so the driver can take appropriate
control. There's also the possibility of dynamic bluetooth/wlan duty cycle
control which I haven't yet really played with.
It configures things up with a static "wlan wins everything" coexistence,
configures up the available 2GHz channel map for bluetooth, sets a static
duty cycle for bluetooth/wifi traffic priority and drives the basics needed to
keep the MCI HAL code happy.
It doesn't do any actual coexistence except to default to "wlan wins everything",
which at least demonstrates that things do indeed work. Bluetooth inquiry frames
still trump wifi (including beacons), so that demonstrates things really do
indeed seem to work.
Tested:
* AR9462 (WB222), STA mode + bt
* QCA9565 (WB335), STA mode + bt
TODO:
* .. the rest of coexistence. yes, bluetooth, not people. That stuff's hard.
* It doesn't do the initial BT side calibration, which requires a WLAN chip
reset. I'll fix up the reset path a bit more first before I enable that.
* The 1-ant and 2-ant configuration bits aren't being set correctly in
if_ath_btcoex.c - I'll dig into that and fix it in a subsequent commit.
* It's not enabled by default for WB222/WB225 even though I believe it now
can be - I'll chase that up in a subsequent commit.
Obtained from: Qualcomm Atheros, Linux ath9k
Support for the new hashing algorithms in ZFS was introduced in r289422
However it was disconnected because FreeBSD lacked implementations of
SHA-512 (truncated to 256 bits), and Skein.
These implementations were introduced in r300921 and r300966 respectively
This commit connects them to ZFS and enabled these new checksum algorithms
This new algorithms are not supported by the boot blocks, so do not use them
on your root dataset if you boot from ZFS.
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Connect it to userland (libmd, libcrypt, sbin/md5) and kernel (crypto.ko)
Support for skein as a ZFS checksum algorithm was introduced in r289422
but is disconnected because FreeBSD lacked a Skein implementation.
A further commit will enable it in ZFS.
Reviewed by: cem
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D6166
includes the FDT option. Use OPT_FDT to conditionally compile modules
that require FDT support.
In the past we've gotten away with using the arch name as a proxy for FDT
support in makefile conditional logic, but now mips has some platforms with
fdt support and some without and we need a more direct test.
Centre for Advanced Internet Architectures
Implementing AQM in FreeBSD
* Overview <http://caia.swin.edu.au/freebsd/aqm/index.html>
* Articles, Papers and Presentations
<http://caia.swin.edu.au/freebsd/aqm/papers.html>
* Patches and Tools <http://caia.swin.edu.au/freebsd/aqm/downloads.html>
Overview
Recent years have seen a resurgence of interest in better managing
the depth of bottleneck queues in routers, switches and other places
that get congested. Solutions include transport protocol enhancements
at the end-hosts (such as delay-based or hybrid congestion control
schemes) and active queue management (AQM) schemes applied within
bottleneck queues.
The notion of AQM has been around since at least the late 1990s
(e.g. RFC 2309). In recent years the proliferation of oversized
buffers in all sorts of network devices (aka bufferbloat) has
stimulated keen community interest in four new AQM schemes -- CoDel,
FQ-CoDel, PIE and FQ-PIE.
The IETF AQM working group is looking to document these schemes,
and independent implementations are a corner-stone of the IETF's
process for confirming the clarity of publicly available protocol
descriptions. While significant development work on all three schemes
has occured in the Linux kernel, there is very little in FreeBSD.
Project Goals
This project began in late 2015, and aims to design and implement
functionally-correct versions of CoDel, FQ-CoDel, PIE and FQ_PIE
in FreeBSD (with code BSD-licensed as much as practical). We have
chosen to do this as extensions to FreeBSD's ipfw/dummynet firewall
and traffic shaper. Implementation of these AQM schemes in FreeBSD
will:
* Demonstrate whether the publicly available documentation is
sufficient to enable independent, functionally equivalent implementations
* Provide a broader suite of AQM options for sections the networking
community that rely on FreeBSD platforms
Program Members:
* Rasool Al Saadi (developer)
* Grenville Armitage (project lead)
Acknowledgements:
This project has been made possible in part by a gift from the
Comcast Innovation Fund.
Submitted by: Rasool Al-Saadi <ralsaadi@swin.edu.au>
X-No objection: core
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D6388
written by Sagi Grimberg <sagig at mellanox.com> and Max Gurtovoy
<maxg at mellanox.com>.
This code comes from https://github.com/sagigrimberg/iser-freebsd, branch
iser-rebase-11-current-r291993. It's not connected to the build just yet;
it still needs some tweaks to adapt to my changes to iSCSI infrastructure.
Big thanks to Mellanox for their support for FreeBSD!
Obtained from: Mellanox Technologies
MFC after: 1 month
Relnotes: yes
This patchset adds support to bhnd_chipc for sharing SYS_RES_MEMORY
resources with its children, allowing us to hang devices off of
bhnd_chipc that rely on access to a subset of the device register space
that bhnd_chipc itself must also allocate.
We could avoid most of this heavy lifting if RF_SHAREABLE+SYS_RES_MEMORY
wasn't limited to use with allocations at the same size/offset.
As a work-around, I implemented something similar to vga_pci.c, which
implements similar reference counting of of PCI BAR resources for its
children.
With these changes, chipc will use reference counting of SYS_RES_MEMORY
allocation/activation requests, to decide when to allocate/activate/
deactivate/release resources from the parent bhnd(4) bus.
The requesting child device is allocated a new resource from chipc's
rman, pointing to (possibly a subregion of) the refcounted bhnd resources
allocated by chipc.
Other resource types are just passed directly to the parent bhnd bus;
RF_SHAREABLE works just fine with IRQs.
I also lifted the SPROM device code out into a common driver, since this
now allows me to hang simple subclasses off of a common driver off of both
bhndb_pci and bhnd_chipc.
Tested:
* (landonf) Tested against BCM4331 and BCM4312, confirmed that SPROM still
attaches and can be queried.
Submitted by: Landon Fuller <landonf@landonf.org>
Reviewed by: mizkha@gmail.com
Differential Revision: https://reviews.freebsd.org/D6471
This adds a BHND_BUS_GET_ATTACH_TYPE(); the primary use-case is to let
chipc make a coarse-grained determination as to whether UART, SPI, etc
drivers ought to be attached, and on fullmac devices, whether a real
CPU driver ought to be skipped for the ARM core, etc.
Tested:
* BCM4331 (BHND)
* BCM4312 (SIBA)
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6492
Add directory structure and fix dependencies to be able to
build and use Cavium VNIC driver as a module.
Reviewed by: zbb
Obtained from: Semihalf
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D6345
* The default kernel and options won't build the GPL PHY bits;
* bwn(4) defaults to building as a module anyway!;
* If BWN_GPL_PHY is specified in the config file, and you uncomment
the GPL PHY bits in the module Makefile, you'll get a working
N-PHY.
This is specifically designed to be obtuse for now, as I don't want
to flip it on by default. It's easy enough for people to flip on
and build, and it's a module so the default GENERIC kernel won't be
GPL tainted.
I'll have to add an actual HAL layer that allows the GPL PHY to be loaded
before if_bwn so it can be "magic", but that'll come later.
Tested:
* BCM4321 11abg NIC, STA mode
Now that we've got access to SPROM and can access board identification,
this implements all known remaining hardware work-arounds for the bhnd(4)
PCI and PCIe-G1 cores operating endpoint mode.
Additionally, this adds an initial set of skeleton PCIe-G2 hostb and pcib
drivers, required by fullmac and newer softmac devices.
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6377
These firmwares were obtained from the "Chelsio T5/T4 Unified Wire
v2.12.0.3 for Linux" release. Changes since 1.14.4.0 (which is the
firmware in -STABLE branches) are in the "Release Notes" accompanying
the Unified Wire release and are copy-pasted here as well.
22.1. T5 Firmware
+++++++++++++++++++++++++++++++++
Version : 1.15.37.0
Date : 04/27/2016
================================================================================
FIXES
-----
BASE:
- Fixed an issue in FW_RSS_VI_CONFIG_CMD handling where the default ingress
queue was ignored.
- Fixed an issue where adapter failed to load fw by adjusting DRAM frequency.
- Fixed an issue in watchdog which was causing VM bring-up failure after reboot.
- Fixed 40G link failures with some switches when auto-negotiation enabled.
- Fixed to improve on link bring-up time.
- Per port buffer groups size doubled to improve performance.
- Fixed an issue where bogus d3hot bits were set causing traffic stall.
- Fixed an issue where sometimes adapter was not seen after reboot.
- Fixed an issue where iWARP was crashing in conjunction with traffic management.
- Fixed an issue where link failed to come up after removing twinax cable and
inserting optical module.
ETH
- Fixed a link flap issue on T580-CR.
OFLD
- Fixed a potential iSCSI data corruption issue by disabling RxFragEn flag.
FOiSCSI
- Fixed an issue in recovery path where connection was getting closed before
recovery processing was done.
- Fixed an issue in TCP port reuse.
- Fixed an issue in recovery path when large number (>64) of iSCSI connections
were in use.
- Returned ENETUNREACH if IP was not been provisioned yet and driver tried to
use given inerface.
- Fixed an issue where fw was sending ENETUNREACH event for normal tcp
disconnection.
DCBX
- Fixed an issue where iscsi tlv is sent incorrectly to host. (DCBX CEE)
- Fixed an issue where apply bit set for APP id was affecting the ETS and PFC
settings.(DCBX IEEE)
- Fixed an issue where app priority values are not handled correctly in fw.
(DCBX IEEE)
- Fixed an issue where enable/disable dcbx can cause crash. (DCBX CEE,DCBX IEEE)
FOFCoE
- Removed BB6 support.
ENHANCEMENTS
------------
BASE:
- Added new interface to program DCA settings in SGE contexts; allow 32-byte
IQE size
- Added PTP interface fw_ptp_ts to support PTP Frequeny and Offset adjustment.
- Added MPS raw interface.
ETH:
- New mailbox command FW_DCB_IEEE_CMD api added for IEEE dcbx.
OFLD:
- WR opcode is returned to host in cqe error response.
22.2. T4 Firmware
+++++++++++++++++
Version : 1.15.37.0
Date : 04/27/2016
================================================================================
FIXES
-----
BASE:
- Fixed an issue in FW_RSS_VI_CONFIG_CMD handling where default ingress queue
was ignored.
- Fixed an issue in watchdog which was causing VM bring-up failure after reboot.
- Per port buffer groups size doubled to improve performance.
- Fixed an issue where iWARP was crashing in conjunction with traffic management.
FOiSCSI:
- Fixed an issue in recovery path where connection was getting closed before
recovery processing was done.
- Fixed an issue in TCP port reuse.
- Fixed an issue in recovery path when large number (>64) of iSCSI connections
were in use.
- Returned ENETUNREACH if IP had not been provisioned yet and driver tried to
use given inerface.
DCBX
- Fixed an issue where iscsi tlv is sent incorrectly to host.(DCBX CEE)
- Fixed an issue where enable/disable dcbx can cause crash in firmware.(DCBX CEE)
FOiSCSI
- Fixes an issue where fw was sending ENETUNREACH event for normal tcp
disconnection.
FOFCoE
- Removed BB6 support.
ENHANCEMENTS
------------
BASE:
- Added MPS raw interface.
ETH:
- New mailbox command FW_DCB_IEEE_CMD api added for IEEE dcbx.
================================================================================
Obtained from: Chelsio Communications
MFC after: 6 weeks
Relnotes: yes
Sponsored by: Chelsio Communications
This adds support for the NVRAM handling and the basic SPROM
hardware used on siba(4) and bcma(4) devices, including:
* SPROM directly attached to the PCI core, accessible via PCI configuration
space.
* SPROM attached to later ChipCommon cores.
* SPROM variables vended from the parent SoC bus (e.g. via a directly-attached
flash device).
Additional improvements to the NVRAM/SPROM interface will
be required, but this changeset stands alone as working
checkpoint.
Submitted by: Landon Fuller <landonf@landonf.org>
Reviewed by: Michael Zhilin <mizkha@gmail.com> (Broadcom MIPS support)
Differential Revision: https://reviews.freebsd.org/D6196
This is an initial work in progress to use the replacement bhnd
bus code for devices which support it.
* Add manpage updates for bhnd, bhndb, siba
* Add kernel options for bhnd, bhndbus, etc
* Add initial support in if_bwn_pci / if_bwn_mac for using bhnd
as the bus transport for suppoted NICs
* if_bwn_pci will eventually be the PCI bus glue to interface to bwn,
which will use the right backend bus to attach to, versus direct
nexus/bhnd attachments (as found in embedded broadcom devices.)
The PCI glue defaults to probing at a lower level than the bwn glue,
so bwn should still attach as per normal without a boot time tunable set.
It's also not fully fleshed out - the bwn probe/attach code needs to be
broken out into platform and bus specific things (just like ath, ath_pci,
ath_ahb) before we can shift the driver over to using this.
Tested:
* BCM4311, STA mode
* BCM4312, STA mode
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6191
after r298107
Summary of changes:
- Replace all instances of FILES/TESTS with ${PACKAGE}FILES. This ensures that
namespacing is kept with FILES appropriately, and that this shouldn't need
to be repeated if the namespace changes -- only the definition of PACKAGE
needs to be changed
- Allow PACKAGE to be overridden by callers instead of forcing it to always be
`tests`. In the event we get to the point where things can be split up
enough in the base system, it would make more sense to group the tests
with the blocks they're a part of, e.g. byacc with byacc-tests, etc
- Remove PACKAGE definitions where possible, i.e. where FILES wasn't used
previously.
- Remove unnecessary TESTSPACKAGE definitions; this has been elided into
bsd.tests.mk
- Remove unnecessary BINDIRs used previously with ${PACKAGE}FILES;
${PACKAGE}FILESDIR is now automatically defined in bsd.test.mk.
- Fix installation of files under data/ subdirectories in lib/libc/tests/hash
and lib/libc/tests/net/getaddrinfo
- Remove unnecessary .include <bsd.own.mk>s (some opportunistic cleanup)
Document the proposed changes in share/examples/tests/tests/... via examples
so it's clear that ${PACKAGES}FILES is the suggested way forward in terms of
replacing FILES. share/mk/bsd.README didn't seem like the appropriate method
of communicating that info.
MFC after: never probably
X-MFC with: r298107
PR: 209114
Relnotes: yes
Tested with: buildworld, installworld, checkworld; buildworld, packageworld
Sponsored by: EMC / Isilon Storage Division
* Break out the 'g' phy code;
* Break out the debugging bits into a separate source file, since
some debugging prints are done in the phy code;
* Make some more chip methods in if_bwn.c public.
This brings the size of if_bwn.c down to 6,805 lines which is now
approaching managable.
This (and eventually migrating the other PHY code out) is in preparation
for adding the 11n PHY. No, the 11ac PHY (for the BCM4260 softmac part) isn't
yet open source, so we can't grow that. Yet.
This trims ~3,700 lines of code from if_bwn.c, bringing it down to a slightly
less crazy sounding 10,446 lines of code.
It seems that the only way to supply dtb to loader on Zynq-based
SoCs is to manually generate dtb and place it to pre-defined location
on SD card or TFTP server where loader can pick it up. More modern
approach is to add modules/dtb/%soc% module and let installworld
target generate dtb and copy them to /boot/dtb/ where they can be
loaded by ubldr
undefined symbol svr4_delete_socket which was moved from streams to the svr4 module
in r160558 that created a two-way dependency between them.
PR: 208464
Submitted by: Kristoffer Eriksson
Reported by: Kristoffer Eriksson
MFC after: 2 week
This extracts common code from bhndb_pci, bhnd_pcib, and bhnd_pci_hostb into a
simpler shared bhnd_pci base driver, and should enable SoC-side implementation
of bhnd_pcib root complex support.
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D5763
Submitted by: Jun Su <junsu microsoft com>
Reviewed by: jhb, kib, sephe
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5910
It allows implementing loadable kernel modules with new actions and
without needing to modify kernel headers and ipfw(8). The module
registers its action handler and keyword string, that will be used
as action name. Using generic syntax user can add rules with this
action. Also ipfw(8) can be easily modified to extend basic syntax
for external actions, that become a part base system.
Sample modules will coming soon.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
