Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie <mikie.pl@gmail.com>]

2007/7/6, Duncan Sands <duncan.sands@math.u-psud.fr>:
> Hi, you should keep this discussion on the lkml so it will be archived -
> that way it may help others too.

I was sure I copied lkml, but obviously something went wrong.

> On Friday 6 July 2007 19:06:14 mikie wrote:
> > 2007/7/6, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > > On Friday 6 July 2007 14:54:18 mikie wrote:
> > > > Hi,
> > > >
> > > > I experience some problems with the speedtch.c module, especially in
> > > > regards to its firmware loader.
> > > > I am not quite sure if this module is going to load the firmware
> > > > itself or does it use some external software to do that ?
> > >
> > > It loads it itself, using some external software!
> >
> > OK, so probably I don't have anything external. Could you please point
> > me to the specific helper-program takes care of this process? As I
> > understand it is not done entirely by kernel itself?
>
> The external helper is the firmware.agent script!  The modem driver calls
> the kernel's firmware subsystem, the firmware subsystem creates a user
> space thread and calls whatever program is specified in /proc/sys/kernel/hotplug
> At the same time the firmware subsystem creates the "data" and "loading" files.
> The hotplug program is supposed to write the firmware into "data".

Thanks for the explanation. Now I get the overall picture of what
whould be done to load the firmware. I will try playing around with
the firmware.agent script, although I do not havfe the entire hotplug
package on my system, but probably this should work with a bit of
manual bash scripting.

> See
> Documentation/firmware_class in the kernel source for details.  More recent
> systems fire off a "uevent" and have udev take care of loading the firmware.

What do you mean by "recent systems" ? Is it distro dependent or
kernel dependent ?

> In any case, the external helper is not specific to this modem - it is part
> of the general hotplug infrastructure.  If you have hotplug or udev installed,
> probably they are looking for the firmware in the wrong place.

Actually I don't have hotplug/udev. That is why I am thinking of some
basic manual firmware loading. I switched from 2.4.33.3 kernel, where
such toold were not needed (I guess).


> > > > All I get is :
> > > >
> > > > Jul  6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin.2.00
> > > > [...]
> > > > Jul  6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin.2
> > > > [...]
> > > > Jul  6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin
> > > >
> > > > And nothing more happens. The firmware does not get loaded to the
> > > > modem. There is also no information in the logs that the firmware
> > > > loading failed...
> > >
> > > It should either print:
> > >         no stage 1 firmware found!
> > > or
> > >         found stage 1 firmware <name>
> > > Does it really print neither?  If so, that must mean that the
> > > firmware loader got stuck.
> >
> > I don't have anything about stage 1. This probably is done by some
> > helper program, as I understood.
>
> No, the modem prints one of these two messages when the user space
> helper returns, or a timeout occurs.  The fact it isn't printed
> suggests that the timeout is infinite.  The timeout is in
> /sys/class/firmware/timeout

I will take a closer look at the timeout value. It is quite
uncomfortable for me right now to switch to the new kernel, because I
loose internet connectivity at that time :)

> > But I don't know which one is that.
> > Perhaps I could do it manually ? Like copying the firmware to the
> > "data" ?
>
> Actually you could.  All the firmware.agent does (or did, maybe it got more
> sophisticated) is use "cat" to write the firmware file to "data".

I tried some basic copy, but received permission denied even though I
was root. Perhaps I was trying at the wrong location. I'll get back
with more info on Monday.

Thanks for your help.

Regards,
MK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/