release.txt Driver File Contents (Broadcom827.exe)

Release Notes
=============

Broadcom ASF 2.0 Firmware
for BCM5750/BCM5751/BCM5752/BCM5753/BCM5721

------------------------------
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/IPMI 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

release.txt Driver File Contents (Broadcom827.exe)

Recent Help Articles

More Popular Downloads

How To Update Drivers Manually

Recent Help Articles

More Popular Downloads