bce(4) on the Dell PE 2950

[David Christensen]

> | > 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) 
support of the MCP firmware.  Not only does MCP firmware provide pre-OS 
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 
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 
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