Opened 9 years ago

Closed 9 years ago

#7528 closed defect (fixed)

Firmware release - 5.110.22.p17

Reported by: carrano Owned by: carrano
Priority: high Milestone: 8.2.0 (was Update.2)
Component: wireless Version: not specified
Keywords: Cc: mbletsas, jcardona, rchokshi@…, ashishs@…, dsaxena, mstone
Blocked By: Blocking:
Deployments affected: Action Needed: qa signoff
Verified: no


From Marvell Release notes:

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 response when upgrade command is not supported.


  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.
  1. More than one firmware/boot2 upgrade can be done, without rebooting/resetting the card/device.
  1. 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


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

Bug fixes

1) OLPC ticket 7150:

Allow zero-delay PREQs

2) OLPC ticket 7016:


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


  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 5.110.22.p17
Date: 07/15/2008

md5sum: 43798c207c347b27ebb2c8be3614de7f *usb8388.img


Download from the standard location

Change History (11)

comment:1 Changed 9 years ago by carrano

  • Cc mbletsas jcardona rchokshi@… ashishs@… added

comment:2 Changed 9 years ago by carrano

Confirming that this firmware fixes #7150.

comment:3 Changed 9 years ago by dsaxena

  • Cc dsaxena added

comment:4 Changed 9 years ago by mstone

  • Action Needed changed from review to package
  • Owner changed from carrano to cscott

Scott - please see that this makes its way into joyride. Thanks so much!

comment:5 Changed 9 years ago by cscott

  • Action Needed changed from package to add to build

Rebuild rpm, added to my public_rpms. Should be in next joyride.

comment:6 Changed 9 years ago by cscott

  • Action Needed changed from add to build to test in build

In joyride-2210. Please test.

comment:7 Changed 9 years ago by cscott

  • Resolution set to fixed
  • Status changed from new to closed

comment:8 Changed 9 years ago by carrano

  • Resolution fixed deleted
  • Status changed from closed to reopened


I'm reopening this ticket.

As previously discussed, the release process for wireless firmware includes regular tests that are performed on all firmware releases and specific tests that confirm that bug fixes and new features introduced are indeed working as expected. And the ticket is the place where the results (good or bad) are reported.

These tests are not over for this release, so let's please keep it open until we are happy with the firmware. Closing the ticket marks the transition to a new test phase (the joyride), what brings me to the next paragraph.

The agreed upon release process determined that the firmware would be released to joyride only when these tests were finished. I noticed that this was not observed this time, but since joyride is also a test environment, and since this initial tests were taking more than the usual (I admit that, and the reason is that it took us a long time to validate the main new feature of this release: the upgrade of images to the standalone module) I considered this changing on the rules, at this specific moment, reasonable. But I see it as an exception.

This release process has increased the overall quality of what's delivered to the community. Note that since it was implemented only two releases were approved to go ahead (into joyride), p6 and p14. Typically, when problems are found we report and interact with Marvell that works fast and release a new version. These two releases p6 and p14 were definitely superior to its predecessors (we could not say the same of p8, p9 and p10, for example).

I suggest we keep this process which is a clear advancement over the previous scene and moreover it is the result of an extensive debate.

So, once we're convinced that this is indeed our next firmware we should keep this open.


comment:9 follow-up: Changed 9 years ago by cscott

  • Cc mstone added
  • Owner changed from cscott to carrano
  • Status changed from reopened to new

Please reassign this bug to someone who is charged with doing the testing, then. My part of this bug is over.

Also: is this firmware release process you describe documented anywhere? This is the first I've heard of it. I was specifically asked by m_stone to add this firmware to joyride. Was he wrong to do so?

comment:10 in reply to: ↑ 9 Changed 9 years ago by carrano

Replying to cscott:

Please reassign this bug to someone who is charged with doing the testing, then. My part of this bug is over.

That would be me. I forgot to put it back to me, thank you for doing that.

Also: is this firmware release process you describe documented anywhere? This is the first I've heard of it.

I'm surprised to read that because it all started with your idea:

---------- Forwarded message ----------
From: C. Scott Ananian <>
Date: Fri, Mar 14, 2008 at 11:45 PM
Subject: Re: wireless firmware 5.110.22.p6
To: Michail Bletsas <>

On Fri, Mar 14, 2008 at 10:30 PM, Michail Bletsas <> wrote:
> FW release W8388-5.110.22.p6

Have we set up a process for ensuring new wireless firmware get into
the build yet?  A good start would be filing a trac bug -- and
assigning to Dennis, I think, who maintains the RPM packaging.  We'd
probably want this new firmware to age some in joyride, and it
probably makes sense to start that aging process as soon as possible.

It was then discussed with all the involved (I'm sure some pipemail research will reveal that). After some months the subject was discussed again. Please check Michael 's comments on that, (you were cc'd):

from	Michael Stone <>
to	Ricardo Carrano <>
cc	John Watlington <>,
Kim Quirk <>,
Michail Bletsas <>,
Jim Gettys <>,
Chris Ball <>,
"C. Scott Ananian" <>,
Javier Cardona <>
date	Thu, Apr 10, 2008 at 4:05 PM
subject	Re: wireless firmware update

On Thu, Apr 10, 2008 at 03:15:28PM -0300, Ricardo Carrano wrote:
> And the truth is that the current process is public and documented (for
> instance there is a lot of on going discussion on the 22.p9 fw - please
> refer to #6869).

Making a ticket to track the inclusion of the package into builds is
perfectly appropriate and I have been watching #6869 with interest.

> Yes, I insist: there is a process. And its ticket based, and the
> instructions were: once it is ready to joyride, we assign the ticket
> to dgilmore. If I got it wrong I appreciate if someone points me to
> the correct direction.

Dennis comes into the picture during periods of change control which
occur during periods of motion towards a stable release. During periods
of unstable development, nothing more than notification is required in
order to change the build. Also, OLPC has no present intentions to
further change candidate-703 before making it official-703. This means
that we are at the very beginning of a period of unstable development.

In short, please advertise new wireless firmware blobs and insert them
into Joyride at will until we announce the resumption of change control
in preparation for our next release. This behavior will result in an
appropriate version of your new wireless firmware being included in our
next release with high probability.

[...removed unrelated part...]



I was specifically asked by m_stone to add this firmware to joyride. Was he wrong to do so?

I think I already commented on that.

comment:11 Changed 9 years ago by kimquirk

  • Action Needed changed from test in build to qa signoff
  • Resolution set to fixed
  • Status changed from new to closed

Closing as it is in joyride builds.

Note: See TracTickets for help on using tickets.