Primary Firmware Download

[Pavel Roskin]

On Fri, 22 Aug 2003, Foy, Patrick wrote:

> We have an embedded application that requires all the download work to
> be done in the driver because if the card goes through a reset, the
> application might not know about the reset and therefore won't reload
> the firmware into RAM.

There is nothing wrong with having the complete firmware in the kernel
memory.  The alternative would be to generate a hotplug even and call
prism2_srec from hotplug.

If you load complete firmware images to the kernel, there is one more
issue.  If your changes to be integrated and maintained as part of HostAP,
please use the firmware download API.  You can keep firmware in memory if
you want, but it should be loaded rather than compiled into the driver for
legal reasons.

> I changed the download code to read the pda before the download begins and
> then restore the pda after the download completes.  This fixes the mac
> address problem, but the reported version is the previous version
> information.
>
> Any ideas how I can update the PDA to fix the version information?

I have no idea how you "restore the PDA" and what it means.  If you are
plugging the image in the driver, it's better that you read the PDA from
NVRAM (non-volatile RAM), as it's done in linux-wlan-ng.  You shouldn't
write to PDA.

I'm afraid you misunderstand the plugging procedure.  If you rely on
prism2_srec to plug the image, you are doing it wrong.  If you put
firmware to the kernel space, you should plug the image with the PDA from
the card.  This also means that the driver should be aware of PDRs.

You can look at a similar implementation for Symbol cards, but I didn't
implement firmware API yet: http://www.red-bean.com/~proski/symbol/

By the way please don't top-post.  It makes it inconvenient to quote your
messages.

-- 
Regards,
Pavel Roskin