rt2x00.serialmonkey.com

Can I know why rt2x00 needs separate firmware images downloadable from Ralink site instead of build-in firmware like hex array in .h file (e.g. <kernel dir>/drivers/net/acenic_firmware.h, <kernel dir>/drivers/net/typhoon-firmware.h, <kernel dir>drivers/net/starfire_firmware.h)? Without firmware the driver is simply incomplete. It makes user trouble getting the firmware on his own. Many distribution can forget to add proper firmware package. Some people using Live CD distributions will have to carry separate pendrive/floppy with the firmware file. Any way one day Ralink may remove firmware images from their web site and what will happen then?

With build in firmware life would be easier.

I am not trolling, I am worried. That is serious question.

We cannot include them because that is a direct violation of the GPL license, if the firmware was GPL then perhaps it could be added, but even then it is not recommended since it is much cleaner to read the file and dump that into the registers. That will also allow users to upgrade the firmware image without upgrading the kernel.

If Live distros need the firmware, they can just package it themselves, the firmware license does allow redistribution so all distros can add the firmware files into their package management systems.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

It seems that Linux general firmware policy is to include them in the driver rather then in separate file:

<kernel dir>/drivers/net/typhoon-firmware.h - BSD license! yet still in kernel mainline and no GPL volation

<kernel dir>drivers/net/tokenring/3c359_microcode.h even better:

/*
* The firmware this driver downloads into the tokenring card is a
* separate program and is not GPL'd source code, even though the Linux
* side driver and the routine that loads this data into the card are.
*
* This firmware is licensed to you strictly for use in conjunction
* with the use of 3Com 3C359 TokenRing adapters. There is no
* waranty expressed or implied about its fitness for any purpose.
*/

Any way OpenBSD developers asked for ISC licensed firmware and they got one:
http://www.openbsd.org/cgi-bin/cvsweb/s ... ocode/ral/
file:
http://www.openbsd.org/cgi-bin/cvsweb/s ... web-markup

How about asking Ralink for GPL microcode (or use ISC one)

Well that there are a few instances where apparantly developers have managed to push the firmware into the kernel does not weigh up to the countless of other drivers who have the firmware as a seperate file. There is also a kernel options that should prevent firmware from being compiled in...
All in all, it is just easier to have it as a seperate file rather than bloating the driver with firmware it only need once, that does safe memory since the file only needs to be read once and can be cleared from memory later on. Where a in-kernel firmware file would remain in memory continuously.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Hmm... perhaps rt2x00 could have firmware (hex in source) and in makefile function of building blob firmware file from this hex - developers would have firmware in separete file and users ability to use "build in" blob firmware file or remove it and use newer one from Ralink (and wait till developers would upgrade the hex).

That is an ugly, not recommended approach.
In short:
- it would not be preferred by the kernel developers
- it would not be preferred by the rt2x00 developers

And since I am both, that solution wouldn't make it into rt2x00.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

Summarizing:
- no hex array firmware in source (even GPL licensed)
- no firmware blob distributed with source (even auto generated from GPL hex array)

I can not understand it I think that OpenBSD way is better, but well it is your project...

Anyway I hope you keep copy of Ralink's firmware blobs some ware on your server in case Ralink "changes it's mind" or get bought by Broadcom