> - Move TX ring full sanity check further up and check the number of DMA
> segments from the DMA map, instead of counting the DMA segments in the
> for loop and breaking out later.
> - Unload the DMA map if encountering an error condition.
- remove an empty statement in if() clause by inverting logic
- use KDASSERT(9) rather than #ifdef DEBUG + KASSERT(9)
- replace commented out M_WRITABLE() with !M_READONLY(9)
1. Instead of enabling the buffer manager hardware-FSM only on
pre-5705 devices, initialize the buffer manager on all bge devices.
Modelled on the Broadcom-authored Linux driver.
2. Instead of enabling the memory arbiter hardware-FSM only on
pre-5705 devices, initialize the memory arbiter on all bge devices.
Modelled on the Broadcom-authored Linux driver.
3. Ditto the second copy of code which enables the memory arbiter.
Also, add an XXX asking, why taunt the chip this way a second time?
(The most plausible explanatoin is that enabling the memory arbiter
twice is my own darn fault, likely a cut-and-paste glitch I made many
moons ago, when re-ordering hardware enables to match the Linux drivers.)
attached via PCI-Express:
The previous code first checked that the bge ASIC-revision matched the
5750 ASIC-revisoin (the bcm5721 has the same ASIC revision). However, the
bcm5752 is also a PCI-Express device, but has a different ASIC revision.
Thus, we were setting sc->bge_pcie to zero for bcm5752s, which in turn
causes bge_reset() to not perform required PCI-Express setup.
The test for a 5750 ASIC revision may (or may not) have been carried
across from the FreeBSD bge(4) driver. FreeBSD's bge(4) does not
properly detect or handle post-5750 bge devices. Instead, FreeBSD's
bge(4) keeps a sofc copy of the ASIC revision, and for post-5750
devices (5752, 5714, ...) overwrites that softc copy of the
ASIC-revision with the 5750 ASIC revision. Thus, the test (mutatis
mutandis, using FreeBDS's softc asic-revision field), was correct for
FreeBSD; but manifestly incorrect for NetBSD.
Mark Davies (mark at mcs.vuw.ac..nz) has confirmed via private email
that this change fixes PR kern/kern/33509: his bcm5752 now works.
ASIC revision.
Add (accidentally omitted) PCI product-ID entries for the BCM5780 and
BCM5780 (Serverworks HT-2000 to bge_products[], so that bge_probe()
will attach bcm5780 variants. Tested on a bcm5780.
Handling for the bcm5780S with 1000base-X PHY almost certainly has the
wrong quirks; our quirk entries are driven off ASIC ID. However, the
5780 (usually integral copper) and 5780S (TBI?) have the same ASIC ID.
The Linux drivers ascertain whether to use integral copper phy or external
PHY via EEPROM bits.
I suspect the only way we're going to handle the 5780 vs. 5780S
properly is to add exact chip-id matches for all 5780/5780S variants
to bge_revisions[]. However, I don't know those ids until other users
with bcm5780s hardware can get this revision, try it, and report the output.
So, here goes.
should obviously have been CSR_READ(sc, BGE_MARB_MODE) incurred during
my backport of 5714/5715 support from my netbsd-3 development branch,
back into -current.
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''.
The __UNCONST macro is now used only where necessary and the RW macros
are gone. Most of the changes here are consumers of the
sysctl_createv(9) interface that now takes a pair of const pointers
which used not to be.
also restructure and simplify input VLAN ID code handling somewhat, to not use
local have_vlan/vlan_tag variables, and use the appropriate cur_rx condition
on the one place where it's needed
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.
