release.txt Driver File Contents (R243173.exe)

        Release Note for BCM5751/5751m BOOT Code Firmware

Version 3.16 or later:
  From this version or later, the release.txt is shared among all Shasta
  devices. Please see releases.txt for the release text.
Version 3.15:

  1. Turn core clock to slow speed in WoL
      When bootcode going to WoL mode. The core clock was not slowed
      5705/Shasta clock control bits are different from 5703 or 5704 devices
      and it was using 5703 bits to control core clock. 
      Changed the code to program correct bits to slow clock to save power
      under WoL mode (VAUX power only mode). 
      This bug does not cause any functional problem. Fixing this problem 
      will give us a better power consumption under WoL mode. 
Version 3.14:

  1. Changed version to 3.14.
      Version 3.13 has two version of code. One had version string with
      "3.12" and later changed to "3.13".
      When initially releasing version 3.13, the version string was not 
      updated. Then later, corrected the string. 
      Released version 3.14 to avoid confusion.
      This release will have the same functionality as v3.13.      

Version 3.13: 

  1. Change Wireless Combo mode LED setting
      LED Wireless Combo mode does not work
      The hardware setting changed from A0 to A1 for Wireless Combo mode. 
      [15:11] = 10000 for A0
      [15:11] = 10011 for A1
      Since A0 never worked for this mode, the A0 setting is ignored.
      The new code will set 10011 for Wireless Combo mode. 
Version 3.12:

  1. Change voltage value.
      There was no problem with previous value, 0xbf00000; however, after the 
      hardware engineers' analyzation, they have concluded that 0xec00000 is 
      closer to 1.2v/2.5v power voltage; therefore, we will use this voltage
      from this version. This setting will only affect A0 revision silicons.
  2. Disabled beacon signal
      There is possible ICH locking by beacon signal due to the existing Intel 
      bug and since we are not using beacon signal, we will disable this from
      this version. 
      Disabled the beacon signal
  3. Removed UART support
      UART was only for debugging purpose. Since the device is more stable now,
      we will only build UART support version upon request. By default, we will
      removed this to make the code size within 8k.       
Version 3.11:

  1. Fixed ASF/Driver handshake 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.
      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. 
      Change bootcode to preserve any value in last_driver_state, 0xc04. 

Version 3.10:

  1. Changed voltage workaround value back to 0x0fb00000
      Version 3.09 has mistakenly using the experimental voltage workaround
      value 0x0ec00000.
      The experimental code was checked in to source control.
      Changed back the workaround value to 0x0fb00000                     

Version 3.09:

  1. Writes firmware id to shared memory rx_cpu_firmware_id field
      Phase1 & Phase2 code will write the firmware id to rx_cpu_firmware_id.
  2. Added new support for Shasta LED modes
      Wireless combo mode was not supported
      New mode; Wireless combo mode, Shasta Mac mode, and Mac mode were added
      Chip revision A0 has problem with wireless mode, should be fixed in A1.  
Version 3.08:

  1. Fixed LED blink problem
      With version 3.05a, LED would blink.
      Phase 1 code detects phase2 code CRC error in mbuf and could not
      jump to execute the code. It blinks LED to indicate the failure.
      By adding NOP operation, the problem will go away.
    Root Cause:
      When reading the code from NVRAM, the FIRST and LAST command bits 
      were assigned incorrectly.
      Originally, the firmware was loading the entire phase2 code in one 
      big block of sequential read. The FIRST bit was assigned to the first 
      word of phase2 code and the LAST bit was assigned to the last word of 
      phase2 code.
      For Shasta, since the NVRAM resource is shared by BroadSafe, we changed 
      to code to load phase2 code in small block of max. 256 bytes. When the 
      loading address is the first word of phase2 code or the address is 
      xxxx00, the FIRST bit will be set and then the last word of phase2 or 
      the address is xxxxfc, the LAST bit will be set. This logic allows 
      BroadSafe to gain the arbitration in the middle of loading phase2 code. 
      The problem occurs when the starting offset of phase2 code was sitting 
      at xxxxfc. For version 3.05a, it was located at 0xcfc. Initially, the 
      FIRST bit was assigned; however, when it detected the offset was xxxxfc, 
      it changed to LAST bit. The first byte was attempt to be read by LAST 
      bit without FIRST bit and cause the NVRAM block state machine to misbehave. 
      This was causing the loading of the first word data to be wrong. As 
      result, the CRC calculation goes wrong and caused LED to blink. 
  2. Fixed NVRAM type detected
      The bootcode will not boot if the NVRAM AT25F512 is used.
      The specification to determine NVRAM type has been changed from 2 bits
      to 4 bits and it is not compatible with other (non-Shasta) devices spec.
      Changed the NVRAM type detection to SHASTA specific code.
      With this change, the bootcode can read data from AT25F512; however,
      write operation is not supported. This means, vpd write will not work

Version 3.07:

  1. Added phy_type field in manufacture data block
      PXE code needed this field to determine the phy type
      Hard coded this field to be copper type
  2. Read revision id from PCI config. register
      For all legacy PCI bus, without main power, the PCI config. space
      was not available. Since the revision resides in PCI config. space,
      we had to determine the revision using phy register or other creative
      way to find out the revision. Since PCIE mode, the PCI config. space
      is always accessible, this means the creative way is no longer needed.
      The code is changed for PCIE to read the revision from 0x68 directly.
  3. Applied workaround for Windows restart yellow bang problem.
      When WoL is disabled, after Windows shutdown/hibernate/standby, the 
      device will yellow bang out after restart.
      When Wol is disabled, after Windows shutdown or hibernate, to save 
      power, the firmware will shutdown the device. When system is coming 
      back, with PCI reset, the chip should come back alive; however, that 
      was not the case. Because of it, Windows will not be able to recognize 
      the device any more.
      For revision A0, we don't shutdown the device.
  4. Restored algorithm in version 3.05. 
      To over come the mystery LED blink issue, the algorithm implemented
      in 3.05 has been removed in 3.06. 
      After the investigation, we isolated that the 3.05 algorithm was not 
      the root cause of the LED blinking issue; therefore, we are restoring 
      the algorithm.
      Algorithm restored.
Version 3.06:

  1. Changed LED programming method back to version 3.04. 
      For some reasons, with version 3.05, we cannot access register 0x40c
      Since we know with version 3.04, it was working correctly, the LED
      mode programming method is reversed back to version 3.04. 
    Side effect:
      With version 3.04 method, there is no protection against LED mode.
      The specification states, when share mode is used, LED mode must be
      in MAC mode. 
Version 3.05:

  1. Changed shared_traffic_link_led bit define
      The shared_traffic_link_led bit should bit 14 instead bit 13.
      The Shasta register spec. version 2.2 had typo.
      Changed the define from bit 13 to bit 14.
Version 3.04: 

  1. Support shared_traffic_link_led bit in configuration
      We needed a new bit to define the behavior of green LED in 
      NVRAM configuration. This bit is defined in bit 15 of 0xc8/0xd8.
      When set the Link LED performs dual role: Solid green, when there 
      is a link. Blink when there is an activity. This bit takes effect 
      only when bit 2, and 3 of offset 0xc8/0xd8 are zero. (LED mode = 
      MAC Mode)
      The bootcode will copy this bit to Mac LED control register
      (0x40c) bit 13. 
Version 3.03: 
  1. Enhanced UART functions
    a. Changed Read command display format
    b. Accept UART empty line
    c. Changed so it takes leading white spaces before commands
    d. Read length converted to actual length instead of count
  2. Fixed UART bug
      The value input had bug reading hex number 'a' to 'f'. Because
      of this, for example, reading from address 0x7c00 was actually
      reading from 0x7f80 and caused cpu to hang. 
      Fixed the charactor input to integer converting routine. 
  3. Applied workaround for 'no snoop' 
      We needed to clear 'no snoop' and 'relax ordering' bit to 
      make master DMA to work.
      Added the code to clear those bits upon reset.    

Version 3.02:
  1. Releasing two version of bootcodes.
      We need both PCIE 1.0 compliance and 1.0a compliance version
      Released two version of bootcodes
      ee5751c3.02a for PCIE 1.0a compliance
      ee5751c3.02 for PCIE 1.0 compliance
  2. Added UART support
      UART debugging was needed for testing
      incorporated UART code into regular bootcode.
    Side effect:
      Now the bootcode size is 12K instead of 8K.
  3. Disabled Flow Control timeout
      We needed to put this workaround on both 1.0 and 1.0a version
Version 3.01:
  1. Program device to be PCIE 1.0 compliance.
      The bootcode was not programming the mode, and we needed
      the device to be PCIE 1.0 compliance. 
      Program device to be PCIE 1.0 compliance.

Version 3.00:
    Initial version
Download Driver Pack

How To Update Drivers Manually

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.

server: web4, load: 0.41