On an x86 Ubuntu machine, I have built ath9k_htc and successfully
gotten an AR9280 card up with the htc_7010.fw firmware file. Now,
what I am attempting to do is move the working build to an Android
device. I have successfully cross-compiled ath9k_htc against my
Android kernel, and I am able to successfully install and load the
ath9k_htc module and related modules on the Android device. Simply, I
cross-compile and then package the kernel modules with my Android
kernel. I carry nothing else over.
However, I am hitting a barrier when trying to load the firmware.
Whenever I insert the Atheros USB module, I get the error:
<3>[ 4010.997375] usb 3-1.4: ath9k_htc: Firmware - htc_7010.fw not found
I placed htc_7010.fw in /lib/firmware on my Android device, which is
the location it was on my Ubuntu machine. However, I still get this
error.
So then I built zd1211rw from the Android kernel source (included in
the kernel source tree), and after doing so I found that /etc/firmware
was the location the in-kernel zd1211rw driver was looking for the
firmware. By placing zd1201.fw in /etc/firmware, I was able to bring
that card up on the Android device.
Then I tried putting htc_7010.fw in /etc/firmware on the Android
device (same place zd1201.fw worked for the kernel source tree
driver), and I still get the same error that it cannot be found. But,
the ath9k_htc driver is from compat-wireless, cross-compiled against
my kernel. Not built from the kernel tree source like zd1211rw was.
I have tried various other locations: /lib/firmware, /etc/firmware,
/system/lib/modules, /system/lib/firmware, /system/etc ... everything
gives me the same error.
Looking at my Android kernel Makefile, I find:
# ---------------------------------------------------------------------------
# Firmware install
INSTALL_FW_PATH=$(INSTALL_MOD_PATH)/lib/firmware
export INSTALL_FW_PATH
PHONY += firmware_install
firmware_install: FORCE
@mkdir -p $(objtree)/firmware
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
#---------------------
This suggests that the kernel is placing (and therefore looking?) for
firmware in /lib/firmware since $(INSTALL_MOD_PATH) defaults to "/"
So, I'm a little confused why it is not finding the firmware. Does
anyone have any insight on this?
Thanks!
George
On Mon, May 16, 2011 at 2:09 PM, George Nychis <[email protected]> wrote:
>> compat-wireless uses a new module called compat_firmware so you need a
>> respective new udev rule for it, it uses the same path for firmware
>> though so you just need to slap on the right udev rule.
>>
>
> Thanks for the response, Luis!
>
> I'm not a udev expert, and my problem might be slightly
> Android-dependent, so feel free to punt the conversation at any point.
>
> I've tried setting up a set of rules on my Android device to handle
> this situation. There was no /etc/udev or anything related, before I
> created them. I created a udev.conf and a default set of rules, and
> then migrated the compat_firmware rules on over. But, udev seems to
> be ignoring everything.
>
> Unfortunately, there's not a lot documented in terms of udev on
> Android. I did manage to find a little bit of information on a page
> that's actually about root exploits on Android:
> http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/
>
> Apparently one of them is a udev exploit, and the author mentions that:
> "Android does not have a separate udev executable and process link
> [like] on standard Linux deployments. However, large portions of the
> udev code have been moved into the init daemon."
>
> I'm not sure if this customization of udev or migration of it into the
> init daemon is affecting anything here.
>
> Is there any simple backwards compatible way of bypassing
> compat_firmware? If not, I will dig up some of the older
> compat-wireless code to try and remedy the problem and get around
> compat_firmware.
If android hacked udev into the init deamon then you will have to
modify the init daemon too but I doubt that they would have kept udev
rules statically in the init daemon, so try to find the udev rules.
Luis
> compat-wireless uses a new module called compat_firmware so you need a
> respective new udev rule for it, it uses the same path for firmware
> though so you just need to slap on the right udev rule.
>
Thanks for the response, Luis!
I'm not a udev expert, and my problem might be slightly
Android-dependent, so feel free to punt the conversation at any point.
I've tried setting up a set of rules on my Android device to handle
this situation. There was no /etc/udev or anything related, before I
created them. I created a udev.conf and a default set of rules, and
then migrated the compat_firmware rules on over. But, udev seems to
be ignoring everything.
Unfortunately, there's not a lot documented in terms of udev on
Android. I did manage to find a little bit of information on a page
that's actually about root exploits on Android:
http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/
Apparently one of them is a udev exploit, and the author mentions that:
"Android does not have a separate udev executable and process link
[like] on standard Linux deployments. However, large portions of the
udev code have been moved into the init daemon."
I'm not sure if this customization of udev or migration of it into the
init daemon is affecting anything here.
Is there any simple backwards compatible way of bypassing
compat_firmware? If not, I will dig up some of the older
compat-wireless code to try and remedy the problem and get around
compat_firmware.
Thanks again
> If android hacked udev into the init deamon then you will have to
> modify the init daemon too but I doubt that they would have kept udev
> rules statically in the init daemon, so try to find the udev rules.
>
I haven't been able to find any other udev rules on the Android
filesystem. I have done a ton of digging for any udev information on
Android, without any luck. I have asked on the Android mailing list,
we'll see how that goes.
In the mean time, the compat_firmware.sh script is pretty straight
forward. My process on Android is continually monitoring the USB
devices connected, I could perform the same actions that
compat_firmware.sh does to dump the firmware into "/data"
Thanks for the udev related pointers in compat-wireless!
On Mon, May 16, 2011 at 12:41 PM, George Nychis <[email protected]> wrote:
> So, I'm a little confused why it is not finding the firmware. Does
> anyone have any insight on this?
compat-wireless uses a new module called compat_firmware so you need a
respective new udev rule for it, it uses the same path for firmware
though so you just need to slap on the right udev rule.
Luis
George Nychis <gnychis@...> writes:
>
> > If android hacked udev into the init deamon then you will have to
> > modify the init daemon too but I doubt that they would have kept udev
> > rules statically in the init daemon, so try to find the udev rules.
> >
>
> I haven't been able to find any other udev rules on the Android
> filesystem. I have done a ton of digging for any udev information on
> Android, without any luck. I have asked on the Android mailing list,
> we'll see how that goes.
>
> In the mean time, the compat_firmware.sh script is pretty straight
> forward. My process on Android is continually monitoring the USB
> devices connected, I could perform the same actions that
> compat_firmware.sh does to dump the firmware into "/data"
>
> Thanks for the udev related pointers in compat-wireless!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
I'm having a similar problem with another USB driver to a chipset that requires
firmware. I have managed to compiler the driver using the compat-wireless method
for the device but can not figure out where to put the firmware. George from the
last post it seems you have a work around. Could you elaborate, give more
details? ...dump firmware into "/data". Thanks