Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

James Bottomley
This is a reference implementation with the debian mkinitrd-tools
package.  It shows how to identify the firmware files necessary for
drivers in the initrd and also includes a primitive system for loading
them.

I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
tag.  Initramfs should be much easier because it already includes most
of the boot time loading; all it has to do is the piece identifying the
firmware for the selected modules.

James

---
Index: initrd-tools-0.1.84.1/mkinitrd
===================================================================
--- initrd-tools-0.1.84.1.orig/mkinitrd 2006-08-28 13:37:30.000000000 -0500
+++ initrd-tools-0.1.84.1/mkinitrd 2006-08-28 16:33:28.000000000 -0500
@@ -950,6 +950,7 @@ add_modules_dep() {
  return
  elif ! [ $oldstyle ]; then
  add_modules_dep_2_5 $VERSION
+ add_firmware $VERSION
  return
  fi
 
@@ -1016,6 +1017,25 @@ add_modules_dep_2_5() {
  fi
 }
 
+add_firmware() {
+ ver=$1
+ set -- $FSTYPES
+ unset IFS
+
+ cat modules.? |
+ while read junk mod junk; do
+ modpath=$(modprobe --set-version "$ver" --list $mod)
+ if [ -z "$modpath" ]; then
+ continue;
+ fi
+ p=$(modinfo -F firmware "$modpath" |sed 's/^/\/lib\/firmware\//')
+ if [ -n "$p" ]; then
+ echo $p
+ echo /usr/sbin/firmware_loader
+ fi
+ done
+}
+
 add_command() {
  if [ -h initrd/"$1" ]; then
  return
Index: initrd-tools-0.1.84.1/firmware_loader
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ initrd-tools-0.1.84.1/firmware_loader 2006-08-28 16:56:18.000000000 -0500
@@ -0,0 +1,29 @@
+#!/bin/sh -e
+#
+# firmware loader agent
+#
+FIRMWARE_DIRS="/lib/firmware"
+
+if [ "$SUBSYSTEM" != "firmware" ]; then
+    exit 0;
+fi
+
+if [ ! -e /sys/$DEVPATH/loading ]; then
+    echo "/sys/$DEVPATH/ does not exist"
+    exit 1
+fi
+
+for DIR in $FIRMWARE_DIRS; do
+    [ -e "$DIR/$FIRMWARE" ] || continue
+    echo 1 > /sys/$DEVPATH/loading
+    cat "$DIR/$FIRMWARE" > /sys/$DEVPATH/data
+    echo 0 > /sys/$DEVPATH/loading
+    exit 0
+done
+
+# the firmware was not found
+echo -1 > /sys/$DEVPATH/loading
+
+echo "Cannot find the $FIRMWARE firmware"
+exit 1
+
Index: initrd-tools-0.1.84.1/debian/rules
===================================================================
--- initrd-tools-0.1.84.1.orig/debian/rules 2006-08-28 16:07:52.000000000 -0500
+++ initrd-tools-0.1.84.1/debian/rules 2006-08-28 16:08:56.000000000 -0500
@@ -35,7 +35,7 @@ install:
  install -o root -g root -m 644 \
  echo init linuxrc debian/initrd-tools/usr/share/initrd-tools/
  install -o root -g root -m 755 \
- mkinitrd debian/initrd-tools/usr/sbin/
+ mkinitrd firmware_loader debian/initrd-tools/usr/sbin/
  install -o root -g root -m 644 \
  mkinitrd.conf modules debian/initrd-tools/etc/mkinitrd/
 ifeq ($(DEB_HOST_ARCH),powerpc)
Index: initrd-tools-0.1.84.1/linuxrc
===================================================================
--- initrd-tools-0.1.84.1.orig/linuxrc 2006-08-28 16:30:30.000000000 -0500
+++ initrd-tools-0.1.84.1/linuxrc 2006-08-28 16:40:45.000000000 -0500
@@ -10,3 +10,7 @@ echo 256 > proc/sys/kernel/real-root-dev
 mount -nt tmpfs tmpfs bin ||
  mount -nt ramfs ramfs bin
 echo $root > bin/root
+if [ -x /usr/sbin/firmware_loader ]; then
+ echo /usr/sbin/firmware_loader > /proc/sys/kernel/hotplug
+fi
+
Index: initrd-tools-0.1.84.1/init
===================================================================
--- initrd-tools-0.1.84.1.orig/init 2006-08-28 16:54:52.000000000 -0500
+++ initrd-tools-0.1.84.1/init 2006-08-28 16:55:01.000000000 -0500
@@ -366,6 +366,7 @@ get_cmdline
 [ -c /dev/.devfsd ] && DEVFS=yes
 
 mount -nt devfs devfs devfs
+mount -nt sysfs sysfs sys
 if [ $IDE_CORE != none ] && [ -n "$ide_options" ]; then
  echo modprobe -k $IDE_CORE "options=\"$ide_options\""
  modprobe -k $IDE_CORE options="$ide_options"



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Sven Luther
On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
> This is a reference implementation with the debian mkinitrd-tools
> package.  It shows how to identify the firmware files necessary for
> drivers in the initrd and also includes a primitive system for loading
> them.
>
> I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
> tag.  Initramfs should be much easier because it already includes most
> of the boot time loading; all it has to do is the piece identifying the
> firmware for the selected modules.

Notice that mkinitrd-tools is dead, and will probably be removed from etch.

mkinitramfs-tools and yaird are the two currently used tools.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

James Bottomley
On Tue, 2006-08-29 at 01:04 +0200, Sven Luther wrote:
> Notice that mkinitrd-tools is dead, and will probably be removed from etch.
>
> mkinitramfs-tools and yaird are the two currently used tools.

Yes ... I'm aware of that.  That's why this is a reference
implementation.  initramfs should be easier ... I just don't have any
initramfs systems at the moment, so I did what I had and could verify.

James



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Oleg Verych-2
In reply to this post by Sven Luther
Sven Luther wrote:
> On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
 >
>>I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
>>tag.  Initramfs should be much easier because it already includes most
>>of the boot time loading; all it has to do is the piece identifying the
>>firmware for the selected modules.
....
> Notice that mkinitrd-tools is dead, and will probably be removed from etch.
>
request_firmware() is dead also.
YMMV, but three years, and there are still big chunks of binary in kernel.
And please don't add new useless info _in_ it.

Nobody cares.
While this implementation exists, it wasn't well designed and hard to use.
As with in-kernel bootsplash and i18n, everything maybe done in userspace, only
with little help from the kernel:
<http://permalink.gmane.org/gmane.linux.kernel/435955>.

Thanks.

--
-o--=O`C  /. .\   (+)
  #oo'L O      o    |
<___=E M    ^--    |  (you're barking up the wrong tree)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

James Bottomley
On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> request_firmware() is dead also.
> YMMV, but three years, and there are still big chunks of binary in kernel.
> And please don't add new useless info _in_ it.

I er don't think so.

We (as in the Kernel) are forcing drivers on to this path.  You should
have noticed it already with the qla2xxx.  The aic94xx is the first
driver that's likely found as the boot driver for a system, that's why I
get to propose the reference implementation.

James



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Greg KH
In reply to this post by Oleg Verych-2
On Tue, Aug 29, 2006 at 02:35:26AM +0200, Oleg Verych wrote:

> Sven Luther wrote:
> >On Mon, Aug 28, 2006 at 05:11:42PM -0500, James Bottomley wrote:
> >
> >>I've tested this with the aic94xx driver using the new MODULE_FIRMWARE()
> >>tag.  Initramfs should be much easier because it already includes most
> >>of the boot time loading; all it has to do is the piece identifying the
> >>firmware for the selected modules.
> ....
> >Notice that mkinitrd-tools is dead, and will probably be removed from etch.
> >
> request_firmware() is dead also.

No it is not, not by any means.  I don't know where you got that idea.

James's patch is just fine, and needed.  I'll add it to my trees in a
bit.

> YMMV, but three years, and there are still big chunks of binary in kernel.

So, what does that have to do with this?  And actually, those binary
chunks have been there longer than three years, I think we are going on
6 or 7 for the ones under my control...

greg k-h


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Oleg Verych-2
In reply to this post by James Bottomley
James Bottomley wrote:
> On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
>
>>request_firmware() is dead also.
>>YMMV, but three years, and there are still big chunks of binary in kernel.
>>And please don't add new useless info _in_ it.
>
>
> I er don't think so.
>
Hell, what can be as easy as this:
,-
|modprobe $drv
|(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
`-
where /dev/blobs is similar to /dev/port or even /dev/null char device.
if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,

>
> James
>
?

--
--
-o--=O`C  /. .\   (+)
  #oo'L O      o    |
<___=E M    ^--    |  (you're barking up the wrong tree)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Greg KH
On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:

> James Bottomley wrote:
> >On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> >
> >>request_firmware() is dead also.
> >>YMMV, but three years, and there are still big chunks of binary in kernel.
> >>And please don't add new useless info _in_ it.
> >
> >
> >I er don't think so.
> >
> Hell, what can be as easy as this:
> ,-
> |modprobe $drv
> |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
> `-
> where /dev/blobs is similar to /dev/port or even /dev/null char device.
> if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,

I don't see such code in the kernel at this time.  So it's not a
solution, sorry.

greg k-h


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Oleg Verych-2
On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:

> On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
> > >>request_firmware() is dead also.
> > >>YMMV, but three years, and there are still big chunks of binary in kernel.
> > >>And please don't add new useless info _in_ it.
> > Hell, what can be as easy as this:
> > ,-
> > |modprobe $drv
> > |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
> > `-
> > where /dev/blobs is similar to /dev/port or even /dev/null char device.
> > if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,
>
> I don't see such code in the kernel at this time.  So it's not a
> solution, sorry.
>
I know. return -ENOPATCH

"No amount of clever coding can ever make up for a poor design.
Conversely, a well-architected system can tolerate a lot of sloppy
coding. In a society where organizations are increasingly filled with
more inexperienced workers whose salaries don't frag down the bottom
line, you have to expect some sloppy coding, so the design becomes
even more important."
                                   -- rbsjrx <[hidden email]>
                                   
I'm nether a CS nor software engineer, just wondering why simple thing isn't
simple _in_ the Kernel. I'm reading list "just for fun (C)" and any good word
about this (IMHO) unix-way design *may* lead professional programmers to do
tiny worthy things (think about kevent discussion).
If it's (i'm) stupid, please, say so (in the way Nicholas Miell did ;).

Thanks.

--
-o--=O`C  /. .\   (+)
 #oo'L O      o    |
<___=E M    ^--    |  (you're barking up the wrong tree)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Greg KH
On Tue, Aug 29, 2006 at 05:14:30AM +0200, Oleg Verych wrote:

> On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:
> > On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
> > > >>request_firmware() is dead also.
> > > >>YMMV, but three years, and there are still big chunks of binary in kernel.
> > > >>And please don't add new useless info _in_ it.
> > > Hell, what can be as easy as this:
> > > ,-
> > > |modprobe $drv
> > > |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
> > > `-
> > > where /dev/blobs is similar to /dev/port or even /dev/null char device.
> > > if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,
> >
> > I don't see such code in the kernel at this time.  So it's not a
> > solution, sorry.
> >
> I know. return -ENOPATCH

Yes, and that's the only way to make changes in the kernel, sorry.

> I'm nether a CS nor software engineer, just wondering why simple thing isn't
> simple _in_ the Kernel. I'm reading list "just for fun (C)" and any good word
> about this (IMHO) unix-way design *may* lead professional programmers to do
> tiny worthy things (think about kevent discussion).
> If it's (i'm) stupid, please, say so (in the way Nicholas Miell did ;).

I don't think it's workable, and goes against the current way the kernel
does things.  But please, feel free to prove me wrong with a patch
otherwise.  I don't want to debate it otherwise.

I think the current way we handle firmware works quite well, especially
given the wide range of different devices that it works for (everything
from BIOS upgrades to different wireless driver stages).

thanks,

greg k-h


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Oleg Verych-2
Greg KH wrote:

> On Tue, Aug 29, 2006 at 05:14:30AM +0200, Oleg Verych wrote:
>
>>On Mon, Aug 28, 2006 at 06:51:03PM -0700, Greg KH wrote:
>>
>>>On Tue, Aug 29, 2006 at 04:15:49AM +0200, Oleg Verych wrote:
>>>
>>>>>>request_firmware() is dead also.
>>>>>>YMMV, but three years, and there are still big chunks of binary in kernel.
>>>>>>And please don't add new useless info _in_ it.
>>>>
>>>>Hell, what can be as easy as this:
>>>>,-
>>>>|modprobe $drv
>>>>|(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
>>>>`-
>>>>where /dev/blobs is similar to /dev/port or even /dev/null char device.
>>>>if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,
>>>
...

>
>>I'm nether a CS nor software engineer, just wondering why simple thing isn't
>>simple _in_ the Kernel. I'm reading list "just for fun (C)" and any good word
>>about this (IMHO) unix-way design *may* lead professional programmers to do
>>tiny worthy things (think about kevent discussion).
>>If it's (i'm) stupid, please, say so (in the way Nicholas Miell did ;).
>
> I don't think it's workable, and goes against the current way the kernel
> does things.  But please, feel free to prove me wrong with a patch
> otherwise.  I don't want to debate it otherwise.
>
Thanks, and OK, this is my last reply on this.

> I think the current way we handle firmware works quite well, especially
> given the wide range of different devices that it works for (everything
> from BIOS upgrades to different wireless driver stages).
>
Oh, come on, even skilled developers (not particular kernel's) having
difficulties with current hotplug-sysfs-modprobe thing;
in this case one couldn't easily figure out problems and way to solve them
<http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/5444>

Goodbye.

--
-o--=O`C  /. .\   (+)
  #oo'L O      o    |
<___=E M    ^--    |  (you're barking up the wrong tree)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

David Lang-2
In reply to this post by Greg KH
On Mon, 28 Aug 2006, Greg KH wrote:

> I think the current way we handle firmware works quite well, especially
> given the wide range of different devices that it works for (everything
> from BIOS upgrades to different wireless driver stages).

the current system works for many people yes, but not everyone.

I'm still waiting to find a way to get the iw2200 working without having to use
modules.

there was a post a month or two ago from someone who had indicated they found a
way to re-initialize it after the system came up, but after someone asked for
details of how to do it there was no response.

David Lang


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Michael Buesch-2
In reply to this post by Oleg Verych-2
On Tuesday 29 August 2006 04:15, Oleg Verych wrote:

> James Bottomley wrote:
> > On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
> >
> >>request_firmware() is dead also.
> >>YMMV, but three years, and there are still big chunks of binary in kernel.
> >>And please don't add new useless info _in_ it.
> >
> >
> > I er don't think so.
> >
> Hell, what can be as easy as this:
> ,-
> |modprobe $drv
> |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
> `-
> where /dev/blobs is similar to /dev/port or even /dev/null char device.
> if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,

Please tell me how this is going to work, if we don't
know which firmware (version) is needed before be actually
initialize the device?

--
Greetings Michael.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Greg KH
In reply to this post by David Lang-2
On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:

> On Mon, 28 Aug 2006, Greg KH wrote:
>
> >I think the current way we handle firmware works quite well, especially
> >given the wide range of different devices that it works for (everything
> >from BIOS upgrades to different wireless driver stages).
>
> the current system works for many people yes, but not everyone.
>
> I'm still waiting to find a way to get the iw2200 working without having to
> use modules.

Sounds like a bug you need to pester the iw2200 developers about then.
I don't think it has much to do with the firmware subsystem though :)

thanks,

greg k-h


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Michael Buesch-2
On Tuesday 29 August 2006 20:32, Greg KH wrote:

> On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
> > On Mon, 28 Aug 2006, Greg KH wrote:
> >
> > >I think the current way we handle firmware works quite well, especially
> > >given the wide range of different devices that it works for (everything
> > >from BIOS upgrades to different wireless driver stages).
> >
> > the current system works for many people yes, but not everyone.
> >
> > I'm still waiting to find a way to get the iw2200 working without having to
> > use modules.
>
> Sounds like a bug you need to pester the iw2200 developers about then.
> I don't think it has much to do with the firmware subsystem though :)

Well, yes and no.
The ipw needs the firmware on insmod time (in contrast to bcm43xx
for example, which needs it on ifconfig up time).
So ipw needs to call request_firmware at insmod time. In case of
built-in, that is when the initcall happens. No userland is available
and request_firmware can not call the userspace helpers to upload
the firmware to sysfs.
Well, not really easy to find a sane solution for this. :)

--
Greetings Michael.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Olaf Hering-2
On Tue, Aug 29, Michael Buesch wrote:

> On Tuesday 29 August 2006 20:32, Greg KH wrote:
> > On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
> > > On Mon, 28 Aug 2006, Greg KH wrote:
> > >
> > > >I think the current way we handle firmware works quite well, especially
> > > >given the wide range of different devices that it works for (everything
> > > >from BIOS upgrades to different wireless driver stages).
> > >
> > > the current system works for many people yes, but not everyone.
> > >
> > > I'm still waiting to find a way to get the iw2200 working without having to
> > > use modules.
> >
> > Sounds like a bug you need to pester the iw2200 developers about then.
> > I don't think it has much to do with the firmware subsystem though :)
>
> Well, yes and no.
> The ipw needs the firmware on insmod time (in contrast to bcm43xx
> for example, which needs it on ifconfig up time).
> So ipw needs to call request_firmware at insmod time. In case of
> built-in, that is when the initcall happens. No userland is available
> and request_firmware can not call the userspace helpers to upload
> the firmware to sysfs.

I dont use nor do I have access ipw hardware, but:
If it is an initcall, the initramfs should be usable at that time.
A creative CONFIG_INITRAMFS_SOURCE= will help, add the firmware and a
small helper that does the cat(1).


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

David Lang-2
On Tue, 29 Aug 2006, Olaf Hering wrote:

> On Tue, Aug 29, Michael Buesch wrote:
>
>> On Tuesday 29 August 2006 20:32, Greg KH wrote:
>>> On Tue, Aug 29, 2006 at 08:46:45AM -0700, David Lang wrote:
>>>> On Mon, 28 Aug 2006, Greg KH wrote:
>>>>
>>>>> I think the current way we handle firmware works quite well, especially
>>>>> given the wide range of different devices that it works for (everything
>>>>> from BIOS upgrades to different wireless driver stages).
>>>>
>>>> the current system works for many people yes, but not everyone.
>>>>
>>>> I'm still waiting to find a way to get the iw2200 working without having to
>>>> use modules.
>>>
>>> Sounds like a bug you need to pester the iw2200 developers about then.
>>> I don't think it has much to do with the firmware subsystem though :)
>>
>> Well, yes and no.
>> The ipw needs the firmware on insmod time (in contrast to bcm43xx
>> for example, which needs it on ifconfig up time).
>> So ipw needs to call request_firmware at insmod time. In case of
>> built-in, that is when the initcall happens. No userland is available
>> and request_firmware can not call the userspace helpers to upload
>> the firmware to sysfs.
>
> I dont use nor do I have access ipw hardware, but:
> If it is an initcall, the initramfs should be usable at that time.
> A creative CONFIG_INITRAMFS_SOURCE= will help, add the firmware and a
> small helper that does the cat(1).
>

you are assuming that

1. modules are enabled and ipw2200 is compiled as a module

2. initrd or initramfs are in use

besides, several kernel versions ago this used to work. the current requirement
is a regression as far as the user is concerned.

David Lang


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Greg KH
On Tue, Aug 29, 2006 at 01:42:56PM -0700, David Lang wrote:
>
> besides, several kernel versions ago this used to work. the current
> requirement is a regression as far as the user is concerned.

Then go bug the driver authors please :)

thanks,

greg k-h


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Oleg Verych-2
In reply to this post by Michael Buesch-2

                    Due to return -ENOPATCH, don't CC lkml please.
Hallo,

On Tue, Aug 29, 2006 at 06:30:25PM +0200, Michael Buesch wrote:
 > On Tuesday 29 August 2006 04:15, Oleg Verych wrote:
 > > James Bottomley wrote:
 > > > On Tue, 2006-08-29 at 02:35 +0200, Oleg Verych wrote:
 > > >
 > > >>request_firmware() is dead also.
 > > >>YMMV, but three years, and there are still big chunks of binary in kernel.
 > > >>And please don't add new useless info _in_ it.
 > > >
 > > >
 > > > I er don't think so.
 > > >
 > > Hell, what can be as easy as this:
 > > ,-
 > > |modprobe $drv
 > > |(dd </lib/firmware/$drv.bin>/dev/blobs && echo OK) || echo Error
 > > `-
 > > where /dev/blobs is similar to /dev/port or even /dev/null char device.
 > > if synchronization is needed, add `echo $drv >/dev/blobs`, remove modprobe,
 >
 > Please tell me how this is going to work, if we don't
 > know which firmware (version) is needed before be actually
 > initialize the device?
 >
be = we, right ?

OK. I don't know who i'm going to explain my idea, programmer or user, but.
First of all two refs:

My own words: <http://permalink.gmane.org/gmane.linux.kernel/435955>
Just have read: <http://www.sabi.co.uk/Notes/linuxPragmaCoding.html>

If you see my point, i'm having (system)programmers and users(admins).
And this two completely opposite domains are meeting here, in a tiny task as
firmware uploading. Situation even harder: kernel developers mainly are not
bare-metal or firmware system programmers.

So. You are seeing chardev-like interface to kernel, and asking how this is
suppose to work ? Remember that ACPI description from mr. Linus ? Yes,

"As a someone who's spent a lot if his life doing contract/consulting
work, I've spent a lot of time breaking the bad habits of the junior
programmers assigned to work with me on various jobs. The most
valuable lesson I was ever able to teach them is that when you uncover
a problem, see if the design needs fixing before you barge in and
start trying to fix the code."
                                        -- rbsjrx <[hidden email]>

That interface is for main etab-library (external text and binary
or external tab (with LSD ;)) of all kinds of hardware config. stuff:
USB id, PCI id, CPU microcode, GPU microcode, all kinds of firmwares.
This etab-library is a simple list of

* driver-name
* acquired-ext-config

items. When driver is registered (module or in-kernel) it places an order
for etab, what it needs. Admin(user) knowing its hardware (hotplug or not)
compose a directory of etab-files with all info for every "driver-name".
Note, that linux isn't a microkernel, and adding whatever feature in
running kernel isn't possible without patch/config/make. And all this is
mostly done by distributions, isn't it ?

Thus we have all info admin wants and kernel(drivers) needs.
Bounds, sizes, lifetimes of in-kernel etabs is a set, to workout.

Unless you need all this on boot time, use chardev-like interface,
otherwise use kernel loader, by adding cpio-etab image to "initrd="
bootloader option ([1] monolithic kernel), or initramfs (initrd fs) + chardev
in case of moduled one [2], [3] usage is what you've saw in my prev. message.

Then, let me take your example:

 > The ipw needs the firmware on insmod time
[1], [2], [3]

 > (in contrast to bcm43xx for example, which needs it on ifconfig up time).
[1], [2], [3]

Handling orders, etab-library itself is an internal part, like
/dev/zero or /dev/null. Implementation seems small and obvious...

Your thoughts ?

--
-o--=O`C  /. .\   (+)
  #oo'L O      o    |
<___=E M    ^--    |  (you're barking up the wrong tree)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

Bodo Eggert-3
In reply to this post by James Bottomley
Michael Buesch <[hidden email]> wrote:

> The ipw needs the firmware on insmod time (in contrast to bcm43xx
> for example, which needs it on ifconfig up time).
> So ipw needs to call request_firmware at insmod time. In case of
> built-in, that is when the initcall happens. No userland is available
> and request_firmware can not call the userspace helpers to upload
> the firmware to sysfs.
> Well, not really easy to find a sane solution for this. :)

Can you trigger loading the firmware from userspace?
echo 1 > /sys/module/iw2200/parameters/load_firmware_now
--
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12