Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: caracalla on July 04, 2018, 12:27:32 AM
-
I experienced the same issue with my WiFi USB dongle as observed by the fellow member coreplayer2 (http://forum.tinycorelinux.net/index.php/topic,20891.msg130518.html#msg130518). Back then this issue was marked as solved because this is error message is supposed to be normal since WiFi should be working anyway. I strongly disagree with this statement, because any error reported by the system is there for a reason.
Tiny Core Linux comes with a set of extension packages containing various firmware images covering different hardware/chipset manufacturers.
In my case following firmware extension packages are loaded on system boot
firmware-atheros.tcz
firmware-broadcom_bcm43xx.tcz
firmware-broadcom_bnx2.tcz
firmware-broadcom_bnx2x.tcz
firmware-chelsio.tcz
firmware-getB43.tcz
firmware-intel_e100.tcz
firmware-ipw2100.tcz
firmware-ipw2200.tcz
firmware-iwimax.tcz
firmware-iwl8000.tcz
firmware-iwl9000.tcz
firmware-iwlwifi.tcz
firmware-marvel.tcz
firmware-myri10ge.tcz
firmware-netxen.tcz
firmware-openfwwf.tcz
firmware-ralinkwifi.tcz
firmware-rtl8192ce_se_de.tcz
firmware-rtl_nic.tcz
firmware-rtlwifi.tcz
firmware-ti-connectivity.tcz
firmware-tigon.tcz
firmware-ueagle-atm.tcz
firmware-vxge.tcz
firmware-zd1211.tcz
From what I see, firmware images will show up in the /usr/local/lib/firmware folder. The issue here is that whenever I insert my WiFi USB dongle to the USB port I will get an error indicating that firmware image for my WiFi USB dongle failed to load. After some experimentation I was able to figure out that system is expecting to find firmware images in the /lib/firmware folder and not in the location specified by the firmware extension packages. If I create a symlink in the /usr/lib folder to point to the firmware folder located in /usr/local/lib, then firmware image for my WiFi USB dongle is loaded without an error.
$ dmesg
...
usb 1-6: new high-speed USB device number 2 using xhci_hcd
rtl8192cu: Chip version 0x10
rtl8192cu: Board Type 0
rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
usb 1-6: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
usb 1-6: Falling back to user helper
...
$ sudo ln -s /usr/local/lib/firmware /lib/firmware
$ dmesg
...
usb 1-6: new high-speed USB device number 4 using xhci_hcd
rtl8192cu: Chip version 0x10
rtl8192cu: Board Type 0
rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
...
My question here is what should be done? Should all firmware extension packages be repackaged to have firmware images located in the /lib/firmware folder? Maybe there is a configuration option for Linux kernel to specify a different location for firmware images?
Any feedback is much appreciated. Thanks!
-
From what I was able to figure out, it seems that udev is responsible for figuring out the location of firmware images directory. More details are available in the /etc/udev/rules.d/50-firmware.rules which actually calls /lib/udev/firmware.sh script.
$ cat /etc/udev/rules.d/50-firmware.rules
# do not edit this file, it will be overwritten on update
# firmware-class requests, copies files into the kernel
#SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"
$ cat /lib/udev/firmware.sh
#!/bin/sh -e
FIRMWARE_DIRS="/lib/firmware /usr/local/lib/firmware"
err() {
echo "$@" >&2
if [ -x /usr/bin/logger ]; then
/usr/bin/logger -t "${0##*/}[$$]" "$@"
fi
}
if [ ! -e /sys$DEVPATH/loading ]; then
err "udev firmware loader misses sysfs directory"
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
echo -1 > /sys$DEVPATH/loading
err "Cannot find firmware file '$FIRMWARE'"
exit 1
From what I see both locations, /lib/firmware and /usr/local/lib/firmware should be covered.
-
Indeed, the kernel message is because the kernel only looks in /lib, and when not found there, it calls firmware.sh (the mentioned usermode helper), which searches /usr/local too. The speed difference is on the order of microseconds.
-
It's normal for the firmware load to fail once brefore suceeding:
iwlwifi 0000:02:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2
iwlwifi 0000:02:00.0: Falling back to user helper
iwlwifi 0000:02:00.0: loaded firmware version 17.459231.0 op_mode iwlmvm
..in the case of my intel hardware, the firmware is loaded from /usr/local/lib/firmware.
I'm not sure why you load so many firmware extensions - maybe you could load just the one you need and try again?
Failing that, you could always make your own personal extension with the firmware in /lib/firmware.
-
I am loading so many firmware extensions because I would like to have a system which covers as many WiFi USB dongles as possible. This way I will be able to test all WiFi USB dongles I have on stack.
Most likely I will prepare a corepure64 image containing firmware image files which will be located in the /lib/firmware folder.
-
...
Tiny Core Linux comes with a set of extension packages containing various firmware images covering different hardware/chipset manufacturers.
In my case following firmware extension packages are loaded on system boot
firmware-atheros.tcz
firmware-broadcom_bcm43xx.tcz
firmware-broadcom_bnx2.tcz
firmware-broadcom_bnx2x.tcz
firmware-chelsio.tcz
firmware-getB43.tcz
firmware-intel_e100.tcz
firmware-ipw2100.tcz
firmware-ipw2200.tcz
firmware-iwimax.tcz
firmware-iwl8000.tcz
firmware-iwl9000.tcz
firmware-iwlwifi.tcz
firmware-marvel.tcz
firmware-myri10ge.tcz
firmware-netxen.tcz
firmware-openfwwf.tcz
firmware-ralinkwifi.tcz
firmware-rtl8192ce_se_de.tcz
firmware-rtl_nic.tcz
firmware-rtlwifi.tcz
firmware-ti-connectivity.tcz
firmware-tigon.tcz
firmware-ueagle-atm.tcz
firmware-vxge.tcz
firmware-zd1211.tcz
[/code]
I am loading so many firmware extensions because I would like to have a system which covers as many WiFi USB dongles as possible. This way I will be able to test all WiFi USB dongles I have on stack.
Hello caracalla,
I couldn't help notice that many of the firmware extensions you're loading don't contain WiFi firmware. For example the list contains firmware for Gigabit Ethernet PCIe cards and modems, like:
firmware-myri10ge.tcz
firmware-netxen.tcz
firmware-rtl_nic.tcz
firmware-tigon.tcz
firmware-ueagle-atm.tcz
etc, etc.
Additionally, broadcomm firmware and openfwwf firmware extensions will likely cause conflict if run together, it's a case of either or.. while none are up to date. Besides none of the previously mentioned Broadcomm extensions are required if instead you run firmware-getB43 which downloads latest Broadcomm proprietary firmware blobs and creates a local broadcomm firmware extension as per the license.
Also, "iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-17.ucode failed with error -2" is not an error, it's merely an advisory notice.
You'll notice that all drivers and firmware are correctly installed into the /usr file structure
regards
-
You've already had the answer but I thought I'd add to the discussion as I've just been through a similar experience with Realtek NIC.
Although it was working OK I did notice in the system log:
r8169 0000:04:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
r8169 0000:04:00.0: Falling back to user helper
r8169 0000:04:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-11)
r8169 0000:04:00.0 eth0: link down
Next step was to load the extension firmware-rtl_nic.tcz. I then got:
r8169 0000:04:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
r8169 0000:04:00.0: Falling back to user helper
r8169 0000:04:00.0 eth0: link down
For a while I was focused on the headline failed line and failed(!) to notice that the unable to load error message two lines below had gone. From a human factors point of view, having started off with failed you'd expect a success if that failure subsequently got reversed.
The driver itself has a first go at /lib/firmware after which (if it failed) it hands the problem on to udev. udev uses /lib/udev/firmware.sh to do the job. This helper searches /lib/firmware and then /usr/local/lib/firmware.
BTW: If anyone has an RTL8168 driver that will let me use ethtool to read/write the eeprom attached to the NIC I'd appreciate it. (I get 'Operation not supported' from the current r8169 driver)