From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 18:36:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 356FEE46; Tue, 16 Apr 2013 18:36:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 12AB0E7E; Tue, 16 Apr 2013 18:36:30 +0000 (UTC) Received: from [10.9.208.57] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 16 Apr 2013 11:26:10 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS08.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 16 Apr 2013 11:34:13 -0700 From: "David Christensen" To: "Doug Ambrisko" , "d@delphij.net" Subject: RE: bce(4) on the Dell PE 2950 Thread-Topic: bce(4) on the Dell PE 2950 Thread-Index: AQHON8BEpg4paSs9hk6nnkTwmAnTSpjTicQAgATa9gCAAMNj4A== Date: Tue, 16 Apr 2013 18:34:10 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> In-Reply-To: <20130415231748.GA82230@ambrisko.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7D73484835W2917222-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Sean Bruno X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 18:36:31 -0000 > | > 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