release.txt Driver File Contents (

Release Notes

                         Broadcom ASF 2.0 Firmware
                           for BCM5751/5752/5753
                         and BCM5754/5755/5756/5787

                  Copyright (c) 2007 Broadcom Corporation
                            All rights reserved.

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

   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.

      Corrected checking of SMBus hardware failure indicators.

   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

      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

   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
   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. 

      This change only in Stanford A2 chip revision. There is no operational
      impact from user point of view. 

Version 7.14 -- November 28, 2006
   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

      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
   1. Problem (CQ 26641):
      ASF Firmware package for BCM5756 could be programmed into incompatible
      devices (e.g. BCM5755) using b57diag.

      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.

      The BCM5756 firmware package now contains a new device family ID,
      specifically for the BCM5756[ME] device.

      b57diag version 10.0 or later must be used to program the BCM5756 ASF

Version 7.12 -- August 24, 2006
   1. Problem (CQ 26456):
      Incorrect RMCP System State Response after resume from S1/S3/S4.

      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.

      Revert to resetting the saved BIOS system state upon non-driver
      initiated reset of the controller.

   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
   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.

      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.

      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.

      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.

      Moved the "Init" portion of ASF firmware to the correct memory location.

   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 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"

      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
   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.

      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).

      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
   1. Problem:
      5787 and 5755 NVRAM access is not compatible. The original code only
      supported 5755. 
      5787 and 5755 NVRAM access is not compatible.
      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. 
      We don't need the workaround for 5787.
      Put device id check and apply the workaround for 5755 only. 

   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.

      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 in the ASF spec). 
      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. 

   1.  Problem: (CQ 24820)
       Implemented workaround for Low_Power_Mode Input Pin

       5755 TPM Block Gets Reset upon Deassertion of Low_Power_Mode Input
       Hardware behavior.
       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.
       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. 
       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
       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
   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.

      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.

      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.

      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.

      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.
      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.

      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.
      If this firmware is used with older drivers, the "OS Alive Check"
      feature will be disabled.

Version 7.06 -- March 24, 2006
   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 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).

      Over-sight in the implementation: watchdog state value was hard-coded
      to 0x00.

      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
   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.

      The work-around for CQ 23469 caused the SMBus push message receive
      routine to prematurely timeout under certain conditions.

      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
   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.

      The firmware routine for receiving SMBus push messages would timeout
      on an incomplete message only after 25 milliseconds.

      The firmware routine for receiving SMBus push messages now services
      expansion ROM requests while waiting for the completion of a received
      SMBus push message.

      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
   1. Problem: (CQ 23469)
      With both ASF and PXE enabled, specific systems could hang during POST.

      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.

      Changed the SMBus push message receive logic to timeout after 25
      milliseconds rather than the indeterministic time-out interval used

      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
   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.

      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.

      Initialize the NVRAM read routine function pointer during firmware

      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.

      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.

      Restart the ARP request timer after link re-establishment regardless of
      OS state (present/absent).

      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
   1. Problem: (CQ 23175)
      System cannot boot (or reboot) after enabling ASF operation.
      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.
      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
   2. Problem: (CQ 23010, 23070)
      When driver is loaded, the link cannot be established correctly. 

      Driver and the firmware was both accessing the hardware for link 

      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. 
      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 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.

      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.

      Always read the NVRAM in blocks evenly divisible by 4 bytes.
   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

   1. Change:
      Added support for pre-standard ASF "Offline Mailbox" RMCP commands:
      "Mailbox Support Request", "Mailbox State Request", and
      "Mailbox Data Request".

      ASF Mailboxes are created with b57diag v9's "asfmbox" engineering
      mode command.

      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).

      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).

      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

   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.
      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.

      Changed the firmware package "device family" value to '05', indicating
      support only for the BCM5754/5755/5787 family of devices.

      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


   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.

      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

      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


   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".

      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. 

      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.
      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.
      ASF firmware now will reject any IP-fragmented frames.

   1. Support for broadcast RMCP packets. The ASF firmware now correctly
      identifies and responds to broadcast RMCP packets (e.g. RMCP Ping
      sent to

Version 6.29 -- September 30, 2005


   1. Problem:
      When ASF & PXE are both enabled on a BCM5755, on some systems, the
      system may hang during system bootstrap (POST).

      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.

      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.

      BCM5755 devices should now support both ASF and PXE enabled.

   2. Problem:
      b57diag "C2 test failure" on ASF-enabled BCM5755 devices.

      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".

      Added the "handshake flag" in the ASF firmware where when the chip reset
      is caused from a non-ASF-aware software.

      The b57diag "C2 test" now passes on BCM5755 devices.

   3. Problem:
      Garbage data included in "Event Data" field of PET messages.

      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.

      Zero-out the entire PET "Event Data" when appropriate.

      Management consoles should now no longer receive garbage in the "Event
      Data" field of PET messages transmitted by our network controller.

   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

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.

   1. Problem:
      When setting the configuration to 1000 speed, the link could not be
      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. 
      For 1000 speed configuration, use auto-negotiation with 1000 only

   2. Problem:
      PET sequence numbers would be reset (to 0) upon adapter reset.

      The PET sequence number was stored in the ASF firmware heap, which
      is reinitialized upon adapter reset.

      Store the PET sequence number in the "ASF saved state" portion of
      static RAM, which is retained between adapter resets.
   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

   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.

      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.

      The experimental "Scan for ASF devices" feature was completely
      removed from the firmware.

Version 6.26 -- March 24, 2005


   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.

      The Event Severity value for System Heartbeat messages is not defined
      anywhere in the ASF specification, so we chose the "unspecified" value
      When the System Heartbeat PET message is created, a value of 1 
      ("Monitor") is used for the Event Severity field.

      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

      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.

      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.

      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).

      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. 
      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. 
      When the NVRAM configuration is configured as NIC, drive GPIO2 low to
      avoid POR.
      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


   1. Support for BCM5752 (Baxter).

Version 6.24 -- December 8, 2004


   1. Problem: (CQ 11289)
      UDP#2 port filtering problem 
      UDP1 Port Filtering Uses UDP 2 Port Value instead.
      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
      GRC reset was generated while we are in master mode sending SMBus
      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 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. 
      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
   1. Problem: (CQ 11181)
      System does not boot when ASF is enabled on the 5753A1 NIC.
      BCM5753 devices use GPIO2 for "main power presence" detection.

      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.

      Main power detection now works on BCM5753 devices.
   2. Problem:
      WHQL test was failing due to workaround for CQ 9901
      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.
      Removed the workaround.

   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
   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).
      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
      Fixed error in calculating pad length required for DWORD alignment of
      the RSP "integrity data" field in secure RMCP response packets.

      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. 
      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.
      Compare the IP only when IP address has been initialized (not NULL). 
   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

Version 6.21 -- August 23, 2004
   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.

      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.
      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.
      A low-level check of the "PET enable" flag was erroneously coded,
      evaluating to "always true".
      Fixed the check of the "PET enable" flag.
      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.
      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.

      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.

      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
   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
      "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
      Management consoles that check and verify the RSP sequence number of
      secure RMCP messages (as described in section of the ASF
      specification) will silently discard messages from the managed client.
      Reset the client's RSP sequence number when a secure session is
      established (session creation phase is complete).
      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 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).
      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.
      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 of the ASF
      specification), thereby allowing accidental or malicious "replay" of
      previously received secure messages.
      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.
      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[6]
      (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 of the ASF specification:
      "Set-type [remote control] messages (e.g., Reset) shall not be accepted
      under this [Bypass] Session ID".
      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.
      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.
      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.
      Check for flag indicating Shasta B1 rev.
   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

   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.

      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

      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

      Interrupt is not disabled and interrupt service routine will
      continue to service event

      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

      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.

      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. 

      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.

      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

Version 6.13 -- June 22, 2004

   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.

      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

      Moved the software timer initialization back to the 2nd initialization
      phase (in CPUB).

Version 6.12 -- June 8, 2004

   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.

      Removed the SMBus ARP reply code from the firmware (conditionally

Version 6.11 -- May 26, 2004

   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

      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.

      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

    BCM 5721, revision A4, B1 or later ASIC will still require this workaround.
    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.
    Change the code so that the "double-ack" workaround applies to all
2. Added new support for Flash ST M45PE80 part

   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.

    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.
    Found potential code logic problem during code-review.
    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.

    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.
    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.
    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

    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.

    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.

    Forced LED to be turned off before shutdown the chip.

Version 6.09 (April 26, 2004)

1. Added disabling device feature

    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.
    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

   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.

      Erroneous syntax in checking of ASF_ENABLE_WOL "enable flag".

      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

   1. Change: (CQ 9365)
      Implemented a better work-around for this issue, as discovered during

Version 6.06 (April 21, 2004)
Module      Checksum
------      --------
INIT        C5E3B036
CPUA        01A84B4B
CPUB        E096249B

   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).

      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.
      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"

      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.

      Support boot options > 11 bytes in length (per ASF specification

   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

Version 6.05 (Internal Release)
   1. Fixed non-ACPI compliance OS shutdown problem
       From non-ACPI compliance OS, such as, Linux, a un-gracefully 
       system shutdown can cause ASF firmware to stop working.
       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.
       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
       With multiple WoL packet comes in, PME signal will be reasserted 
       and cause system not able to power down. 
       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.
       Changed IPMI firmware to initialize WoL configuration only when there 
       is no main power.         

       This fix will also make WoL to work under DOS shutdown.
   3. Skipped the LED mode initialization

       Customer's LED mode setting was destroyed.
       The code was unconditionally set LED mode to PHY1 mode. NVRAM setting
       was ignored.
       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.
       Eliminated local variable ("BootOptionsValid") stored in
       volatile memory. Using BootOptions magic number in ASF
       "Saved State" structure instead, which is retained between
       adapter resets.
       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
       System locks if link is connected to 100 half duplex when OS present.
       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.
       Poll for buffer empty before transmit data.
       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.
       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)
   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 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
      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

   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
               of the ASF 2.0 specification. 

   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)

   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
      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.

   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)

   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.
   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)

   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
      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 
      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.
      Impact:  None.

   1. Request: Use different ASF firmware filenames for BCM575x adapters.
      Change:  ASF firmware for BCM575x now uses the following filenames:
      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.



/* End of File */
Download Driver Pack

How To Update Drivers Manually

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.

server: web1, load: 0.54