Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Apr 2013 16:17:48 -0700
From:      Doug Ambrisko <ambrisko@ambrisko.com>
To:        d@delphij.net
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, davidch@freebsd.org, Sean Bruno <seanwbruno@gmail.com>
Subject:   Re: bce(4) on the Dell PE 2950
Message-ID:  <20130415231748.GA82230@ambrisko.com>
In-Reply-To: <516877F0.9080301@delphij.net>
References:  <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 12, 2013 at 02:09:04PM -0700, Xin Li wrote:
| (Added David to Cc)
| 
| On 04/12/13 13:56, Sean Bruno wrote:
| > A note from clusteradm@freebsd.org
| > 
| > It looks like there is some amount of instability or bugginess in
| > some of the Broadcom firmware(management) on the bce(4) chipeset
| > shipped on later generations of the Poweredge 2950 from Dell:
| > 
| > bce0: <Broadcom NetXtreme II BCM5708 1000Base-T (B2)>
| > 
| > Specifically, we've seen that newer (9 and higher) have issues with
| > the doing initial setup and negotiation and that Dell did indeed
| > release newer firmware to fix the issues.  This requires a full
| > reboot into Linux (probably centos6) to get the update to execute.
| 
| I could be wrong but I *think* that the firmware is loaded on device
| initialization, so there may be a chance that the driver can do it
| when starting?  Additionally, maybe one can leverage the kernel
| firmware(9) framework so that the firmware can be more easily updated
| by user?

What we created at work was a tool to dump the NIC's "firmware" via the
BCE_DEBUG and BCE_NVRAM_WRITE_SUPPORT.  It's totally unsupported but
works well :-)  The usage is to flash it via Linux etc, boot FreeBSD
then dump the NVRAM contents.  Then use a "flashing" tool that
first saves the MAC address info, write the new image and then restore
the MAC address ... otherwise all of your NICs get the same MAC addresses!

If someone wants to make a decent tool out of it let me know.  It's
hacky but works.  This is why we added the BCE_NVRAM_WRITE_SUPPORT.
This means you need these options enabled in the kernel.  It's trivial
code based on public data.  I tossed it up at:
	http://www.ambrisko.com/doug/bce_firmware.c
It needs a correct usage :-)  -r reads the NVRAM and -w writes it.
There is no error checking "flashing" the firmware since it isn't
done via the chip so if you write trash, then you break your NIC.
It's a starting point.  I put a header file up at:
	http://www.ambrisko.com/doug/bce_struct.h

We've had issues with bce(4) devices since day one in which the BIOS,
BMC and NIC firmware had to be in some type of sync. or things
break.  For a while we actually had to use a cobbled together NIC
firmware image from a couple of releases of firmware.

Doug A.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130415231748.GA82230>