Release Note for BCM5705 Family BOOT Code Firmware ================================================== 5705, 5705f, 5782, 5788, 5901 ------------------------- Version 3.27 ---- 7/8/05 ------------------------- 1. Removed NIC cut off delay time feature Problem: In NIC, when firmware detects VMain is not present and WoL is diabled, it will cut off power by using GPIO 1 to generate a rising edge. This debug feature is to delay the time before cutting off the power. The user had choice of delaying 250ms, 150ms, 50ms, or 0ms before cut off power. By default, the delay time was 250ms. However, this feature not only appears to be no value in final product but also to cause excessive power comsumption before cutting off power, it is better to remove this feature. Fix: Removed this feature. Impact: Changing VAUX cut off delay value in NVRAM configuration (offset 0xc4, [23:24]) will take no effect. 2. Added SST non-buffered flash (SST45VF010/SST45F512) support Enhancement: Added SST 1MB non-buffer support. Due to buffering problem, no VPD write is supported. The following is the supported NVRAM 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 01 SST SST45VF512 No SST Non-Buffered 512KB Flash 3. Removed disabling WoL procedure Enhancement: Earlier bootcode used to be disabling WoL if the device is in D3 state while VMain presents. Cause: In the old days, there was no good communication defined between driver and bootcode for WoL initialization. One good way for bootcode to determine if driver present or not was by looking at power state. Only driver could place the device into D3 state while VMain present. In order to support old driver without WoL handshake, bootcode was not arming WoL if D3 state was detected while VMain present. For 5705 family devices, all driver has WoL handshake defined, therefore, this line was no longer needed. ------------------------- Version 3.26 ---- 6/16/04 ------------------------- 1. Added Capacitive Coupling feature support CQ#10394 Enhancement: Added Capacitive Coupling (CC) support. Defined a new configuration in hw_config in nvram. When CC is enable in the NVRAM, the PHY must be reconfigured by setting bit 10 in register 0x18, shadow register 100b. Setting this bit configures the link pulse transmitter to function properly in a CC application. After enabling CC in the PHY, the link must be reset and auto-negotiation restarted. Note: Bootcode will only configure phy to this mode upon cold reset. When driver reset (with reset signature), bootcode will not touch phy registers. ------------------------- Version 3.25 ---- 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.24 (4/19/04) ------------------------- 1. Applied the workaround for higher BER problem Problem: On certain corners, bit-error-rate(BER) was higher then desired when cable length was 70m or less. Workedaround: By increasing hybrid bias current can reduce the BER. ------------------------- Version 3.23: ------------------------- 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 5705, 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. 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. 2. Turn core clock to slow speed in WoL Problem: When bootcode going to WoL mode. The core clock was not slowed Down. Cause: 5705/Shasta clock control bits are different from 5703 or 5704 devices and it was using 5703 bits to control core clock. Fix: Changed the code to program correct bits to slow clock to save power under WoL mode (VAUX power only mode). Note: This bug does not cause any functional problem. Fixing this problem will give us a better power consumption under WoL mode.