Thread (10 messages) 10 messages, 4 authors, 2017-10-28

Re: RTL usb adapter question

From: James Cameron <hidden>
Date: 2017-10-27 04:41:57

Interesting, thanks.  It should be a QFN 46 pin chip; you may have
counted 15 instead of 14 pins on the long edge.  Send me a photograph
of the inside, off-list?

There's a brief datasheet that I found, but no sign of firmware or
registers documentation, as usual;

http://www.cnping.com/wp-content/uploads/2015/09/RTL8188CUS_DataSheet_1.01.pdf

I've no direct experience with the rtl8188cus chip.  I can't prove it,
but my experience with other vendors suggests a small non-volatile
storage built into the chip for device configuration and firmware.
Device configuration often includes USB vendor:product.

I've read that Edimax uses rtl8188cus in a device programmed with
vendor:product 7392:7811, and the kernel handles this in

rtl8xxxu/rtl8xxxu_core.c
rtlwifi/rtl8192cu/sw.c

rtl8188cus has several configurable pins, so device configuration or
firmware would have been programmed to match the circuit layout.

As your kernel isn't providing firmware, yet the device works to an
extent, there is probably firmware already on the device.  I don't
know of a way to ask the device for a firmware version, or a firmware
dump.

You might sacrifice a sample to see if loading rtl8192cu firmware
changes behaviour at all.

You might also work with your device vendor to improve clarity.  ;-)

On Thu, Oct 26, 2017 at 08:28:00PM -0500, David Ashley wrote:
I opened up the dongle, it has these things inside (aside from 2 coils
and various resistors and capacitors)
1)
48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
REALTEK
RTL8188CUS
F6J23P2
GF27 TAIWAN

6 pin chip (3 pins,3 pins)
BZ5JA

40.0 mhz crystal oscillator

I was thinking maybe some serial eeprom would be included, but there wasn't one.

-Dave


On 10/26/17, James Cameron [off-list ref] wrote:
quoted
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:
quoted
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 [off-list ref] wrote:
quoted
On 10/25/2017 01:43 PM, David Ashley wrote:
quoted
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/
-- 
James Cameron
http://quozl.netrek.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help