Firmware release - 5.110.22.p17

[carrano]

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.

Notes:

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

md5sum: 43798c207c347b27ebb2c8be3614de7f *usb8388.img

Download

Download from the standard location http://www.laptop.org/teamwiki/index.php/Image:Libertas-firmware.tgz

[carrano]

Confirming that this firmware fixes #7150.

[mstone]

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

[cscott]

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

[cscott]

In joyride-2210. Please test.

[carrano]

Cscott,

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.

--Ricardo

[cscott]

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?

[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 <cscott@laptop.org>
Date: Fri, Mar 14, 2008 at 11:45 PM
Subject: Re: wireless firmware 5.110.22.p6
To: Michail Bletsas <mbletsas@laptop.org>
Cc: techteam@laptop.org, dennis@laptop.org


On Fri, Mar 14, 2008 at 10:30 PM, Michail Bletsas <mbletsas@laptop.org> 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.
 --scott

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 <michael@laptop.org>
to	Ricardo Carrano <carrano@laptop.org>
cc	John Watlington <wad@laptop.org>,
Kim Quirk <kim@laptop.org>,
Michail Bletsas <mbletsas@laptop.org>,
Jim Gettys <jg@laptop.org>,
Chris Ball <cjb@laptop.org>,
"C. Scott Ananian" <cscott@laptop.org>,
Javier Cardona <javier@cozybit.com>
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...]

Yours,

Michael

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.

[kimquirk]

Closing as it is in joyride builds.