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>