Release Note for BCM5703/2 Family BOOT Code Firmware
         ====================================================
                        5702, 5703, 5703s
                    
--------------------------                    
Version 2.43 ---- 11/29/04
--------------------------
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. 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, 5703s, device.   
        
-------------------------                    
Version 2.42 ---- 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 2.41 ---- 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 2.40
------------------------

  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.