Hello all,
I came across the in-development rtl8192su source tree on github while
looking for a driver for a small Trendnet 802.11bgn device I have.
The chipset in use is an rtl8188su with usbid 0bda:8171. I was able
to compile and load the driver against a standard 3.16.1 kernel with
what looks to be a reasonably accurate capability listing for the
wireless phy along with a standard dev instance.
Whenever I attempt to enable the dev interface with an 'ifconfig wlan0
up' I get an error back indicating no such device (it does pause for a
second or two however before the error returns). I enabled the
RT_TRACE messages in the module compile as well as setting the debug
module parameter to 5 to enable all the tracing and it looks like
there are some problems happening when the driver attempts to load the
firmware into the device.
The firmware is found correctly (I created a link from the
rtl8712u.bin to rtl8192sufw.bin). This firmware is identical to the
rtl8712u-oldest-but-good.bin firmware located in the git tree. Here's
a snippet of what looks to be start of the troubles during the module
initialization.
Aug 24 19:43:02 [kernel] rtl8192s_common: Chip version 0x3
Aug 24 19:43:02 [kernel] rtl_usb: rx_max_size 9100, rx_urb_num 8, in_ep 3
Aug 24 19:43:02 [kernel] rtl8192su: Power Save off (module option)
Aug 24 19:43:02 [kernel] rtl8192su: FW Power Save off (module option)
Aug 24 19:43:02 [kernel] rtl8192su: Driver for Realtek RTL8192SU/RTL8191SU
Aug 24 19:43:02 [kernel] Loading firmware rtlwifi/rtl8192sufw.bin
Aug 24 19:43:02 [kernel] usbcore: registered new interface driver rtl8192su
Aug 24 19:43:02 [kernel] rtl8192su:rtl92su_fw_cb():<0-0> Firmware
callback routine entered!
Aug 24 19:43:02 [kernel] rtlwifi:rtl_reg_notifier():<0-0>
Aug 24 19:43:02 [kernel] ieee80211 phy0: Selected rate control
algorithm 'rtl_rc'
Aug 24 19:43:33 [kernel]
rtl8192su:_rtl92su_macconfig_before_fwdownload():<0-0> Polling
TXDMA_INIT_VALUE timeout!! Current TCR(0x0)
Aug 24 19:43:33 [kernel] rtl8192s_common:rtl92s_download_fw():<0-0>
signature:8712, version:11ec, size:30, imemsize:e808, sram size:f550
Aug 24 19:43:33 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> LoadStaus(1)
Aug 24 19:43:33 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0>
FW_STATUS_LOAD_IMEM FAIL CPU, Status=0
Aug 24 19:43:33 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> loadfw_status(1),
rtstatus(1)
Aug 24 19:43:33 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> LoadStaus(2)
Aug 24 19:43:34 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0>
FW_STATUS_LOAD_EMEM FAIL CPU, Status=0
Aug 24 19:43:34 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> loadfw_status(2),
rtstatus(1)
Aug 24 19:43:34 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> LoadStaus(3)
Aug 24 19:43:34 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> Polling DMEM code
done fail ! cpustatus(0x0)
Aug 24 19:43:34 [kernel]
rtl8192s_common:_rtl92s_firmware_checkready():<0-0> loadfw_status(3),
rtstatus(1)
Aug 24 19:43:34 [kernel]
rtl8192su:_rtl92su_macconfig_after_fwdownload():<0-0> OK
...
The trace then goes on to do a bunch of register writes to continue
initializing the device and then ends as follows:
...
Aug 24 19:43:34 [kernel] rtl8192s_common:rtl92s_phy_set_bb_reg():<0-0>
regaddr(0xc78), bitmask(0xffffffff), data(0x721f001e)
Aug 24 19:43:34 [kernel]
rtl8192s_common:rtl92s_phy_query_bb_reg():<0-0> BBR MASK=0x200
Addr[0x824]=0x0
Aug 24 19:43:34 [kernel]
rtl8192s_common:rtl92s_phy_query_bb_reg():<0-0> BBR MASK=0xf
Addr[0x804]=0x0
Aug 24 19:43:34 [kernel]
rtl8192s_common:rtl92s_phy_query_bb_reg():<0-0> BBR MASK=0xf
Addr[0xc04]=0x0
Aug 24 19:43:34 [kernel] rtl8192s_common:rtl92s_phy_bb_config():<0-0>
RF_Type(0) does not match RF_Num(0)!!
Aug 24 19:43:34 [kernel] rtl8192s_common:rtl92s_phy_bb_config():<0-0>
path1 0x0, path2 0x0, pathmap 0x0
Aug 24 19:43:34 [kernel] rtl8192su:rtl92su_hw_init():<0-0> BB Config failed
It appears that the firmware writes into the device are timing out or
failing in some fashion which leaves the device uninitialized, and
eventually returns the error. Is the rtl8188su expected to work with
the driver currently or is support there still a work in progress?
I was able to use the existing rtl8712 driver from the staging tree to
get the device working, but it uses the old wireless extensions and
doesn't appear to support a monitor mode, which was the initial goal
of getting this device working.
In summary I've got a few questions. Is this chipset expected to be
functional with the driver at this time? If so, is there anything I
can do/provide to debug further? If not I would be interested in
helping out with porting/testing/debugging to aid in getting the
chipset functional. Lastly, is monitor mode expected to work with the
driver/chipset or are there lower layer filters in place that would
keep the driver and upper layers from seeing all the frames from the
phy?
--
David Madsen
On Tue, Aug 26, 2014 at 8:19 AM, Christian Lamparter
<[email protected]> wrote:
> The rtl8192su.git comes with two sets of firmware (for two different
> driver architectures).
>
> The rtl8712u firmware is much more integrated and can performs several
> high-level procedures (high-level for firmware) like scanning, link setup
> (auth, assoc, reassoc, deassoc, deauth), link monitoring, rate control,
> crypto, erp, beacon generation, etc... with little to no help from the
> driver. This firmware is used by the (staging) rtl8712u, v2.6.6.0.20120405
> and (abandoned) r92su driver.
>
> the rtl8192su* firmware can't do any of those. The driver +
> mac80211-stack has to perform the all the necessary procedures
> (starting from the phy/rf setup). This firmware is used by rtl8192su,
> AR-7284WnAB, windows and mac osx drivers.
Thanks for the clarifications on the differing firmwares. I think
this is likely my first issue (using an incorrect firmware with
rtl8192su driver stack).
> The monitor mode of the rtl8712/r92su driver is limited by the firmware
> too. For example it is not possible to set the channel bandwidth to 40MHz.
> If that is not a problem and you don't need injection, you can try to get
> the abandoned r92su driver to work. It uses cfg80211 (not the old wireless
> extension) and has support for the monitor mode.
Thanks for the pointer to the r92su driver. I think this may address
my immediate needs (basic RX monitoring).
>> If not I would be interested in helping out with porting/testing/debugging
>> to aid in getting the chipset functional.
> That would be: figuring out why the device dies after a random amount of time.
> This could be caused by a missing watchdog check or the firmware detected a
> problem and needs a reset. I think this will probably require someone taking
> USB traffic dumps from both the mac os x or windows driver and check what they
> do differently. [Not very trivial]
If I can get the device working I should be able to get the traces
(though analyzing them is another story).
Thanks for the help.
--
David Madsen
Hello,
On Monday, August 25, 2014 06:08:14 PM David Madsen wrote:
> I came across the in-development rtl8192su source tree on github while
> looking for a driver for a small Trendnet 802.11bgn device I have.
> The chipset in use is an rtl8188su with usbid 0bda:8171. I was able
> to compile and load the driver against a standard 3.16.1 kernel with
> what looks to be a reasonably accurate capability listing for the
> wireless phy along with a standard dev instance.
The capability listings are enabled since it wouldn't be possible
to test the devices capability otherwise. Even though the caps
are present/set they are by no means implemented. [see README.md]
> The firmware is found correctly (I created a link from the
> rtl8712u.bin to rtl8192sufw.bin).
The rtl8192su.git comes with two sets of firmware (for two different
driver architectures).
The rtl8712u firmware is much more integrated and can performs several
high-level procedures (high-level for firmware) like scanning, link setup
(auth, assoc, reassoc, deassoc, deauth), link monitoring, rate control,
crypto, erp, beacon generation, etc... with little to no help from the
driver. This firmware is used by the (staging) rtl8712u, v2.6.6.0.20120405
and (abandoned) r92su driver.
the rtl8192su* firmware can't do any of those. The driver +
mac80211-stack has to perform the all the necessary procedures
(starting from the phy/rf setup). This firmware is used by rtl8192su,
AR-7284WnAB, windows and mac osx drivers.
> [...]
>
> It appears that the firmware writes into the device are timing out or
> failing in some fashion which leaves the device uninitialized, and
> eventually returns the error.
The rtl8712u firmware doesn't allow the driver to write into
the phy/bb registers in the same way the rtl8192su firmware
does (and vice versa). That said, it should be possible to
check if the firmware image is the right now. A good place to
add it would be in rtl8192su/sw.c's rtl_fw_cb(). It should be
enough to check if the first word (fw_hdr->signature) matches
0x8192 (in little endian) to determine whenever it is the
correct firmware or not.
> Is the rtl8188su expected to work with the driver currently or is
> support there still a work in progress?
No, the rtl8192su driver is not ready for anything useful. Sure, with
the correct firmware it can scan, connect, send and receive data just
fine... But only *for a random amount of time*.
The abandoned r92su driver is much better in this regard. However it
suffers from firmware problems. One big problem is that the sequence
counter is increased for every frame [tx fragmentation doesn't work
since only the fragment count should be increased in this case].
Another big issue is that the rate control algorithm falls back to
1MBit/s and stays there.
> I was able to use the existing rtl8712 driver from the staging tree
> to get the device working, but it uses the old wireless extensions and
> doesn't appear to support a monitor mode, which was the initial goal
> of getting this device working.
The monitor mode of the rtl8712/r92su driver is limited by the firmware
too. For example it is not possible to set the channel bandwidth to 40MHz.
If that is not a problem and you don't need injection, you can try to get
the abandoned r92su driver to work. It uses cfg80211 (not the old wireless
extension) and has support for the monitor mode.
> In summary I've got a few questions. Is this chipset expected to be
> functional with the driver at this time?
No.
> If not I would be interested in helping out with porting/testing/debugging
> to aid in getting the chipset functional.
That would be: figuring out why the device dies after a random amount of time.
This could be caused by a missing watchdog check or the firmware detected a
problem and needs a reset. I think this will probably require someone taking
USB traffic dumps from both the mac os x or windows driver and check what they
do differently. [Not very trivial]
[Note: rtl8192su shares a lot of code with rtl8192se (this is the pcie-version)
The pcie-version doesn't have the problem either.]
> Lastly, is monitor mode expected to work with the driver/chipset or are there
> lower layer filters in place that would keep the driver and upper layers
> from seeing all the frames from the phy?
The frame filters are fully configurable for this device in monitor mode.
For the r92su driver this is controlled by the r92su_hw_mac_set_rx_filter
function in r92su/hw.c.
Regards
Christian