Date: Tue, 16 Apr 2013 18:34:10 +0000 From: "David Christensen" <davidch@broadcom.com> To: "Doug Ambrisko" <ambrisko@ambrisko.com>, "d@delphij.net" <d@delphij.net> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "davidch@freebsd.org" <davidch@freebsd.org>, Sean Bruno <seanwbruno@gmail.com> Subject: RE: bce(4) on the Dell PE 2950 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> In-Reply-To: <20130415231748.GA82230@ambrisko.com> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> | > 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? The 5706/5708/5709/5716 devices have a set of RISC processors. One is loaded from NVRAM based firmware (MCP) while the others are loaded by firmware embedded in the driver. The MCP firmware is loaded at device power-on when the system is plugged into a socket in order to provide pre-OS access to the system (think Dell DRAC). There's a chicken and egg problem with your suggestion for firmware(9)=20 support of the MCP firmware. Not only does MCP firmware provide pre-OS=20 services but it also provides FreeBSD driver services. There are shared resources on the device which require synchronization between multiple FreeBSD driver instances and the MCP acts as an arbitrator for them. Additionally, I have some security concerns about making NVRAM write=20 functionality easily accessible through the driver since it would be fairly easy to take down a system and require a motherboard swap to fix the problem. There's always a concern that a power-event could interrupt an NVRAM upgrade and make the system unusable so I think it's=20 important to have the system administrator's blessings before making any NVRAM changes to firmware. Not sure how to accomplish that without making the driver load process interactive. Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A5015FE9E557D448AF7238AF0ACE20A31A4E5>