Hello,
is preferred to have firmware in kernel binary (and go through array of chars)
or userspace (and load it through standard kernel api)?
For char sx driver in this case (I hope there is no later fw):
ftp://ftp.bitwizard.nl/specialix/sx_firmware_306c.tgz
Now it's 2 .c files used by loader through ioctl. After compilation it has:
text data bss dec hex filename
4 8416 2 8422 20e6 si2_z280.o
4 19484 2 19490 4c22 si3_t225.o
So convert it to binary (and load it through userspace) or simply #include it in
the sources? I hope the former is preferred?
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Wed, Nov 01, 2006 at 01:15:28AM +0100, Jiri Slaby wrote:
> Hello,
>
> is preferred to have firmware in kernel binary (and go through array of chars)
> or userspace (and load it through standard kernel api)?
IMHO, from a theoretical point-of-view, I prefer the way it is:
the driver will upload any firmware you tell it to upload.
Since writing the driver, some consensus has been reached on how
this is done. This, for example, doesn't involve the misc device
that I use.
> For char sx driver in this case (I hope there is no later fw):
> ftp://ftp.bitwizard.nl/specialix/sx_firmware_306c.tgz
> Now it's 2 .c files used by loader through ioctl. After compilation it has:
> text data bss dec hex filename
> 4 8416 2 8422 20e6 si2_z280.o
> 4 19484 2 19490 4c22 si3_t225.o
I see two different processors, there are three.
> So convert it to binary (and load it through userspace) or simply #include it in
> the sources? I hope the former is preferred?
>From a legal point of view, that is undesirable: You'd be linking
the propritary firmware with the kernel, which disallows distribution
of the resulting kernel or module binary.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
On Wed, 2006-11-01 at 01:15 +0100, Jiri Slaby wrote:
> Hello,
>
> is preferred to have firmware in kernel binary (and go through array of chars)
> or userspace (and load it through standard kernel api)?
generally the preferred way is for you to use request_firmware() API
which causes userspace to upload it to you via standard mechanisms.
This avoids kernel size bloat if it's not needed (by only having the
firmware in memory that is really really needed) and also avoids the
entire question of "can it be done within GPL" (not saying it can or
cannot, but usually if someone asks its a huge flamewar and this just
sidesteps the entire issue)
Ar Mer, 2006-11-01 am 01:15 +0100, ysgrifennodd Jiri Slaby:
> Hello,
>
> is preferred to have firmware in kernel binary (and go through array of chars)
> or userspace (and load it through standard kernel api)?
User space.
Alan
On Wednesday 01 November 2006 01:15, Jiri Slaby wrote:
> is preferred to have firmware in kernel binary (and go through array of chars)
> or userspace (and load it through standard kernel api)?
If you control the whole system, the ideal way is to have the system
firmware or boot loader come with the firmware blob and avoid worrying
about it in linux entirely. E.g. if you are using Open Firmware, you
can have the binary image as a property of the device in your device
tree, where Linux then goes looking for it.
Arnd <><
Rogier Wolff wrote:
> On Wed, Nov 01, 2006 at 01:15:28AM +0100, Jiri Slaby wrote:
>> For char sx driver in this case (I hope there is no later fw):
>> ftp://ftp.bitwizard.nl/specialix/sx_firmware_306c.tgz
>
>> Now it's 2 .c files used by loader through ioctl. After compilation it has:
>> text data bss dec hex filename
>> 4 8416 2 8422 20e6 si2_z280.o
>> 4 19484 2 19490 4c22 si3_t225.o
>
> I see two different processors, there are three.
And don't you know, where may one obtain some later release? I found only this
package which includes only these two.
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E