Release Notes ============= Broadcom ASF 2.0 Firmware for BCM5751/5752/5753 and BCM5754/5755/5756/5787 Copyright (c) 2007 Broadcom Corporation All rights reserved. Note: a25751cx.xx firmware package is to be used for BCM5751/5752/5753 devices a25755cx.xx firmware package is to be used for BCM5754/5755/5787 devices a25756cx.xx firmware package is to be used for BCM5756M devices ------------------------------ Version 7.17 -- April 26, 2007 ------------------------------ Fixes: ====== 1. Problem: When configured to poll an SMBus sensor (in the ASF System Description table) and that sensor doesn't acknowledge the SMBus Byte Read request, subsequent SMBus operations would fail. Change: Corrected checking of SMBus hardware failure indicators. Enhancements: ============= 1. Change (CQ 28832): RMCP System State Response: When the BIOS does not inform the ASF Firmware of the current system state (using the ASF SMBus message "Set System State"), we return a "best guess" system state to the management console based on the information available to the ASF firmware (i.e. driver present, VMAIN power present). This feature was added in ASF Firmware v7.11. It was requested that the VAUX system state be reported consistently, regardless of whether WoL was enabled or not. So the new "best guess" system state table is as follows: Condition State Description --------- ----- ----------- Main power, driver preset 0x00 S0 / G0 "working" Main power, driver not present 0x0B Legacy ON Aux power 0x0C Legacy OFF Impact: If the BIOS uses the "Set System State" SMBus message to inform the ASF Firmware of the current system state, then this change has no impact. Otherwise, remote management consoles can expect the "Legacy OFF" state instead of G1 or S5 / G2 states when the system is in an off or low-power state. --------------------------------- Version 7.16 -- December 20, 2006 --------------------------------- Enhancements: ============= 1. Change: Work-around for platforms where the BIOS cannot use the SMBus to receive an "ASD Ready" message: During ASF firmware initialization, an ASD-Ready signature is written to a fixed device memory location (0xd58). This signature will be initialized to the string "ASDREADY" (8 ASCII characters) when the advanced firmware (e.g. ASF) has initialized the SMBus block and is ready to receive SMBus messages. This tells the BIOS that it can now send us (the Alert Sending Device) SMBus messages successfully. The BIOS should clear this field (e.g. to all 0's) after reading it since our advanced firmware never resets this field and it is not cleared/re-initialized upon a device reset. 2. Change (Re-visit CQ#24820, CQ#27697, CQ#27659 workaround): ASF Firmware version 7.15 Item #1 attempts to address CQ#24820, CQ#27697, CQ#27659. The workaround takes about 27ms to shutdown the 5755m device. Any access to the LOM within this window can prevent proper shutdown. This version optimized the shutdown logic and reduces the shutdown time down to less than 3ms. --------------------------------- Version 7.15 -- December 06, 2006 --------------------------------- Enhancements: ============= 1. Change (CQ 27699): In Stanford A2 chip, we have power down workaround using GPIO2 for some platform. In the power down sequence, after putting the device to D3Hot, the original code was waiting for 2 millisecond before proceed to next power down sequence. The enhancement is to put a condition check for PCI-E link to be in L1 or L1 ASPM state then exit loop to shorten the delay. Note: This change only in Stanford A2 chip revision. There is no operational impact from user point of view. --------------------------------- Version 7.14 -- November 28, 2006 --------------------------------- Enhancements: ============= 1. Change (CQ 26780): The ASF Firmware can now (optionally) assert a GPIO signal before issuing remote control commands on the SMBus to an ASF remote control device. Note: This feature requires b57diag version 10.05 or later in order to enable and configure this behavior under the "asfcfg -> ASF Settings" menu. --------------------------------- Version 7.13 -- September 6, 2006 --------------------------------- Fixes: ====== 1. Problem (CQ 26641): ASF Firmware package for BCM5756 could be programmed into incompatible devices (e.g. BCM5755) using b57diag. Cause: The device "family ID" specified in the 5756 package was the "Stanford" family of devices (i.e. BCM5754/5755/5787), even though they are not compatible with the BCM5756 firmware. Change: The BCM5756 firmware package now contains a new device family ID, specifically for the BCM5756[ME] device. Impact: b57diag version 10.0 or later must be used to program the BCM5756 ASF firmware. ------------------------------- Version 7.12 -- August 24, 2006 ------------------------------- Fixes: ====== 1. Problem (CQ 26456): Incorrect RMCP System State Response after resume from S1/S3/S4. Cause: One of the changes in v7.11 was to no longer reset the saved BIOS system state to 0x0e ("unknown") upon a non-driver initiated reset. This change left the previous known BIOS state (e.g. S3) intact, which was sometimes not subsequently over-written by the BIOS. Change: Revert to resetting the saved BIOS system state upon non-driver initiated reset of the controller. Enhancements: ============= 1. Change (CQ 26473 and CQ 26474): Not to bring down PCI-E link when generate GRC reset The original design when generate reset, such as switching operating mode from OS-Present to Non_OS mode, the PCI-E block was also get reset. There are some platforms cannot tolerate the PCI-E link down and will causes the system error. The change is not to reset the PCI-E block so PCI-E link will not be brought down during the reset. ------------------------------- Version 7.11 -- August 16, 2006 ------------------------------- Fixes: ====== 1. Problem (CQ 26380): PET messages (e.g. "System Heartbeats", "Alerts", "Events") generated (and transmitted) by the ASF network controller contained a garbage SNMP "Enterprise" value. Some ASF PET capture and display utilities (e.g. the Broadcom ASFCAP utility) may ignore the received SNMP trap messages due to the unrecognized Enterprise value. Cause: A firmware build tool had a bug (introduced in v7.08) which created the firmware binary files without the required data segment (where the PET SNMP Enterprise value was initialized from). As a result, the Enterprise value was copied from uninitialized or stale NVRAM. Change: Fixed the firmware build tool to include the required data segment in the generated binary files. 2. Problem (CQ 26284), BCM5754, 5755, and 5787 only: After installing ASF v7.10, the speed indicator LED will randomly flash on and off at random LED speeds and the network controller will not transmit PET messages or respond to RMCP messages. Cause: The fix for CQ 26245 in v7.10 was accidentally applied to BCM5754, 5755, and 5787 firmware as well, but these devices require the "Init" portion of the ASF firmware to be located at a different location from BCM5756 resulting in the firmware crashing upon execution. Change: Moved the "Init" portion of ASF firmware to the correct memory location. Enhancements: ============= 1. Change: RMCP "System State Response" messages will now include a "best guess" system state value if (and only if) the BIOS has not informed the network controller of the current system state via the SMBus. The "best guess" system state values reported (see section 184.108.40.206 of the ASF specification for details): Condition State Description --------- ----- ----------- Main power, driver preset 0x00 S0 / G0 "working" Main power, driver not present 0x0B Legacy ON Aux power, WoL mode 0x09 G1 sleeping Aux power, not WoL mode 0x05 S5 / G2 "soft-off" Impact: An "Unknown" (0x0E) system state will no longer be returned in the RMCP System State Response messages. The intention is to provide, in all systems, at least some indication of the current operating state of the system. At the very least, this will provide a feedback mechanism to allow ASF remote management consoles to determine whether an RMCP power-on/off/reset command was successful or not. ------------------------------ Version 7.10 -- August 8, 2006 ------------------------------ Fixes: ====== 1. Problem (CQ 26245), BCM5756 only: After receiving some host traffic, the ASF firmware would stop responding to RMCP requests and stop transmitting PET alerts. Cause: The "Init" portion of ASF firmware was located in controller's receive buffer pool. So after receiving a certain amount of data, the firmware code would eventually be overwritten. The ASF firmware would then die (halt on an "invalid instruction" exception). Change: Moved the "Init" portion of ASF firmware to the correct memory location so as not to conflict with the receiver buffer pool. ------------------------------ Version 7.09 -- August 7, 2006 ------------------------------ Fixes: ====== 1. Problem: 5787 and 5755 NVRAM access is not compatible. The original code only supported 5755. Cause: 5787 and 5755 NVRAM access is not compatible. Change: Added the code to support 5787. 2. Problem: CQ24820 does not apply to 5787. But if the current code is run in 5787, the workaround will apply. Cause: We don't need the workaround for 5787. Change: Put device id check and apply the workaround for 5755 only. Enhancements: ============= 1. Change: Added support for BCM5756 (Stanford ME). 2. Change: Mask off capabilities flags in secure Capabilities Response messages based on rights of authenticated user's role (bypass sessions have no rights). This enhancements insures that the reported capabilities actually match the capabilities of the current session. RMCP messages sent/received over the ASF 1.0 "compatibility port" are not affected. Impact: An ASF management console must query the client's capabilities using an authenticated secure session to get the actual remote control capabilities of the system and the authenticated user. 3. Change: When receiving an RAKP "Message 3" with a status value other than 0 (success) or an invalid "integrity check value", immediately close the session. This only applies to sessions in the "creation" phase (per section 220.127.116.11 in the ASF spec). Impact: Secure sessions will no longer be left "half-open" (until time-out) when an invalid authentication key is used to attempt to open a secure session. If 2 secure sessions were left "half-open", a secure session creation attempt would result in a client response of an RSP status of 1 ("insufficient resources") until one or both sessions timed-out due to inactivity. ----------------------------- Version 7.08 -- June 15, 2006 ----------------------------- This release requires 5755 bootcode 3.18 or newer to run. Fixes: ====== 1. Problem: (CQ 24820) Implemented workaround for Low_Power_Mode Input Pin 5755 TPM Block Gets Reset upon Deassertion of Low_Power_Mode Input Pin. Cause: Hardware behavior. Change: Using GPIO2 as Low_Power_Mode Input Pin and use firmware to shutdown the device when deasserted and power-up the device when it it asserted. Impact: Only 5755 mobile device, chip revision A2, and LOM configuration will take effect. All others are unaffected by this change. If a NIC card is configured as LOM and the GPIO2 is floating, the device will be shut down immediately. In that case, GPIO2 should be shorted to ground to bring up the device. This version requires bootcode version 3.18 or newer. 2. Problem: (CQ 25395) Under stress traffic environment, running after a long time, the host will no longer be able to receive data. Cause: The Ethernet packet receive handler takes care single packet at each event. Under stress environment, multiple packet may stay in single event. Upon exit of the handler routine, the unprocessed packet will be left in queue and the device does not generate a new event until next arrival of new packet. When next event occurs, again, only single packet is processed there still will be unprocessed packet left in the queue. After repeating this over and over, eventually, it will fill up the receive buffer and device will be no longer accepting the incoming packet. Fix: When there is pending packet left in receive buffer, do not clear the event so the pending packet will be processed in next service. --------------------------- Version 7.07 -- May 2, 2006 --------------------------- Fixes: ====== 1. Problem: (CQ 24489) When remotely powering-up or resetting a managed client (via RMCP) with the "Force Progress Events" boot option enabled, PETs for some of the "System Firmware Progress Events" received over the SMBus from the BIOS would not be transmitted by the ASF Firmware. This could be observed by the PET sequence numbers that were received on the management console or by comparing the SMBus trace with the received PET capture log. Cause: When powering-up or resetting the system, the ASF network controller temporarily loses Ethernet link. While Ethernet link is down, the ASF Firmware relies on the PET retransmission queue to retransmit any PETs (2 times) at the configured interval ("PET Retransmission Interval", defaults to 10 seconds). The PET retransmission queue could hold only 6 PETs, so if more than 6 events were received over the SMBus within the allotted time (twice the PET retransmission interval), then those additional events (beyond the initial 6) would not be retransmitted. If the initial PET could not be sent (due to loss of Ethernet link), then the "System Firmware Progress Event" would be lost. Change: Increased the PET retransmission queue from 6 to 30 PETs. 2. Problem: (CQ 24490) Event data from one PET could be carried over into subsequent PETs. Cause: The PET message buffer is reused for all PETs. The "Event Data" field was not zeroed-out, so it was possible for stale event data to be copied from one PET to the next. Change: The entire PET message buffer is now reinitialized (zeroed-out) for each transmitted PET. 3. Problem: (CQ 24520) When PXE-booting to a RIS client (with ASF enabled), after 5 seconds at the RIS login screen (waiting for user input) the RIS login (authentication) will fail. Cause: The ASF firmware's "OS Alive Check" feature monitors the network controller's receive buffer and if there are any packets pending on the receive buffer for at least 5 seconds, the firmware will consider the OS/driver hung and issue a device reset. While displaying the RIS client login screen, the UNDI driver is paused, not consuming packets on the receive buffer. After 5 seconds of pending received data, the firmware considers the driver/OS hung and issue a device reset, causing the driver to fail to transmit any packets thereafter. Without being able to transmit any packets, the RIS client cannot authenticate with the RIS server, causing the observed login failure. Change: Disable the ASF Firmware "OS Alive Check" feature by default. If a driver is loaded that wishes to have this feature enabled, it must explicitly enable it. Impact: If this firmware is used with older drivers, the "OS Alive Check" feature will be disabled. ------------------------------ Version 7.06 -- March 24, 2006 ------------------------------ Fixes: ====== 1. Problem: (CQ 23984) The "Watchdog State" field of the RMCP "System State Response" message sent by the ASF Firmware always contains 0, regardless of the current watchdog timer state. The ASF Specification, section 18.104.22.168 states that bit 0 of the "Watchdog State" field should indicate whether or not the watchdog timer has expired (1 = expired, 0 = not expired or has been restarted or stopped). Cause: Over-sight in the implementation: watchdog state value was hard-coded to 0x00. Change: Track the current watchdog timer expiration/restart/stopped state and set bit 0 of the "Watchdog State" field of RMCP "System State Response" messages accordingly. ------------------------------ Version 7.05 -- March 13, 2006 ------------------------------ Fixes: ====== 1. Problem: (CQ 23774) When using ASF Boot Options to remotely power-on/reset specific systems (via RMCP remote control commands), the system would freeze during the subsequent boot-up. Cause: The work-around for CQ 23469 caused the SMBus push message receive routine to prematurely timeout under certain conditions. Change: Fix the work-around for CQ 23469 to use an accurate clock reference to detect a timeout condition instead of looping an indeterministic (1 microsecond) delay routine. ----------------------------- Version 7.04 -- March 6, 2006 ----------------------------- Fixes: ====== 1. Problem: (CQ 23469) The fix for this defect, in v7.03, was deemed insufficient since the ASF Firmware could still become non-responsive to expansion ROM requests (e.g. PXE) for up to 25ms. The PCI Express specification requires a response time of 10ms or less. Cause: The firmware routine for receiving SMBus push messages would timeout on an incomplete message only after 25 milliseconds. Change: The firmware routine for receiving SMBus push messages now services expansion ROM requests while waiting for the completion of a received SMBus push message. Impact: The expansion ROM requests should now be serviced within 10ms, even if the ASF firmware receives an incomplete SMBus push message. ----------------------------- Version 7.03 -- March 2, 2006 ----------------------------- Fixes: ====== 1. Problem: (CQ 23469) With both ASF and PXE enabled, specific systems could hang during POST. Cause: Certain SMBus conditions could cause the ASF Firmware to become non-responsive to expansion ROM requests (e.g. PXE) for an extended indeterministic period of time (e.g. 11+ seconds) while attempting to receive an SMBus push message. Change: Changed the SMBus push message receive logic to timeout after 25 milliseconds rather than the indeterministic time-out interval used previously. Impact: The PXE load should no longer fail due to expansion ROM requests being ignored for extended periods of time by the ASF Firmware. --------------------------------- Version 7.02 -- February 23, 2006 --------------------------------- Fixes: ====== 1. Problem: (CQ 23408) Receiving RMCP requests for ASF Mailbox State or ASF Mailbox Data would cause the network controller to constantly transmit garbled RMCP messages and become unresponsive to subsequent RMCP requests. Cause: The BCM5754/5755/5787 build of ASF Firmware was missing the initialization of the NVRAM read routine function pointer, so it was attempting to call a function at offset 0 of the firmware which produced anomalous results. Change: Initialize the NVRAM read routine function pointer during firmware startup. Impact: Mailbox state and data requests now work on BCM5754/5755/5787 devices. 2. Problem: (CQ 23422) After losing and re-establishing Ethernet link status, PETs would not resume transmission until the ASF network controller received RMCP traffic from the management console. Cause: Introduced as enhancement #4 in v7.00, the ARP request timer would not be restarted if the system was in "OS present" mode. So the MAC address of the management console would not be known until the client received RMCP traffic from the console. Change: Restart the ARP request timer after link re-establishment regardless of OS state (present/absent). Impact: PETs will now automatically resume transmission after Ethernet link re-establishment, as was the case in ASF Firmware v6.32 and earlier. --------------------------------- Version 7.01 -- February 22, 2006 --------------------------------- Fixes: ====== 1. Problem: (CQ 23175) System cannot boot (or reboot) after enabling ASF operation. Cause: ASF Firmware was driving the SMBus (while sending the ASD_READY message) in the middle of a system-generated SMBus "read byte" command during POST (BIOS reading information from the DIMMs). If the controller's SMBus block is initialized while the SMBus is active, the ASF firmware will not know the correct status of the bus and commence the sending of the ASD_READY message as an SMBus Master. As a result, the ASD_READY message became the "return data" from the DIMM, and causes the BIOS to receive erroneous data, and subsequently causes BIOS bootstrap process to be halted or the system memory size to be reported incorrectly. Change: Added logic in the ASF firmware to ensure the bus is indeed idle after initializing the SMBus block and before sending any SMBus traffic. The implementation is achieved by monitoring the SM_CLK and SM_DAT lines to ensure both signals are high for a time period of greater than 50 microseconds. 2. Problem: (CQ 23010, 23070) When driver is loaded, the link cannot be established correctly. Cause: Driver and the firmware was both accessing the hardware for link initialization. Change: Changed firmware to not to touch the hardware when driver is loaded 3. Problem: (CQ 23399) When unplugging and re-plugging in the Ethernet cable, ARP request message was not being sent out. Cause: The ARP timer was stopped after the first time the MAC address was resolved. After unplug and re-plug the cable, the ARP timer was not restarted. Change: Restarted the timer when link is up. 4. Problem: (CQ 23061) When reading (e.g. with the asfcmd utility "mread" command), an ASF offline mailbox length, not evenly divisible by 4 (32-bit), the ASF firmware would fail to read subsequent mail box blocks correctly. Cause: When reading an ASF offline mailbox length, not evenly divisible by 4, the NVRAM registers were left in an invalid state. The situation was recoverable after subsequent NVRAM accesses. Change: Always read the NVRAM in blocks evenly divisible by 4 bytes. Enhancements: ============= 1. Change: ASF Firmware verifies ASF Mailbox NVRAM header "version" field contains expected value (currently, 0). If an unsupported version value is found, no ASF Mailboxes will be supported. -------------------------------- Version 7.00 -- January 25, 2006 -------------------------------- Enhancements: ============= 1. Change: Added support for pre-standard ASF "Offline Mailbox" RMCP commands: "Mailbox Support Request", "Mailbox State Request", and "Mailbox Data Request". Note: ASF Mailboxes are created with b57diag v9's "asfmbox" engineering mode command. Note: BMAPI applications will be able to "claim" and read-from/write-to ASF mailboxes to be subsequently polled with remote management applications (e.g. "asfcmd" from the ASF SDK v1.2.0). Note: Broadcom will be submitting a "change request" to the DMTF Pre-OS working group to have these commands added to the ASF specification. 2. Change: ASF Firmware Package filename for BCM5751/5752/5753 is now a25751c7.xx. BCM5721 is a server class part that won't typically run ASF, so the previous filename was misleading. "5751" represents the class of controllers including BCM5750, 5751, 5752, 5753, and 5721. 3. Change: The sending of the OEM-specific 'ASD Ready' SMBus message after the firmware has initialized, is now configurable via b57diag->asfcfg->settings (default: disabled). Impact: b57diag version 8.34 or later must be used to enable this option. 4. Change: The getting management control MAC Address ARP timer was never stopped. Since in the timer routine, we already checking if we already got the MAC address; therefore, there was no bug and this change does not fix any thing. However, by stopping the timer can make code more efficient. 5. Change: The slow event timer originally was using software counter to generate slow ever tick. Since the core clock can be different in full power and VAux only power state, the frequency value is not constant. Changed the timer to use hardware tick, thus, every once second, the routine is called accurately, regardless the core clock. 6. Change: (CQ#22365) When system generated NMI in Windows environment, the system will simply blue screen. At this time, the driver will be no longer functional. When received buffer is fill up with host packets, after running out of buffer space, IPMI traffic will be no longer work also. In order to recover from this situation, firmware will have to monitor the health of driver by looking at the receive buffer. When the hang is detected, the firmware will generate a reset to run in non-OS mode. --------------------------------- Version 6.32 -- December 12, 2005 --------------------------------- Fixes: ====== 1. Problem: (CQ 22364) ASF Firmware packages for the BCM5754/5755/5787 family of devices (e.g. a257555c6.31) could be programmed into BCM5750-53/5721 devices, resulting in a non-functioning ASF-enabled network controller. Cause: Firmware packages for the BCM5754/5755/5787 family of devices had an incorrect "device family" value, indicating the firmware was intended for a BCM5750-53/5721 family device. Change: Changed the firmware package "device family" value to '05', indicating support only for the BCM5754/5755/5787 family of devices. Impact: b57diag version 8.33 or later must be used to program this firmware package into BCM5754/5755/5787 family devices. Previously released ASF firmware packages (a25755cX.XX) may still be erroneously programmed into BCM5750-53/5721 devices. --------------------------------- Version 6.31 -- November 29, 2005 --------------------------------- Fixes: ====== 1. Problem: (CQ 14669) System with ASF-enabled network controller does not wake up from S1,S3,S4 when connected at 10Mb. Actually, no traffic of any kind, including RMCP or PET, could be passed by the network controller until the Ethernet link was re-established. Cause: The ASF firmware would re-program the MAC control mode register to GMII mode when it was re-initialized by the driver during driver unload (transition to "WoL mode"). When the MAC control mode register and PHY registers do not agree on the link type, traffic cannot be passed. Change: ASF firmware no longer modifies the "port mode" bits in the MAC control mode register when re-initializing due to a driver "WoL reset". --------------------------------- Version 6.30 -- November 18, 2005 --------------------------------- Fixes: ====== 1. Problem: (CQ 14638 and CQ 13946) ASF-enabled network controller would maintain 1Gb link when in VAUX power state and driver WoL mode set to "None". Cause: The original logic was to take over the PHY initialization when there is no link. However, when driver switch from Gb to WoL speed, the PHY is re-negotiated and takes time to have a stable link. By the time firmware reaches initialization code, the link was still not established, hence the PHY got re-initialized again. Change: Instead of checking for link status, it checks system state. We don't initialize PHY for OS_present state or WoL_state. 2. Problem: (CQ 14207) ASF firmware could incorrectly identify an IP-fragmented UDP packet as an RMCP packet. Cause: When packets are split to fragments, the IP header is copied to each fragmented packet. When data has the "RMCP" signature at correct offset, the packet was mistakenly handled by ASF firmware as an RMCP packet. Change: ASF firmware now will reject any IP-fragmented frames. Enhancements: ============= 1. Support for broadcast RMCP packets. The ASF firmware now correctly identifies and responds to broadcast RMCP packets (e.g. RMCP Ping sent to 192.168.255.255). ---------------------------------- Version 6.29 -- September 30, 2005 ---------------------------------- Fixes: ====== 1. Problem: When ASF & PXE are both enabled on a BCM5755, on some systems, the system may hang during system bootstrap (POST). Cause: The system hangs while loading PXE code via Expansion ROM interface, where if the ASF firmware hangs, the Expansion ROM access from the BIOS will be stalled and the system hangs. The reason for the ASF firmware hang is due to an NVRAM access workaround that was applied in the ASF firmware, specifically for the 5755/A0 chip. Depending on the timing, the required "workaround" may not get executed due to the internal CPU interrupt that occurs during the NVRAM access routines. Change: Changed the firmware interrupt service routine to perform a dummy read of an NVRAM register (that's known to return zero) to clean up the internal bus. Impact: BCM5755 devices should now support both ASF and PXE enabled. 2. Problem: b57diag "C2 test failure" on ASF-enabled BCM5755 devices. Cause: In the "C2 test", b57diag is expecting a special "Driver/firmware handshake flag" from the firmware, but due to a "5755/A0 NVRAM access workaround" the ASF firmware is now required to handle this "handshake flag" (instead of bootcode). In the ASF firmware (v6.28), there is a corner case where the "handshake flag" didn't get handled properly. The corner case is when the NIC is reset by an "non-ASF-aware host software" such as b57diag, the ASF firmware will execute down to a "suspend" code path where also require handling of this "handshake flag", otherwise, the b57diag will not "see" the flag which it is expecting, hence the "C2 test failure". Change: Added the "handshake flag" in the ASF firmware where when the chip reset is caused from a non-ASF-aware software. Impact: The b57diag "C2 test" now passes on BCM5755 devices. 3. Problem: Garbage data included in "Event Data" field of PET messages. Cause: The entire "Event Data" field was not being initialized to zero. The first event data byte determines the contents of the following bytes, and we were just initializing the first byte to 0x00, indicating that no valid data followed, when there was no event data to be included. This caused a portion of the uninitialized memory of the PET message to be sent over the wire. Change: Zero-out the entire PET "Event Data" when appropriate. Impact: Management consoles should now no longer receive garbage in the "Event Data" field of PET messages transmitted by our network controller. Enhancements: ============= 1. Support broadcast PET messages. If the management console IP address is configured with an IP address ending in .255, a broadcast MAC address (all 1's) will be used as the destination address for the PET/UDP/IP packet. ---------------------------------- Version 6.28 -- September 26, 2005 ---------------------------------- NOTE: First release to support BCM5754/5755/5787 family (via a25755c6.28). Contains 5755/A0 workaround for 0x7000-0x703c problem. Requires Boot Code firmware v3.03 or later. Fixes: ====== 1. Problem: When setting the configuration to 1000 speed, the link could not be established. Cause: For Gb speed, the PHY must negotiate with partner for master or slave. Since the force mode cannot kick off the negotiation, there was no guarantee that link could be established. Change: For 1000 speed configuration, use auto-negotiation with 1000 only capability. 2. Problem: PET sequence numbers would be reset (to 0) upon adapter reset. Cause: The PET sequence number was stored in the ASF firmware heap, which is reinitialized upon adapter reset. Change: Store the PET sequence number in the "ASF saved state" portion of static RAM, which is retained between adapter resets. Enhancements: ============= 1. RMCP Response message headers use a sequence number of 255, indicating the client does not want to request acknowledgement from the management console. This change eliminates unnecessary RMCP ACK traffic and delays. --------------------------- Version 6.27 -- May 3, 2005 --------------------------- Fixes: ====== 1. Problem: (CQ 12647) If the "Scan for ASF devices" option flag was enabled in b75diag-> asfcfg->ASF Settings, any SMBus messages sent from the system to the ASF-enabled network adapter will be partially ignored. This will cause SMBus "push" messages to not be sent out as PET events and may even cause the system to hang while booting. Cause: The "Scan for ASF devices" feature is not actually supported in the ASF firmware, but partial support was left in the firmware from an older experimental version which caused the firmware to partially ignore SMBus messages when enabled. Some systems would hang during boot when the SMBus data line was not driven by the firmware in a response to an SMBus read message. Simply disabling this option avoids this problem completely. Current versions of b57diag have been updated to remove this option. Change: The experimental "Scan for ASF devices" feature was completely removed from the firmware. ------------------------------ Version 6.26 -- March 24, 2005 ------------------------------ Fixes: ====== 1. Problem: (CQ 12483) Broadcom ASF NIC transmits System Heartbeat PET messages with the Event Severity field set to 0 ("unspecified"). Other Alert Sending Devices (ASDs) send System Heartbeat PET messages with the Event Severity field set to 1 ("Monitor"). An OEM requested that we use the "Monitor" Event Severity for System Heartbeat PET messages. Cause: The Event Severity value for System Heartbeat messages is not defined anywhere in the ASF specification, so we chose the "unspecified" value (0). Change: When the System Heartbeat PET message is created, a value of 1 ("Monitor") is used for the Event Severity field. Impact: Any applications that monitor PET messages will need to recognize System Heartbeat messages with the "Monitor" event severity value. 2. Problem: (CQ 12521) On some systems, with "PET Retransmit Interval" set to non-zero (typically 20 seconds) and ASF_INFO->MinWatchdogResetValue set to 0 (an atypical value), any PET messages transmitted by the ASF firmware would not have any subsequent retransmissions as required by the ASF specification, section 22.214.171.124. Cause: Root cause not identified. The fix for CQ 12530 also eliminated this problem. When starting the PET retransmission software timer during the firmware initialization, it appears the software timer entry could under some circumstances become corrupted or removed. Change: The PET retransmission software timer entry is not created until a PET message (that is subject to retransmission) is actually sent. 3. Problem: (CQ 12530 ASF PET retransmission occurs at indeterministic interval: first PET retransmission occurs at random interval, second retransmission occurs at configured PET Retransmit Interval. Cause: The PET retransmission timer is a free-running software timer, ticking at the configured PET Retransmit Interval. A PET message can be sent at any time. If the transmitted PET messages is subject to retransmission, the PET message would be added to the retransmission queue somewhere in the middle of a retransmit interval causing the first retransmission to occur at the next software timer tick (whenever that may be). Change: If the PET retransmission queue is empty (as is usually the case), the PET retransmit software timer is reset when the PET message is added to the retransmission queue. If multiple PET retransmissions are enqueued simultaneously, the software timer cannot be reset (or it would be possible to fill-up the retransmit queue before any messages were actually retransmitted). Also, the software timer mechanism was fixed to insure the first event (in this case, a PET retransmission) does not occur one second short of the requested interval. 4. Problem: (CQ 12279) NIC card lose power when device gets reset. Thus, clears ASF/IPMI saved data in shared memory. Cause: The system was not designed for NIC. NIC card has circuit designed to generate POR (power on reset) when device get reset without driving GPIO2 low. The device lose everything and starts fresh in POR and lose the previous BMC/SMBus information. Change: When the NVRAM configuration is configured as NIC, drive GPIO2 low to avoid POR. Note: It is not a requirement for ASF/IPMI to run in NIC. This fix is only for SQA testing. --------------------------------- Version 6.25 -- December 17, 2004 --------------------------------- Enhancements: ============= 1. Support for BCM5752 (Baxter). -------------------------------- Version 6.24 -- December 8, 2004 -------------------------------- Fixes: ====== 1. Problem: (CQ 11289) UDP#2 port filtering problem Cause: UDP1 Port Filtering Uses UDP 2 Port Value instead. Change: Where when the f/w is setting up the RcvRule, the correct value should be the UDP1 port number. 2. Problem: (CQ 10569) Connection to BMC fails when running driver load/unload test in Windows. Cause: GRC reset was generated while we are in master mode sending SMBus message. When driver sends NICDRV_PAUSE_FIRMWARE command to firmware, firmware maybe too busy to respond (already in sending smbus message routine, for example) and cause drive to timeout in 100us. Then driver may generate GRC reset while sending SMBus message. When GRC reset was generated while we are master and sending message, there is a window can cause SMBus in deadlock condition: When we are writing the last byte of message and the remote (slave) is acknowledging the write by driving data line low and awaiting for our device (master) to generate a falling edge clock to move on, if our device is reset at this point, we will no longer drive both clock and data line. As result, the data line will stay low. (because slave is acknowledging input data by driving data line low and waiting for the falling edge of clock.) Because of reset, our device is back to idle state. When we want to write data again, since data line is already low, we could not gain the arbitration to become master; therefore we will never be able to send out data again unless if the data line and clock line back to high (idle state). The SMBus become deadlock until someone drives clock low to let the slave to release data line. Change: Change firmware to constantly monitor driver's NICDRV_PAUSE_FIRMWARE event while sending each byte of SMBus message; when it happens, get ready to stop and clean up message by issuing stop condition. Concern: Driver only wait 100us before times out. CPUB may spending time in other loop before getting into send routine; even though we reduced the chance to cause this problem, it is not 100% bullet proof. Furthermore, we need to insure the smbus is at operational state at initialization all the time (possible because of other device's chip bug); therefore, extra security initialization has been put in initialization routine. 1. Checks if Smbus is idle. (Both clock and data lines are high) 2. If it is idle, then no problem, it is operational. 3. If it is not idle, then we monitor the lines. If there is changed, that means there is activity on the bus; it is operational state. 4. If the bus is not idle and no activity for a long period of time (We are using 1.6 second), we consider the bus is stuck. To clean up the bus, we want to generate a stop condition. -------------------------------- Version 6.23 -- October 29, 2004 -------------------------------- Fixes: ====== 1. Problem: (CQ 11181) System does not boot when ASF is enabled on the 5753A1 NIC. Cause: BCM5753 devices use GPIO2 for "main power presence" detection. Change: Changed firmware's "hasMainPower" macro to check the "hw_config" in the shared memory to see if the boot code has configured GPIO2 to be used for main power detection. Impact: Main power detection now works on BCM5753 devices. 2. Problem: WHQL test was failing due to workaround for CQ 9901 Cause: When this workaround was implemented, both driver and firmware needed to be changed. The problem was only seen in Linux system where OS was performing a PCI Config. space read right after placing our device into D3Hot. Since Windows driver was not coped to handle the workaround (It was not needed since Windows OS was not performing PCI config. space read immediately right after placing our device into D3Hot), the workaround was causing problem when driver was loaded immediately right after unload. Change: Removed the workaround. Enhancements: ============= 1. Added SST 1MB/512k non-buffered flash (SST45VF010/SST45VF512) support. Due to buffering issue, no VPD write is supported. The following is the supported NVRAM summary: SO: Bit 25, Flash Size, internal pull-up SI: Bit 24, Protected Mode, internal pull-down SCLK: Bit 1, Buffered Mode, internal pull-down CS: Bit 0, Flash Mode, internal pull-down [SO,SI,SCLK,CS] Device Write Memo --------------- -------------- ----- ---------------------------- 1000 AT24C512 Yes SEEPROM, AT24Cxxx, any size 1011 AT45DB011B Yes Atmel Buffered 1MB Flash 1001 SST SST45VF010 No SST Non-Buffered 1MB Flash 0001 SST SST45VF512 No SST Non-Buffered 512KB Flash 1101 ST M45PE80 Yes ST 8MB Flash --------------------------------- Version 6.22 -- September 1, 2004 --------------------------------- Fixes: ====== 1. Problem: (CQ 10854) ASF management consoles that verify the DWORD-alignment of the "integrity data" field of secure RMCP response packets, would fail to verify the authenticity of some secure RMCP response packets transmitted by the ASF firmware (i.e. Close Session Response). Cause: The integrity-protected portion of transmitted secure RMCP packets contained the wrong number of pad bytes if the length of the protected portion was an odd number of bytes, resulting in an "integrity data" field that was not DWORD-aligned, as is required by the ASF specification. Change: Fixed error in calculating pad length required for DWORD alignment of the RSP "integrity data" field in secure RMCP response packets. Impact: Management consoles that failed to work with previous versions of ASF firmware due to this defect should now work. 2. Fixed WoL problem when IP address not configured (NULL). Problem: (CQ 10838) Standby on does not wake up from ICMP ping if clear the ARP cache on the ping station. IF not clear the ARP Cache, there is no problem to wake up with ping. There is also no problem when using the Ethernet port that does not have ASF/IPMI enabled. Cause: In the code logic, WoL was disabled when the IP address mismatches. When the IP address was uninitialized (NULL), the comparison would fail when compared to the incoming ARP IP address. Hence, it disabled WoL as designed. Change: Compare the IP only when IP address has been initialized (not NULL). Enhancements: ============= 1. Change: Changed the "firmware ID" value stored in the LSB of memory location 0xc0c from 0x05, 0x0a, and 0x0b to 0x15, 0x1a, and 0x1b for the ASF firmware init, CPUA, and CPUB modules, respectively. This allows the driver differentiate between ASF and IPMI pass-through firmware, if necessary. ------------------------------- Version 6.21 -- August 23, 2004 ------------------------------- Fixes: ====== 1. Problem: (CQ 10801) After creating a secure RMCP session and sending any secure RMCP command (even a "close session" command), each subsequent PET message transmitted by the client (e.g. "System Heartbeat") would be followed by 2 corrupted PET messages. Cause: When generating the RSP trailer for the secure RMCP response packets, a call to the HMAC-SHA1 routine would overflow the firmware stack and corrupt the bottom portion of the "sys" variable memory which contains the PET retransmission structures causing erroneous retransmissions of every transmitted PET message there-after. Change: Reduced local (stack) variables used by HMAC-SHA1 routine and increased the amount of memory reserved for the firmware stack (from 0x300 to 0x500 bytes). 2. Problem: (CQ 10825) Disabling the transmission of PET messages does not stop the transmission of "System Heartbeat" messages. Cause: A low-level check of the "PET enable" flag was erroneously coded, evaluating to "always true". Change: Fixed the check of the "PET enable" flag. Impact: A managed client transmitting PET heartbeats before an upgrade to this version of firmware may stop transmitting heartbeats after the upgrade if the client is configured to not transmit PETs (as was originally intended and documented). 3. Problem: (CQ 10826) Secure RMCP ACK packets transmitted by the managed client may contain RSP headers with session IDs and sequence numbers of unexpected values. Cause: The RSP header added to an RMCP ACK packet transmitted by the ASF client is a copy of the RSP header of the received RMCP command packet that is being acknowledged. The RSP header's session ID and sequence number were not changed to reflect the "destination entity" (management console) during a secure session. Change: For RMCP command packets received over a secure session, the RSP headers generated now contain the session ID of the management console and an incremented sequence number from the saved "sequence number" state variable. Impact: This change has no effect on packets transmitted over the insecure ("compatibility") port, or packets transmitted over the secure port using the "Bypass" session ID (0). Management consoles that failed to work with previous versions of ASF firmware due to this defect should now work. ------------------------------- Version 6.20 -- August 16, 2004 ------------------------------- Fixes: ====== 1. Problem: (CQ 10700) RSP sequence numbers (included in the RSP header of secure RMCP packets transmitted from the managed client) are not reset to 0 when the secure session is established. ASF specification section 126.96.36.199: "When a session is created, the Sequence Number is initialized to zero and incremented by one at the start of outbound processing for a given message". Management consoles that check and verify the RSP sequence number of secure RMCP messages (as described in section 188.8.131.52.3 of the ASF specification) will silently discard messages from the managed client. Change: Reset the client's RSP sequence number when a secure session is established (session creation phase is complete). Impact: Management consoles that failed to work with previous versions of ASF firmware due to this defect should now work. 2. Problem: (CQ 10701) RSP headers transmitted by the managed client contain the client's session ID (SIDc) instead of the management console's session ID (SIDm). Hidden in the table in section 184.108.40.206 of the ASF specification: "The session ID of the destination entity". So the session ID in RSP headers generated by the ASF firmware (managed client) should be that of the management console, the destination entity. Management consoles that check and verify the session ID before processing messages will silently discard messages from the managed client unless the client's session ID happens to be the same value as the management console's session ID (not an uncommon occurrence when using the Broadcom ASF Management Console). Change: Save and use the management console's session ID (SIDm) for RSP headers generated by the ASF firmware for secure RMCP messages transmitted after session establishment. Impact: Management consoles that failed to work with previous versions of ASF firmware due to this defect should now work. 3. Problem: Managed client does not verify RSP sequence numbers in received secure RMCP messages (as described in section 220.127.116.11.3 of the ASF specification), thereby allowing accidental or malicious "replay" of previously received secure messages. Change: ASF firmware now tracks and verifies RSP sequence numbers in received secure RMCP messages, silently discarding messages with duplicate or out-of-order sequence numbers. Impact: Managed client will now silently discard the first secure RMCP packet received from Broadcom ASFMgmtCon v1.14 and earlier since these versions erroneously used a sequence number of 0 for the first secure message after session establishment. This problem was fixed in ASFMgmtCon v1.20. 4. Problem: If any of the "compatibility or secure" remote control capability bits (4:7) were set in the ASF_RMCP.RemoteControlCapabiltities (System Capabilities) bit mask, non-secure remote control commands received over the secure ASF port (using the Bypass session ID) were allowed to trigger the corresponding remote control function. Hidden in the table in section 18.104.22.168 of the ASF specification: "Set-type [remote control] messages (e.g., Reset) shall not be accepted under this [Bypass] Session ID". Change: It seems somewhat illogical to reject non-secure remote control commands on the secure port while allowing remote control commands on the "compatibility" (non-secure) port, but in an effort to comply with the specification as written, the firmware now rejects remote control commands on the secure port using the Bypass session ID (0), regardless of the bits set in the "System Capabilities" bit mask. Impact: Most likely, none. It's doubtful that anyone would rely on the old behavior. Typically, remote control commands are only allowed during secure sessions, if at all. 5. Problem: (CQ 10770) When attempting a secure session establishment on Shasta B1, the ASF firmware would lock-up. Cause: The ASF firmware must be able to distinguish between Shasta A and B step devices to use the correct hardware random number generator interface (B-step devices do not have TPM/Broadsafe). If the firmware attempts a Broadsafe operation on a B-step device, the firmware will enter an infinite loop. Change: Check for flag indicating Shasta B1 rev. Enhancements: ============= 1. Change: On Shasta A4 chips, the Broadsafe random number generator is now used in low power mode instead of the software random number generator used to work-around CQ 9685. ----------------------------- Version 6.15 -- July 13, 2004 ----------------------------- Fixes: ====== 1. Problem: (CQ 10447) System exhibits signs of NMI errors in a driver load/unload stress test. Problem: (CQ 10450) System fails to Wake Repeatedly from S3 (Waker/Dozer stress test). Problem: (CQ 10524) System hangs while performing disable/enable stress test with windiag. Cause: Build chain (compiler/assembler/linker) used to build ASF Firmware generated invalid op code in "pause_cpu" firmware function executed during driver shutdown, causing firmware to jump to an invalid memory location. Change: Eliminate "static" function definitions. The compiler appears to have problems with some functions declared as "static". 2. Problem: We may continue to service smbus even if we enter pause_cpu routine. Cause: Interrupt is not disabled and interrupt service routine will continue to service event Fix: Before we enter pause_cpu routine, we disable interrupt. 3. Applied extension of workaround for CQ#9901. Fixing/Affecting: CQ#10452, CQ#10509, CQ#10510 Problem: In Linux system, when unload driver, may cause system to generate NMI, hang, or shutdown. This problem (CQ 10510) is not seen on all systems, but has been observed on a system that uses the Intel Lindenhurst chipset when running the Linux 2.6 kernel. This problem (CQ 10510) has never been observed under Windows on any system. Cause: In Linux system, when driver request OS to put device to D3Hot, there is another PCI config read from 0 followed right after the write to 0x4c with value 3. Since the moment our device is put to D3Hot state, our device enters L1 state; therefore, the read command data is generated but pending due to L1 state and cause bus to choke. In PCI-E spec (section 5.6.1) requires host SW to not access a device for 10ms after it is put into a D3hot state, and that this bootcode change is needed to workaround a scenario where the newer Linux 2.6 kernel does not follow the PCI-E standard. Fix: Put a new algorithm to delay the entering to L1 state. This workaround requires Linux driver v7.41 or newer version to work. When in D0 state: We disabled state machine from entering L1 state. When in D3 state: We wait for at least 10us, then enable state machine to enter L1 state after the read command completes. Notes: This workaround works only when firmware is still running. It is proven to be working in Linux system; however, in Windows driver case, since the firmware is halted while shutting down. This workaournd will not work. ----------------------------- Version 6.13 -- June 22, 2004 ----------------------------- Fixes: ====== 1. Problem: (CQ 10420) ASF Firmware would not transmit ARP requests after the Windows driver was loaded and could not then transmit PET System Heartbeat (or any other) messages until it received a packet from the Management console. Cause: As part of the code size reduction effort, in v6.05, the software timer initialization function was moved from the 2nd initialization phase (in CPUB) to the 1st initialization phase (in CPUA). Apparently the device driver is resetting the ASF Retransmission Timer Register (0x6C1C) to 0 in-between the first and second initialization phases causing no ASF software timer functions (including ARP requests) to be called. Change: Moved the software timer initialization back to the 2nd initialization phase (in CPUB). ---------------------------- Version 6.12 -- June 8, 2004 ---------------------------- Fixes: ====== 1. Problem: ASF Firmware would respond to SMBus GetUDID with an invalid SMBus response (missing the SMBus address field). ASF Firmware would reply to SMBus ARP queries even though we do not support SMBus ARP. Change: Removed the SMBus ARP reply code from the firmware (conditionally compiled-out). ----------------------------- Version 6.11 -- May 26, 2004 ----------------------------- Fixes: ====== 1. Problem: (CQ 10161) Attempting to authenticate a secure session on B-step device would cause firmware to go into an infinite loop and not respond until a reset. Cause: The random number generator interface was changed in B0 due to the removal of the Broadsafe/TPM block. The new interface is not backward compatible. Change: Added support for the new RNG interface on B-step devices. ----------------------------- Version 6.10 -- May 13, 2004 ----------------------------- 1. Apply "double-ACK" workaround for all revision of 5721 chips Problem: BCM 5721, revision A4, B1 or later ASIC will still require this workaround. Cause: In the previous version (pre 6.05), the workaround for a "double-ack" ASIC problem only applies to revision A0, A1, A2 and A3. After consulted with the ASIC team, this workaround will be needed for all revisions. Fix: Change the code so that the "double-ack" workaround applies to all revisions. 2. Added new support for Flash ST M45PE80 part Enhancement: Added new support for Flash ST M45PE80 part for VPD write routine. M45PE80 uses M25P10-A pin straps. [SO,SI,CS,SCLK] = 1110 SO - internal pull-up, no need to pull-down SI - internal pull-down, need to pull-up CS - internal pull-down, need to pull-up SCLK - internal pull-down, no need to pull-up. 3. Enhanced the reliability of PXE load service. Problem: As a result of code review, there is a place in the firmware code logic where on a system with the NIC's PXE enabled, and if the Driver/Firmware hand-shake went out-of-sync for some unknown reasons, the firmware will halt itself in order to avoid h/w access conflicts between the f/w and the Driver. With PXE enabled, When the system starts, the "bootcode" will advertise the existence of the "optional ROM", however, after firmware halts itself, if the system attempt to access the expansion ROM data, it will get garbage and could potentially have bad effect to the system. Although the "driver and firmware handshake" should never go out-of-sync, but on the safe side, the code logic should be modified. Cause: Found potential code logic problem during code-review. Fix: Instead of halting the CPU, the firmware is modified to continue servicing the system inquiry for the expansion ROM data. 4. Workaround for a "driver/firmware handshake bug. Problem: Customer reported after the NDIS driver went into Hibernate state, when pressing the power button to wake up the system, the IPMI PT stop functioning all the way until the Windows driver is loaded. Cause: On Windows Device Driver v7.73 and prior. When Windows goes into hibernate, the Driver erroneously deposit an extra "reset signature". Later, when the system resumes, that extra "reset signature" causes firmware to misinterpret the reset state, and halt-itself, hence the IPMI PT service stops. When the Windows Driver is loaded, the driver issues a chip reset (GRC RESET), the firmware restarts and begin to function normally. This problem was investigated, and the "extra reset" occurs in both Hibernation and Standby mode, but due to the resume from Hibernation take a longer time, so the IPMI PT service interruption is more visible, compared to resume from standby. Note: because of this bug in the Driver it leads to the discovery of problem #4 above. Workaround: The firmware monitors the chip's "Power state", when VMain goes off, the firmware will clear the "reset signature". This workaround ensure the removal of the extra "reset signature" that was erroneously left by the faulty Windows Device Driver. 5. When using "0xdeaddead" to disable the NIC, the LED could be left on Problem: In the last release, a new feature was added to allow system to disable the NIC using a special "0xdeaddead" signature command. When using this special mechanism to shutdown the chip, some times the LED could still be ON. Cause: In the previous release, the chip was shutdown as soon as the firmware sees the special shutdown signature command, without consideration of the LED state. If the shutdown was invoked when the LED was at a ON state, the chip was shut down with the LED left ON, which is not desirable. Fix: Forced LED to be turned off before shutdown the chip. ----------------------------- Version 6.09 (April 26, 2004) ----------------------------- 1. Added disabling device feature Enhancement: Some customer requested a mechanism to (a) disable the NIC via software control and (b) the NIC will consume lowest possible power when disabled. A mechanism is provided to the host by writing a hex value of 0xdeaddead into NIC's shared memory at location 0xb50 prior to NIC reset. The bootcode is implemented to continuesly monitor this special hex value, if detected, the bootcode will disable the NIC device on the PCI bus, which causes the NIC to become invisible to the Host in the subsequent PCI bus scan. Furthermore, before the bootcode disables the device, the firmware will program the device to a lowest possible power consumption level to save system's power supply. To disable the device (from HOST), write a hex value 0xdeaddead to shared memory location 0xb50 (use pci config cycle, memory access). A subsequent "hard reset" to the NIC, such as "PCI Reset" or "Power On Reset" without writing the hex value 0xdeaddead will cause the NIC to resume its normal operation. Impact: This change only affect PCI-E devices (5751, 5751m, and 5721). ----------------------------- Version 6.08 (April 26, 2004) (Internal Release) ----------------------------- Module Checksum ------ -------- INIT 94457E49 CPUA 921DAD9D CPUB D478D090 Fixes: ====== 1. Problem: Disabling the "Wake on ARP or RMCP Traffic" ASF configuration option had no effect. The firmware would always behave as though this option were enabled. Cause: Erroneous syntax in checking of ASF_ENABLE_WOL "enable flag". Change: Fixed syntax for checking ASF_ENABLE_WOL bit in AsfGui.enableFlags. Version 6.07 (April 23, 2004) ----------------------------- Module Checksum ------ -------- INIT 3B37CF30 CPUA C3A92EBE CPUB A7750A69 Fixes: ====== 1. Change: (CQ 9365) Implemented a better work-around for this issue, as discovered during simulation. Version 6.06 (April 21, 2004) ----------------------------- Module Checksum ------ -------- INIT C5E3B036 CPUA 01A84B4B CPUB E096249B Fixes: ====== 1. Problem: (CQ 9685) When attempting to authenticate a secure management session while in low-power (S5) mode, ASF firmware would lock-up (no longer responding to RMCP packets or transmitting PET packets). Cause: 5751 PCI-E LOM systems that tie the LPC Bus Reset (LRESET#) to PCI-E Reset (PERST#), would disable the Broadsafe/TPM block when in low- power mode. The Broadsafe/TPM block is used for random number generation as part of the ASF 2.0 RAKP authentication sequence. Change: Use software-generated random number when in low-power mode (for chip revs < B0). A high-resolution hardware timer is used to seed the random number generator to provide adequate security. 2. Problem: Under a couple of circumstances, an RAKP MSG2 response packet could contain the client's session-ID in the "management console session-ID" field. Change: If the management console session-ID cannot be determined, then the by-pass session-ID (0) is used. 3. Problem: If an management console included a boot options structure longer than 11 bytes in a remote control message (i.e. Reset, Power-Up, or Power-Reset), the additional bytes (beyond 11) would not be passed to the system firmware over the SMBus. Change: Support boot options > 11 bytes in length (per ASF specification section 22.214.171.124). Enhancements: ============= 1. Change: If for some reason the Broadsafe/TPM core clock has been disabled, an RAKP MSG2 response packet will return an "insufficient resources" status, rather than lock-up the firmware trying to access the Broadsafe registers to generate a random number. 2. Change: Code-size reduction by optimization, clean-up (elimination of unnecessary code) and reusing functions in the "init" portion of the firmware. Version 6.05 (Internal Release) ------------------------------- Fixes: 1. Fixed non-ACPI compliance OS shutdown problem Problem: From non-ACPI compliance OS, such as, Linux, a un-gracefully system shutdown can cause ASF firmware to stop working. Cause: In a un-gracefully system shutdown, the OS Driver did not have a chance to properly stop the hardware state machine nor inform the firmware that the OS Driver is unloaded, as a result, after main power goes away, the hardware and firmware still operating under OS present mode, and causes the hardware and firmware to have unexpected behavior, including stopped ASF function. Fix: Add Firmware logic to monitor main power state. When the main power goes off while in OS Preset mode, the firmware will generate a GRC reset to restart the hardware and firmware. 2. Fixed WoL problem Problem: With multiple WoL packet comes in, PME signal will be reasserted and cause system not able to power down. Cause: After system is waking up from WoL, BIOS will clear PME status. However, since ASF firmware will re-initialize WoL upon reset, when new WoL packet arrives, the hardware will re-assert PME single again after BIOS clear the status. Fix: Changed IPMI firmware to initialize WoL configuration only when there is no main power. Impact: This fix will also make WoL to work under DOS shutdown. 3. Skipped the LED mode initialization Problem: Customer's LED mode setting was destroyed. Cause: The code was unconditionally set LED mode to PHY1 mode. NVRAM setting was ignored. Fix: Since bootcode will initialize LED mode correctly. The LED mode initialization should not be done in ASF/IMPI code. 4. Fixed ASF Boot Option problem Problem: (CQ9761) After an adapter reset, an SMBus query of the stored ASF Boot Options would always result in a response of "No boot options", even if RMCP boot options were previously received and stored by the ASF firmware. Change: Eliminated local variable ("BootOptionsValid") stored in volatile memory. Using BootOptions magic number in ASF "Saved State" structure instead, which is retained between adapter resets. Impact: Remote Control commands (e.g. RMCP Reset) with specified boot options should now work on systems with supporting BIOSes. 5. Applied workaround for 100 half duplex problem Problem: System locks if link is connected to 100 half duplex when OS present. Cause: When there is collision, it can cause transmit buffer to buffer up data. Hardware generate different ACK signals from two different state machine block. When there is data in buffer, it cause hardware to increase time gap between those two acknowledges. If host does any register read between those ACKs, it will cause system to lock. Workaround: Poll for buffer empty before transmit data. Impact: This bug should be fixed in ASIC rev A4 or later. Therefore, The workaround only applies to A0-A3 and B0. 6. Changed workaround for version 6.03 item 1. Problem: There is an alternate and simple way to workaround this issue. In addition, with previous workaround, there is a chance that it may cause problem when OS and firmware is out of sync. New workaround: Instead of freeing buffer from firmware, we change the buffer status to invalid buffer and let hardware to free the buffer. Version 6.04 (February 26, 2004) -------------------------------- Fixes: ====== 1. Problem: Receiving an RMCP remote control command (e.g. reset), the firmware would look for control data in the ASF_RCTL table with a function number matching the RMCP msg type (e.g. 0x10-0x13) rather than the control function number defined in section 126.96.36.199 of the ASF specification (e.g. 0x00-0x03), and send an SMBus command with the incorrect function number. Change: Map the RMCP remote control msg type to the appropriate RCTL control function number. Impact: RMCP remote control commands can now work as documented. 2. Problem: When sending RCTL function messages over SMBus, all 8-bits of the configured Device Address were used as the target SMBus address. If an odd address was configured in the ASF_RCTL table (bit 0 represents the inclusion of PEC in the SMBus message or not), this would cause an SMBus message to be sent to an invalid address. Change: Only use bits 7:1 in the ASF_RCTL control data device address field for the target SMBus address as defined in section 188.8.131.52 of the ASF specification. Impact: Odd Device Addresses in the RCTL control data table should now work as documented. 3. Problem: Support for remote control commands (e.g. reset) was only implemented for secure (ASF 2.0) sessions. Change: Support remote control commands in both secure and non-secure ASF 2.0 sessions as well as non-secure ASF 1.0 sessions based on configured RMCP system capabilities bit mask. Impact: Must have the appropriate bits set in the configured RMCP system capabilities bit mask to enable specific remote control commands. 4. Problem: Only the upper 4-bits of the configured RMCP system capabilities bit mask were being used to determine support for remote control commands (e.g. reset). Change: Use the low 4-bits of the configured RMCP system capabilities bit mask to determine if support for a specific secure remote control command is only supported via secure (authenticated) ASF 2.0 sessions. Impact: Must configure RMCP system capabilities bit mask (ASF_RMCP RemoteControlCapabilities byte offset 6) per the table describing the System Capabilities Bit Mask in section 184.108.40.206 of the ASF 2.0 specification. Enhancements: ============= 1. Change: Added configurable secure session time-out parameter. The value stored in this parameter determines the number of seconds of ASF 2.0 authenticated-session inactivity before the session ID may be re-used for a new open session request. This value was previously hard-coded to 5 minutes (300 seconds). Impact: You must use b57diag v7.21 or later to configure this parameter. The size of the ASF configuration table was changed and only b57diag v7.21 or later will handle the size change correctly. If this value is configured to 0 (seconds), a default value of 300 seconds is used. 2. Change: The MIPS instruction cache is now enabled and posted-writes are now enabled if the chip is rev A1 or later. Impact: Slight performance improvement. 3. Change: ASF 1.0 compatibility can now be optionally disabled. Impact: RMCP messages sent to the ASF 1.0 "compatibility port" will be ignored if both this option and secure RMCP support are enabled. This option is ignored if secure RMCP support is disabled. b57diag v7.21 or later is required to make this configuration change (on the "asfcfg" Secure RMCP sub-menu). The default behavior is with ASF 1.0 compatibility enabled. 4. Change: Chip-bug (CQ 9365) work-around disabled if using chip revs after A1. Impact: Work-around has potential performance impact, so we may see slight performance improvement with non-A0/A1 chips. Version 6.03 (February 23, 2004) -------------------------------- Fixes: ====== 1. Problem: (CQ 9365) When stressing ASF firmware with RMCP traffic while simultaneously stressing host device driver with TCP traffic, adapter could stop receiving until reset. Cause: Race condition in chip's RxMbuf free logic. Change: Firmware work-around by polling buffer manager hardware diagnostic register 3 until it contains the descriptor of the RxMbuf chain the ASF firmware is about to free. Impact: Under heavy loads, there may be a throttle on the receive rate of RMCP packets. 2. Problem: (CQ 9322) When stressing ASF firmware with RMCP traffic while having PET Heartbeat transmits enabled, transmitted RMCP ACK or response packets could be corrupted. Cause: Transmits of PET packets during interrupt time could corrupt RMCP ACK or response packets since they share the same transmit packet buffer. Change: Fixed by disabling interrupts during receive packet event. Impact: None. 3. Problem: (CQ 9336) When using an ASF configuration program to modify the security keys in the ASF configuration table, if such program wrote the key lengths in little-endian byte order, a subsequent authentication attempt would cause the ASF firmware to halt or return erroneous status codes (e.g. 0x01 - insufficient resources). Cause: A key size larger than the key buffer (20 bytes) could corrupt the firmware code space. A little-endian key size of a valid length would be interpreted by the firmware (in big-endian byte order) as a very large number and exceed the bounds of the allocated key buffer. Change: Key sizes are now validated during ASF firmware initialization. Key sizes exceeding the maximum are automatically truncated. Impact: A wrong-endian key size will most likely just cause any authentication attempts to silently fail, but the firmware will continue to execute. 4. Problem: Creating 2 secure sessions, one immediately after the other, with no other RMCP traffic in-between, would cause the first session ID to be re-allocated for the second session. Creating a 3rd session with no other RMCP traffic in-between would re-use the same session ID, and so on. Cause: When creating a new secure session, the "last active" time stamp value was initialized to 0 and would not be set to a valid time stamp value until an RMCP command was received from the management console. With a "last active" time stamp of 0, any new session requests would automatically timeout this session ID and re-use it for the new session. Change: When creating a new secure session, the "last active" time stamp value is now initialized to the current time. Impact: None. Enhancements: ============= 1. Change: Removed support for intelligent ASF sensor and SMBus ARP responses as these features are not yet supported. Impact: Reduced code size by approximately 2 kilobytes. Version 6.02 (January 27, 2004) -------------------------------- Fixes: ====== 1. Problem: (CQ 9264) Corrupted receive Mbuf pool memory if ASF Heartbeat PET transmission is enabled. Symptoms include: DMA engine halting causing subsequent receives to fail, corrupted packets, and system lock-ups. Cause: ASF firmware interrupt service routine could corrupt an embedded MIPS CPU register. Change: Added NOP after JAL instruction in ASF ISR. Impact: None. Enhancements: ============= 1. Change: MIPS Data cache was not enabled after OS-present resets. Impact: ASF code should execute faster (same as v6.00). 2. Change: Removed BCM5702FE support. Impact: None. Version 6.01 (January 21, 2004) -------------------------------- Fixes: ====== 1. Problem: (CQ 9062) Secure destructive RMCP commands caused ASF firmware to stop responding to secure RMCP packets. This problem only occurred with RMCP commands that use the "Boot Options" field, which includes all destructive RMCP commands except "Power Down". Cause: ASF firmware code uses a pointer into the non-volatile ASF saved states structure to store secure session information (including the session integrity key used during secure packet authentication). This pointer was pointing to the wrong location in the structure which would conflict with other elements in the structure, namely the boot options, which would be updated whenever any destructive RMCP commands were received, thus overwriting a portion of the session integrity key causing subsequent secure commands to fail authentication. Change: Changed the secure session saved state pointer to the proper offset into the ASF saved states structure. Impact: None. 2. Problem: Boot option updates caused by SMBus or specific RMCP commands (e.g. "Power Up") would corrupt ASF saved state table. Cause: All boot option array offsets used were "off by one", overwriting the first byte of next element in the ASF saved states structure. Change: Fixed "boot options" array offsets. Impact: None. 3. Problem: (CQ 9155) An adapter reset would cause any existing secure RMCP sessions to subsequently fail (secure RMCP packets are unanswered). Cause: ASF firmware was re-initializing the ASF saved states structure to zero upon any OS-absent reset (assuming initial power-up). Change: This has been fixed by checking for a signature in the saved states structure which will not exist if the structure has not been initialized at least once. Impact: Existing saved state structures stored in the static memory will be re-initialized by this new version since it will be missing the required signature. 4. Problem: (CQ 9184) and (CQ 9207) Exclusive to BCM5751 (PCI-E), adapter would lose Ethernet link status when device driver was loaded with ASF firmware already running. Cause: Race conditions in driver/firmware handshaking causing driver initialization to step on ASF initialization. This race condition occurs on BCM5751 because the A0 rev requires a 300ms delay in the driver after GRC and before initialization. During this period ASF may be loaded and begin initialization. Change: ASF firmware now waits (up to 3 seconds) for a "driver initialization done" flag to be set by the driver in shared memory, signaling to the firmware that the driver has completed initialization (or uninitialization) and the firmware may continue without risk of conflict. The MIPS data cache must be disabled to see the immediate change to the shared memory. The MIPS data cache is now enabled later in the ASF initialization. Impact: When used in combination with device drivers that do not implement this new handshaking method, a 3 second delay can be expected during ASF initialization. 5. Problem: (CQ 9038) If ASF is enabled but not configured, the System IP and Management Console IP addresses will be 0.0.0.0. Cause: The ASF code didn't check if the System IP and Management Console addresses are valid before generating ARP requests for the Management Console MAC address. Change: ASF will no longer send ARP requests if the Management Console IP address is not configured (i.e. 0.0.0.0). Impact: None. Enhancements: ============= 1. Request: Use different ASF firmware filenames for BCM575x adapters. Change: ASF firmware for BCM575x now uses the following filenames: ASFE5xI.BIN ASFE5xA.BIN ASFE5xB.BIN Impact: You must use b57diag v7.16 or later to update the ASF firmware for a BCM575x adapter. 2. Change: Active secure session's "last activity" timer value is initialized upon reset, preventing premature session time-out due to reset. Impact: Creating a new session after an adapter reset should no longer overwrite an existing session that has not actually been inactive longer than the maximum inactivity period (5 minutes). 3. Change: ASF no longer attempts to transmit ARP requests or PET HeartBeat packets if there is no Ethernet link. Worked-around race condition during initialization on BCM5751 (CQ 9184), left in place since it's the logical thing to do. Impact: None. Version 6.00 (December 15, 2003) -------------------------------- Initial release. See readme.txt for documentation. Fixes: ====== None. Enhancements: ============= None. /* End of File */Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.