Release Note for BCM5704/BCM5704s BOOT Code Firmware ==================================================== 5704, 5704s ------------------------- Version 3.41 --- 2/13/06 ------------------------- 1. Not to slow down the core clock when ASF/IPMI is enabled Problem: CQ#23235 Ungraceful Shutdown From Linux Causes IPMI Connectivity Loss Cause: Bootcode was slowing down the core clock when there is no VMain. IPMI requires the firmware to be running at fast speed. Fix: Not to slow down the core clock if ASF/IPMI is enabled. ------------------------- Version 3.40 --- 12/19/05 ------------------------- 1. Work-around the IDDQ issue Problem: CQ#22548 When both devices WoL/Management firmware are disabled, the device may disappear until unplug AC power. Cause: After firmware determine the device no longer needs power, it puts the device into IDDQ mode; however, the IDDQ mode is not cleared by the following reset. Fix: Don't put the device into IDDQ mode. 2. Move GPIO initialization to Phase1 code Enhancement: Originally, activating VAUX power was done in phase 2 bootcode. However, once driver waited for phase1 signature, driver may start to configure GPIO for WoL setting. The 2nd phase GPIO initialization may destroy driver's setting. This problem was worked around by driver by waiting for phase2 bootcode to be loaded before the GPIO initialization. This change does not affect anything since driver already have the work around. ------------------------- Version 3.39 --- 10/11/05 ------------------------- 1. CQ#14101 Problem: Loss of BMC connectivity after ipmish power off Cause: When the secondary port was not in use, the Linux driver shut down the device and disabled WoL. When the device loses VMian, the bootcode would shutdown the device to honor driver's setting. When shutting down, the powerdown bit (bit 20 of 0x6804) could not be used (due the design). When shutting one port, the other port also gets turned off. As result, the port running IPMI also got turned off. Fix: When other port still needs power, do not shutdown the device by using shutdown bit. ------------------------- Version 3.38 --- 5/18/05 ------------------------- 1. Phy shutdown Enhancement: We used to have ASIC errata that shutting down phy in primary port causing other port to shutdown also. This was fixed in revision A1 and bootcode was never changed to reflect the change. This version is changed so only A0 will place the phy in super isolate mode instead of shutdown mode. All other revisions will simply shutdown the phy. By making this change, the device can further save some power. Impact: This change only affect copper devices. 2. Added a new field, Smbus address, in shared memory Enhancement: IPMI needed multiple SmBus addresses. The NVRAM address is stored at NVRAM. This version of bootcode reads the data and store the addresses in the shared memory 0xd54. ------------------------- Version 3.37 --- 2/25/05 ------------------------- 1. Turn of serdes when shutting down the device. Problem: The link was still on after device shutdown. Cause: After device is shutdown, the Serdes block was left powered on. Fix: Turned Serdes block off when device is shutting down. Note: This change is for 5704s device. ------------------------- Version 3.36 --- 11/29/04 ------------------------- 1. Changed Serdes power dissipated value Problem: The default value for Serdes power dissipated value was incorrect Fix: Changed value D3:D2:D1:D0 from 0.16.0.28 to 10.0.0.100 Note: This change only affect Serdes, 5704s device. ------------------------- Version 3.35 --- 11/10/04 ------------------------- 1. Swapped Port 0 & Port 1 TxSerdes override value Problem: Port 0 and Port 1 TxSerdes value was swapped from b57diag. Cause: B57diag is in little endian system while internal CPU is in big endian system. When two 16 bit value stored by little endian system was read as one 32 bit unit, the value is swapped. This problem can be fixed in either host program or firmware; however, since there already has other 16 bit value defined before, to keep everything consistent, firmware will make the change. Fix: Swapped Port 0 and Port 1 TxSerdes override value ------------------------- Version 3.34 --- 11/9/04 ------------------------- 1. Fixed Serdes TxSerdes register override function Problem: The version 3.33 change did not work on serdes devices (5704s) Cause: Serdes had a workaround that required a value to be over written to this register. As result, even if the override value was written initially, it got over written again with the workaround. Therefore, the change in v3.33 did not take effect. Fix: Fixed the bug Impact: This release will only affect 5704s. ------------------------- Version 3.33 --- 10/28/04 ------------------------- 1. Added TxSerdes register override feature Enhancement: Added new feature to configure TxSerdes 0:14 setting. When this feature is enabled, the value can be overridden by custom value. Note: Bit 18 of hardware config. enables this feature and NVRAM offset 0xec and 0xee has the value to override. 0xec for primary device, 0xee for the secondary device. 2. Added SST non-buffered flash SST45VF010 support Enhancement: Added SST 1MB non-buffer support. Due to buffering problem, no VPD write is supported. Because of VPD write limitation, we do not officially support this device. The following is the summary: SCLK: Bit 1, Buffered Mode, internal pull-down CS: Bit 0, Flash Mode, internal pull-down [SCLK,CS] Device Write Memo ------------- -------------- ----- ---------------------------- *00 AT24C512 Yes SEEPROM, AT24Cxxx, any size *11 AT45DB011B Yes Atmel Buffered 1MB Flash 01 SST SST45VF010 No SST Non-Buffered 1MB Flash * Officially supported 3. Removed VAUX cut off delay time Problem: Code size has reached 8k limit. Cause: By adding new feature to support txSerdes override, the code size has grown over 8k. Fix: We have a debug feature to delay in time to cut off power in NIC. This feature is not need as final product; therefore, will be removed in this version to save code space. ------------------------- Version 3.32 ---- 8/2/04 ------------------------- 1. Reset Write & Read DMA engine upon reset Problem: Some chips will assert interrupt signal when first time apply AC power. Cause: We found the interrupt assertion was caused by DMA engine coming up uninitialized. The LSI team has determined that the DMA engine reset issue root cause is a "race condition" with regard to how a reset event is handled internally in the device, whereby certain blocks inside the device may not actually get reset. So the recommendation from the LSI team is that we modify bootcode to reset both the read DMA and write DMA block. Fix: Upon device reset, issue a reset to both read and write DMA block. ------------------------- Version 3.31 ---- 5/5/04 ------------------------- 1. Added blinking feature when loading ASF code failed. Problem: Loading ASF failure case has been seen on certain system. Enhancement: In order to indicate loading ASF failed, blinking LED feature has been added. 2. Enable PXE only when PXE image exists Problem: System may hang when PXE is enabled without PXE image. Cause: Due to user error, it is possible PXE is enabled without image. Bootcode was enabling PXE based on enable/disable. As result, bootcode is returning garbage. Fix: Advertise PXE only when there is an image and PXE is enabled. ------------------------- Version 3.30: ------------------------- 1. Fixed ASF/Driver handshake problem Problem: Today, we are using the shared memory last_driver_state, 0xc04, as parameter for reset. last_driver_state got cleared by bootcode upon reset. For legacy method, driver deposit this parameter after GRC reset; therefore the symton is not showing up. However, by doing this, there will be a race condition between driver write and ASF code read. ASF code loading too fast or driver's delay is too long after GRC reset can cause ASF code to miss the command. The proper way to fix this should be done in both driver and firmware: Firmware should change to not to clear this field upon reset. Driver should deposit command prior to GRC reset; however this will not work with older firmware since the command get cleared upon reset; therefore, driver should deposit the command one more time after reset like before to prevent the device running with old firmware. Cause: Upon reset, bootcode is designed to initialize all shared memory between 0xb54-0xc28 to zero. Originally, when last_driver_state field was defined, it was only used for ASF self resetting purpose; therefore, the code has been changed to: "if the last_driver_state (0xc04) contains CPU_RESET (0x40), then preserve this value." Any other value was cleared to zero. When ASF code sees the value "CPU_RESET", it knows the reset was initiated by ASF code itself and will know how to handle the reset. This changed was made in more than two years ago, Dec. 92. and it was working since. Today, we defined more usage for last_driver_state parameter. However, since the bootcode will only preserve the value for CPU_RESET (0x40), any other parameter was zeroed. The reason, the problem never showed up until now was probably because, driver was writing the parameter after bootcode initialize shared memory to zero and before ASF was fully up and running. Now, we are trying to change the driver code to deposit signature and parameter before GRC reset, the problem showed up. fix: Change bootcode to preserve any value in last_driver_state, 0xc04.