Release Notes
=============
Broadcom ASF 2.0 Firmware
for BCM5751/5752/5753
, BCM5754/5755/5764/5787
, BCM5756,
, BCM57760,
and BCM57761
Copyright (c) 2008-2009 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/5764/5787 devices
a25756cx.xx firmware package is to be used for BCM5756M devices
a57760cx.xx firmware package is to be used for BMC57760 devices
a57761cx.xx firmware package is to be used for BMC57761 and BMC57765 devices
---------------------------------
Version 8.11 -- January 06, 2010
---------------------------------
Fixes:
======
1. Problem:
Boot agent failed to run on 57760 device with ASF enabled.
Cause:
Data corruption due to the 57760 ASF firmware using more than the
available scratchpad memory on device.
Change:
ifdef code not used by ASF firmware to reduce size of firmware.
---------------------------------
Version 8.10 -- January 05, 2010
---------------------------------
Fixes:
======
1. Problem (CQ 45124):
45120 - ASPEN asf enable ping display message "No buffer space available"
45123 - Linux : 57765 asf enable then run stress test will get error.
Cause:
There are some build issues with image V8.09.
It makes use of the MBuf memory for running ASF firmware which cause data corruption.
Change:
Fixed the build process to avoid using the MBuf memory to run ASF firmware.
Make sure that ASF firmware is running within the Scratch Pad Memory.
Enhancements:
=============
1. Change:
Changing the starting address of the Init code from 0x8005500 to 0x8006000 in format.init for Aspen ASF firmware.
It will provide more room for CPUB code.
2. Change:
Adding support for POWERDOWN_MAGIC, POWERDOWN_MAGIC_LEN and POWERDOWN_MAGIC_CR for Aspen
When seeing POWERDOWN_MAGIC in Shared Memory offset 0xB50, ASF firmware will IDDQ the LEN and the Card Reader.
When seeing POWERDOWN_MAGIC_CR in Shared Memory offset 0xB50 , ASF firmware will IDDQ the Card Reader.
When seeing POWERDOWN_MAGIC_LEN in Shared Memory offset 0xB50, ASF firmware will IDDQ the LEN.
3. Change:
When running in Vaux only mode, ASF firmware for Aspen will power down the Card Reader if Wake on Card Insertion,
Wake on Card Removal and Wake on Card Interrupt are not enabled.
4. Change:
Setting USE_BROADSAFE flag to FALSE for Aspen ASF firmware.
5. Change:
Removing Expansion Rom Data access support in Aspen ASF firmware.
---------------------------------
Version 8.09 -- December 30, 2009
---------------------------------
Initial release for BMC57761 and BMC57765 devices.
Fixes:
======
None.
Enhancements:
=============
None.
---------------------------------
Version 8.08 -- December 29, 2009
---------------------------------
Fixes:
======
1. Problem (CQ 44737):
Secure RMCP vulnerability: a malformed "RAKP Message 1" packet received
with a "User Name Length" field value greater than 16 may corrupt stack
memory causing the management controller to crash or potentially allow
an attacker to execute chosen or arbitrary instructions on the
management controller's processor.
Cause:
Insufficient validation of received "RAKP Message 1" packets before
processing.
Change:
If the "User Name Length" field value is greater than the maximum length
allowed by the ASF 2.0 specification, then an "RAKP Message 2" response
packet is sent with a "Status Code" value of 0x0C (Invalid name length),
as defined in section 3.2.3.5.1 of the DMTF ASF 2.0 specification
(DSP0136).
2. Problem:
"Open Session Response" and "RAKP Message 2" packets generated with a
non-zero "Status Code" value (indicating an error has occurred) have an
RMCP data length value of 28 and 52 bytes respectively, instead of 8,
as specified in sections 3.2.4.6 and 3.2.4.14 of the ASF 2.0
specification.
Cause:
The generated and transmitted "Open Session Response" and "RAKP Message
2" packets were always the full message, regardless of the included
"Status Code" value.
Change:
Only transmit the full 6-field, 28 or 52 byte payload when the
"Status Code" value is 0 (success).
---------------------------------
Version 8.07 -- May 18, 2009
---------------------------------
Fixes:
======
1. Problem: (CQ40973).
ASF 57760 Force Progress Events will show "Event logging disable".
Change:
Disabled SMBus auto-read feature for CiLai/Caesar 3. Firmware will explicitly
clear the SMBus In Ready bit in the SMBus input register. This change is a
software workaround for a hardware bug in the device where the firmware would
intermittently read a duplicate byte from the SMBus input register. This would
cause the SMBus push message to be corrupted and the ASF management console
would report the event as "Event logging disable" instead of the expected
"System firmware progress".
---------------------------------
Version 8.06 -- March 20, 2009
---------------------------------
Fixes:
======
1. Problem: (CQ40004).
ASF 57760 System in S3/S4/S5 does not shows correct LED.
Change:
Added additional check to perform GRC reset for power transition from
Vmain to Vaux only when OS is absent.
2. Problem: (CQ40025).
ASF cannot wake up 57760 on linux system when bootcode disable and os enable.
Change:
Added additional check to perform GRC reset for power transition from Vmain
to Vaux only when the last driver state was not unload.
---------------------------------
Version 8.05 -- March 13, 2009
---------------------------------
Fixes:
======
1. Problem: (CQ39949).
ASF 57760 LED is not correct when system is in VAUX with J701 plugged out.
Change:
Removing the J701 jumper will cause the device to always run in Vaux. So
when the system goes from Vmain to Vaux the RxCPU does not get reset. This
causes the link to stay in 1G even though it should transition to Vaux speed.
The ASF firmware does the link speed negotiation during initialization
and not in the main loop. This fix will check for the power
transition in the main loop and will do a GRC reset when this transition occur.
---------------------------------
Version 8.04 -- March 5, 2009
---------------------------------
Enhancements:
======
1. Change (CQ39405).
Add "Lowest Speed Advertised" support in Vaux for out of box.
Change:
Add LSA option in mancfg, also limit copper device Vaux speed to
10 and 100 mbps. When LSA option is specified, use current
link partner's link capabilities to determine lowest speed setting.
When out of box, the mancfg Vaux setting is used. After booted to
OS, driver's Vaux setting is used when system goes to S3, S4, S5 states.
Note:
This feature requires b57diag version 11.81 or later in order to enable
LSA option in Vaux under the "mancfg -> Settings" menu.
---------------------------------
Version 8.03 -- November 14, 2008
---------------------------------
Fixes:
======
1. Problem: (CQ38524).
Device does not power-down when it is set to hidden/unavailable in BIOS setup
Change:
Power-Down bit moved to CPMU control register (0x3600) from GRC Misc Config
register (0x6804) starting with the Taishan/Caesar II device. Added check
for device (5764M and 57760) and use the CPMU control register to
power-down device. For other devices use the GRC Misc Config register.
---------------------------------
Version 8.02 -- October 30, 2008
---------------------------------
Enhancements:
=============
1. Change
ASF Firmware to use the ASF configured link speed only if the OS is absent
and the system is in Vaux. If OS is absent and Vmain is present then configure
the PHY registers to link at 10/100/1000. Otherwise, when OS is present the
driver will configure the PHY registers.
---------------------------------
Version 8.01 -- July 9, 2008
---------------------------------
Fixes:
======
1. Problem: (CQ36254)
Incorrect Event Source Type value in trasmitted PETs (always 0x68, "ASF").
Change:
Use the Event Source Type from the ASF push message and ASF_ALRT record
when sending PETs.
---------------------------------
Version 8.00 -- June 6, 2008
---------------------------------
Enhancements:
=============
1. Change
ASF Firmware using new build environment. ASF firmware now built in
Win32 with a new compiler.
2. Change (CQ35081)
Added support for ASF Sensors. ASF Firmware will query the devices listed in the
Fixed SMBus Address structure in the ASF_ADDR record of the ASF! table for whether
it is a ASF Sensor device. If so, it will poll the device(s) periodically. If
there are any change in the status from the last poll then a PET alert message
will be sent.
Fixes:
======
1. Problem: (CQ34961)
5764M B0 LOM running XP SP3, enable ASF using BACS3 will drag
down the system performance
Change:
Caesar II has H/W bug which will corrupt the accessed PCI config register
when the PCIe link is running slow and the chip core clock is running fast.
Specifically, the ASF firmware was reading the register 0x68 to determine
whether the chip family is a Stanford. Solution is to read the
Receive List Placement Statistics Enable Mask Register (0x2018) to determine
the chip family.
---------------------------------
Version 7.20 -- February 4, 2008
---------------------------------
Fixes:
======
1. Problem: (CQ33758)
Version 7.19 BCM5755 ASF is not working due to format.init text section value change.
Change:
Decouple format.init for pass-thru-lite from ASF, and restore old value back.
---------------------------------
Version 7.19 -- January 24, 2008
---------------------------------
Fixes:
======
1. Problem: (CQ33051)
Version 7.18 code change increases init section code size. For
5752, this code size is too large.
Change:
Put in ifdef to only enable version 7.18 code change for Caesar II.
---------------------------------
Version 7.18 -- December 11, 2007
---------------------------------
Fixes:
======
1. Problem: (CQ32156 CQ32337)
For 5764M: ASF PETs are not sent out of NIC in Vaux mode until after
90 seconds delay.
Change:
Caesar II has no access to PCI config space in Vaux, it takes 10msec to
timeout. Optimize code to do LogicalToPhysicalAddressIsNeeded() checking
once during seprom_init() and store result in static variable,
so PCI timeout in Vaux, only happen once and does not impact loading
of firmware and config from NVRAM.
------------------------------
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 3.2.4.5 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 3.2.3.4 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 3.2.4.5 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 3.1.1.1.
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 3.2.3.1:
"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 3.2.3.3.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 3.2.3.1 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 3.2.3.3.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[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 3.2.3.1 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 3.2.4.1).
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 4.1.2.5 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
4.1.2.5 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 3.2.4.4
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.