Base on your evidence, I'd say the device is different to others and has firmware included. On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote: > OK I'm completely baffled. > > I have explicitly removed all rtlwifi/ firmware files from the root > filesystem and yet the usb dongle still works, even after a power > cycle. How can it possibly be getting its firmware file???????? > > Here are the relevant kernel messages. There is no file > rtl8192cufw.bin anywhere for the kernel to find... > root@30046:~# ls -l /lib/firmware/rtlwifi/ > total 0 > > I have ensured there is no *OTHER* route to the internet such that the > driver (or udev) can magically get the firmware file from the > internet... > > Here's other info that may be useful... > > root@30046:~# zcat /proc/config.gz | grep FIRM > CONFIG_PREVENT_FIRMWARE_BUILD=y > CONFIG_FIRMWARE_IN_KERNEL=y > CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf > am335x-bone-scale-data.bin am335x-evm-scale-data.bin > am43x-evm-scale-data.bin" > CONFIG_EXTRA_FIRMWARE_DIR="firmware" > # CONFIG_LIBERTAS_THINFIRM is not set > # CONFIG_FIRMWARE_MEMMAP is not set > # CONFIG_TEST_FIRMWARE is not set > root@30046:~# cat /proc/version > Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0 > 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3 > 17:25:35 CDT 2017 > root@30046:~# lsusb > Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un > 802.11n Wireless Adapter [Realtek RTL8188CUS] > > ... ifconfig > wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c > inet addr:192.168.10.31 Bcast:192.168.10.255 Mask:255.255.255.0 > inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:509 errors:0 dropped:0 overruns:0 frame:0 > TX packets:146 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB) > > > > > [ 9.663796] rtl8192cu: Chip version 0x10 > [ 9.745394] cfg80211: Calling CRDA to update world regulatory domain > [ 9.844311] random: nonblocking pool is initialized > [ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c > [ 9.877883] rtl8192cu: Board Type 0 > [ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1 > [ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin > [ 9.878249] usb 1-1: Direct firmware load for > rtlwifi/rtl8192cufw_TMSC.bin failed with error -2 > [ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' > [ 9.890862] usbcore: registered new interface driver rtl8192cu > [ 9.897667] usb 1-1: Direct firmware load for > rtlwifi/rtl8192cufw.bin failed with error -2 > [ 9.906030] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin > [ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available > [ 11.316476] rtl8192cu: MAC auto ON okay! > [ 11.333847] rtl8192cu: Tx queue select: 0x05 > [ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 12.905367] cfg80211: Calling CRDA to update world regulatory domain > [ 13.413043] rtl8192cu: MAC auto ON okay! > [ 13.430371] rtl8192cu: Tx queue select: 0x05 > [ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 16.065356] cfg80211: Calling CRDA to update world regulatory domain > [ 19.225333] cfg80211: Calling CRDA to update world regulatory domain > [ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40 > [ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3) > [ 21.605390] wlan0: authenticated > [ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3) > [ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411 > status=0 aid=5) > [ 21.669000] wlan0: associated > [ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > [ 22.385320] cfg80211: Calling CRDA to update world regulatory domain > [ 25.545336] cfg80211: Calling CRDA to update world regulatory domain > [ 28.705312] cfg80211: Calling CRDA to update world regulatory domain > [ 31.865335] cfg80211: Calling CRDA to update world regulatory domain > [ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA > > > Thanks!!!!!! > -Dave > > On 10/25/17, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > > On 10/25/2017 01:43 PM, David Ashley wrote: > >> I'm trying to understand how the linux kernel loads RTL8188CUS firmware > >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin > >> when that file isn't available anywhere in my embedded system's > >> filesystem. > >> > >> Basically I'm trying to understand the theory. We have a product that > >> is making use of the device > >> > >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd > >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS] > >> > >> It has not been especially reliable. I've never provided firmware > >> files for the device in the root filesystem. I've started to pay > >> attention to the kernel error messages. Now the kernel drivers seem to > >> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to > >> understand if this is actually working, if it makes any difference in > >> reliability... > >> > >> It's like I can't figure out how the usb dongle even worked without > >> its firmware file... > >> > >> My working theory is that the usb dongle comes from the factory with a > >> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or > >> inferior. And the performance and reliability can be improved if the > >> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I > >> don't know if the firmware load persists across a power cycle (my > >> assumption is it doesn't). > > > > There is NO firmware coded by the factory in the device. It only has enough > > > > intelligence to load the real firmware. The exact file that it loads is > > determined by the model. If you provide the appropriate section of the > > output of > > dmesg where the above firmware messages occur, and a file listing of > > /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded. > > > > No, firmware will not persist across a power failure. > > > > The driver has never been particularly reliable, and the USB group at > > Realtek > > seems not to care. You might try their other driver, but you will be on your > > > > own, as I will not support that particular piece of ****. > > > > Please reply to all on any followups. > > > > Larry > > > > -- James Cameron http://quozl.netrek.org/
