FW release W8388-5.110.22.p23
Date: 11/20/2008
md5sum: 5e38f55719df3d0c58dd3bd02575a09c


Bug fixes
----------
        1. Boundary condition for WOL rule has been fixed, if 
           offset of the WOL rule exceeds the frame size than it will be considered
           as invalid rule for that particular frame.
            


FW release W8388-5.110.22.p22
Date: 10/20/2008
md5sum: b1c4a4382389ad5e9f4982622aa0a8b1


Bug fixes
----------
1. Fix for OLPC ticket 8666

2. Fix for OLPC ticket 8667

3. Fix for bug28263, WOL filter should not accept existing WOL rule.
   http://bugs-02.marvell.com/SW/show_bug.cgi?id=28263

4. Fix for bug28544, API to set/get probe response retry limit.
   http://bugs-02.marvell.com/SW/show_bug.cgi?id=28544
   For changing value of Probe Response Retry Limit Command will be
   iwpriv msh0 prspretrylt #VALUE  /* Argument will be new value */
   For example: for changing value of probe response retry limit to 10 
                iwpriv msh0 prspretrylt 10
   For retrieving value of Probe response retry limit command will be
                iwpriv msh0 prspretrylt  /* No argument required */

5. Fix for bug28660
   http://bugs-02.marvell.com/SW/show_bug.cgi?id=28660
   When the XO is in the infra mode and if it tries to connect to a non-existing
   AP, after the "iwconfig eth0 essid <non-existing_AP> mode man-" command is
   issued the XO stops beaconing


Notes
-----
1. Driver patch is required to support API for get/set probe response retry 
   limit. 
   Driver should add command CMD_ACT_SET (0x00) or CMD_ACT_GET (0x01) 
   followed by data while sending CMD_ACT_MESH_SET_GET_PRB_RSP_RETRY_LIMIT
   to firmware.

 

FW release W8388-5.110.22.p20
Date: 09/10/2008
md5sum: 6893f13b996a46b077c1e5aeb35f4c1a

New Features
------------
1. Enhancements for WOL feature

	1. Number of WOL rules has been increased from 8 to 16.
        2. Multiple iwpriv calls can be used to set wol rules for one type 
	   of packet, in previous firmware version only one iwpriv was allowed.
	3. Offset is calculated from the starting of LLC header of the 
           ethernet frame.

	Example:
  	--------
	  
        Consider the topology 
             A	<---------> B	
            
	 Where A and B are connected using mesh and A is pinging to B, 
         with payload 0xef 

	 ping B -p ef 	

 	 Assume that B is in enhanced host sleep mode and wants to wakeup on 
         pattern 0xaa (LLC header) at offset 0 or 0xef at offset 0x55. 
         The following rule example would set this rule on node B. 

         iwpriv msh0 "u m 0xaa.ff@0 || 0xef.ff@55"
	 
	 or we can set same rule using multiple iwpriv calls 

	 iwpriv msh0 "u m 0Xaa.ff@0"
	 iwpriv msh0 "u m 0Xef.ff@55"


2. APIs to enable, disable and to get status of dynamic contention window (DCW)
   adaptation logic.

	  Example:
          --------

	  iwpriv msh0 mesh_set_cw 0 	/* for disabling DCW */
	  iwpriv msh0 mesh_set_cw 1 	/* for enabling DCW  */
	
	  iwpriv msh0 mesh_get_cw 		/* Check the current DCW status */
	   msh0		mesh_get_cw: 1	/* It shows DCW is enabled */
	   

3. Adding MODULE_TYPE signature flag in flash for boot2 version 0x311b so 
   that boot2 version 0x311b does not wait for infinite time for downloading 
   firmware from the host.



FW release 5.110.22.p18
Date: 08/26/2008
md5sum: af642c0558e716e3cb4b3d449a938cd8

Bug fixes
----------

1. OLPC ticket 7973
   http://dev.laptop.org/ticket/7973

2. Honor ALL_MULTI flag in the receive path.



FW release 5.110.22.p17
Date: 07/15/2008
md5sum: 43798c207c347b27ebb2c8be3614de7f 

New Features
------------
1.	Support for Firmware, boot2 and Non Volatile configuration parameters
	update on active antenna module.
	Firmware returns BOOT_CMD_RESP_NOT_SUPPORTED (0x2) command respone
	when upgrade command is not supported.
	
	Note.
	
	1.	Firmware/boot2/non-volatile configuration upgrade currently
		supported on active antenna (512KB external modules).
		In case of other modules, firmware returns command response
		BOOT_CMD_RESP_NOT_SUPPORTED (0x2) to the host driver.

	2.	More than one firmware/boot2 upgrade can be done, without 
		rebooting/resetting the card/device.

	3.	Three capability bits are defined to notify driver about the 
		firmware/Boot2/non-volatile configuration parameter upgrade
		feature. Driver can get information about these bits by
		checking the firmware capability field of GET_HW_SPEC (0x3)
		command response.

		Host driver should issue upgrade command only if the 
		corresponding capability bit in fwcapinfo is set to 1. 
		
		These bits are
		
		FW_CAPINFO_FIRMWARE_UPGRADEABLE bit 13
		FW_CAPINFO_BOOT2_UPGRADEABLE  bit 14
		NON_VOLATILE_CONFIGURABLE bit 15

2.	Do not adapt CWMax while running dynamic contention window adaptation.


Bug fixes
----------
 	1) OLPC ticket 7150: 
	   http://dev/laptop.org/ticket/7150
	   Allow zero-delay PREQs

	2) OLPC ticket 7016:
	   http://dev/laptop.org/ticket7016

	3) Set default CWMin, CWMax as per IEEE 802.11g standard.
	

Notes
-----
1. Driver patch is required for firmware/boot2 upgrade feature.
2. Boot2 version 0x311B waits for programmed boot2 wait time only if offset
   0x7c of flash module contains 0xFFFF2937. 
   While doing firmware upgrade on new 512K module using this version of firmware
   boot2 would not wait for 'boot2 command wait time' and would jump to firmware
   stored in the flash.



FW release W8388-5.110.22.p14

New Features
------------

1. Signature based WOL filter

    (see http://dev.laptop.org/ticket/6993 for details)

2. Support for 32 multicast addresses.

Bug Fix
-------

1. OLPC ticket 6805

    http://dev.laptop.org/ticket/6805



FW release W8388-5.110.22.p10

Bug Fixes
---------

1. All 0xFF MAC addresses during bootup.

    http://dev.laptop.org/ticket/6869#comment:1

    The original implementation of mesh start was based on populating mesh
    start command using buffers used for command processing and sending this
    command to command task.

    Driver after firmware download waits for either FIRMWARE_READY (0x30)
    event or (in the absence of this event) 200ms.

    In the absence of FIRMWARE_READY event, this wait 200ms period (long
    enough to start all the tasks in firmware and finish up mesh start
    processing) everything worked fine as there was no conflict accessing
    command buffer, which is used for the driver commands.

    With FIRMWARE_READY event in place, driver issues GET_HW_SPEC (0x3)
    command, immediately after receiving this event. This sometimes caused
    incorrect command response due to overlapped use (by driver command and
    mesh start logic) of command buffers.



FW release W8388-5.110.22.p9

New Features
------------

1. Firmware ready event.

    Firmware sends event 0x30 (FIRMWARE_READY) once it's downloaded from
    host and up.

Bug Fixes
---------

1. OLPC ticket 6589.

    http://dev.laptop.org/ticket/6589
    Fixed timers, which are used for mesh routing, leak during mesh stop.



FW release W8388-5.110.22.p8

New Features
------------

1. Dynamic MAC contention window adaptation.

    Based on number of neighbors MAC contention window is adjusted. Current
    implementation relies on beacons received, with assumption of 100ms
    beacon interval, and active neighbors.

Bug Fixes
---------

1. OLPC ticket 4616: Mesh doesn't resume from suspend on receipt of
multicast packets.

    http://dev.laptop.org/ticket/4616
    Multicast filter in firmware also filtering broadcast packets.
    Modified the filter so that filter will not process broadcast packets.

2. OLPC ticket 6709: Stop beacon transmission during monitor mode.

    http://dev.laptop.org/ticket/6709

3. OLPC ticket 4927: [firmware] beacon interval gets reset by other operations

    http://dev.laptop.org/ticket/4927 Preserve beacon setting during scan.



FW release W8388-5.110.22.p6

New Features
------------
1.Configurable probe response retries. Probe response retries can be set 
from driver 
from 0 (no probe response) to 15.Default probe response retry set to 2 in 
the firmware.

Bug Fixes
----------
1.OLPC ticket 6600:
USB fails to enumerate after warm reboot.
http://dev.laptop.org/ticket/6600

2.Loss of first packet that wakeups host during enhanced host sleep.
http://dev/laptop.org/ticket/3733
http://dev.laptop.org/ticket/6528

3.Wakeup host --during enhanced host sleep-- after a programmable delay.
The wireless module will initiate host resume, when specified number of 
milliseconds expires. 
The host configured programmable delay can be from 1ms to 1000ms.

Notes
-----
1.Driver patch is required for setting up max probe response retries.



FW release W8388-5.110.22.p1

* Fixes scan failures when a link loss event happens concurrently with the 
scan.
* Adjusts task priorities in order to reduce probability of race 
conditions.

