bcm5715 PCI-Express dual-port NICs. Taken from the Broadcom-supplied
Linux driver, bcm-8.3.13a.
Add nascent support for the bcm5780, but (since I have no bcm5780 to
test), don't yet add an entry which allows us to match or attach to a
5780.
Change 5752 support: Follow the lead of the Broadcom-supplied Linux
driver (bcm) and the Linux tg3 driver, and treat the 5752 like a 5750.
ethernet devices: bcm5714, bcm5752 (previously the 5789, but fvdl
committed that whilst I was musing).
Add definitions to sys/dev/pci/if_bgereg.h for the Broadcom 57xx-family
ASIC revisions on these newer chips.
Add entries to the PCI-device-version and bge-internal-asic-revision
tables in sys/dev/pci/if_bge.c to use these new devices. Pending
further information, follow the lead of FreeBSD's if_bge.c driver and,
pending further info, treat these new chips as we do the 5750.
shipped from the factory with TSO-capable firmware. The TSO support
here may also work on 5705 chips, but that is (so far) untested.
TSO support written after careful reading of the Linux tg3 driver,
and (after attempting to deconstruct the cut-and-paste mess therein)
very close reading of the Broadcom-supplied Linux driver, particularly
the building of Tx-DMA buffer descriptors (bds). The TSO code herein was
then rewritten from scratch, circa 4am local time, October 27 2005.
(In other words: this is 4am software; caveat emptor.)
Other magic register settings in this patch are required; without
them, attepmting to use TSO locks up the chip. The required register
settings were extracted from the cited Linux drivers.
Note that TSO-capable firmware for the 5703/5704 is distributed in
non-GPL form with the aforementioned Linux drivers. Once the 5705 case
is debugged, (particularly the pseudo-header checksum precalculation
flagged with an XXX) downloading that TSO-capable firmware to the
5703/5704 should, in principle, enable TSO support on all but the
original bcm5700 (I forget if the 5701 can support TSO, or not).
Note also that the ``hard case '' of IP/TCP headers spanning more than
one mbuf is not handled; I haven't been able to trigger it. In any
case, since TSO applies only to packets generated by the local TCP,
and our TCP always leaves space for TCP headers and a normal IP
header, TSO on an IP/TCP header spanning multiple headers can only
arise due to insertion of IP options. I beleive that we are clearly
better off outlawing that case, and requiring ip_insertoptions()
to pull-up TCP headers on any packets with M_CSUM_TSOv4 set.
As far as I know, bge hardwar does not support TSO for IPv6.
Each call to the FreeBSD bge_start() routine the transmit producer
pointer index from the chip mailbox register BGE_MBX_TX_HOST_PROD0_LO.
The local copy of that value is then updated by bge_encap() as
bge_encap() encapsulates packets in the Tx ring. If bge_encap()
succeds in encpuslating one or more packets, bge_start() tells the
chip to start sending the newly-encinitiates writes the new value back
to the chip mailbox register.
However, comparison of the Linux drivers (Broadcom-supplied and
open-source tg3.c) and to the OpenSolaris driver confirms that
register BGE_MBX_TX_HOST_PROD0_LO is write-only to software.
Thus, we can just keep a copy in the softc, and eliminate the
(expensive) PCI register write on each call to bge_start().
``Make it so''.
some special cases for the PCI-Express versions. As there is no
documentation available, all of this is inspired from Linux or taken from
FreeBSD (itself inspired from Linux). There are a lot of magic numbers.
Tested on two BCM5751 devices as found in newer Dell computers.
(e.g., polling for a half-second or more at splnet(), blocking most
interrupts, durin an ifconfig down/ifconfig up).
Appears to help for a 5704C rev A3, which is the only chip I've
ever seen that had even a mild version of the reported problem.
found empiricaly that (at least on bcm5700s) the Rx coalesce and bd
counts cannot be updated on-the-fly; attempting to do so (even at
splhigh()) causes weird behaviour.
Instead, add a softc flag to record that the desired softc values for
Rx-interrupt thresholds have changed; check that boolean in the interrupt
routine. If set, apply the new values there and clear the flag.
BGE_MISC_TIMER register definition, and more bit definitions for
HCC-mode. (I would credit individuals, but the attributions are buried
deep in my own tree.)
* don't set the NOCRC bit in the mode control register, it can cause
problems on some chips (from the broadcom errata via FreeBSD)
* implement a fallback quirktable that is searched only using the
major asic revision, so that the driver has a shot at supporting
newer versions properly without modification
* rename asicrev -> chipid, like the FreeBSD driver
- Only BCM5705M asic rev A1 was tested.
Thanks to Bill Paul (wpaul@freebsd.org) for help and support.
Approved by: Frank van der Linden <fvdl@netbsd.org>
require that the DMA receive buffers be aligned. The driver was
deliberately mis-aligning by 2 bytes, to force the layer-2/3
headers to 32-bit alignment.
Workaround: if chip is a 5701, and is in PCI-X mode, leave the DMA
buffers aligned. If the host CPU requires alignment, copy the buffer
after reception to force aligment.
Tested on an i386 in PCI-X bus, with __NO_STRICT_ALIGNMENT forced off.
Patch and comments reworked to minimize drift from
FreeBSD if_bge.c rev 1.14.
ram for using TBI, versus MII/GMII.
FreeBSD commit log and versions:
Obtain the media type from the shared memory and only use the eeprom
as a fallback.
if_bge.c: rev 1.30
if_bgereg.h: rev 1.13
Thanks to Paul Saab @mu.org.
Add cpp definitions for the DMA control register fields needed for
5703/5704 configuration on PCI-X.
Add softc copy of internal"local control" register clobbered by reset.
Written by Bill Paul for FreeBSD. This port started out with the
port done to OpenBSD by nate@openbsd.org, but ended up looking much
more like the port of the ti driver done by drochner@netbsd.org
(they are similar in structure).
perry