Hi,
we are trying to integrate a RTL8192CU based WiFi adapter (TP-Link TL-WL822N)
on a PowerPC based platform running a vendor-supplied/modified 3.12 kernel
using compat-wireless (I've tried 2016-01-06 and 2016-06-20 versions). While
the adapter works fine on my Laptop (using Debian 4.6 and 4.7 kernels), it
seems the firmware loading fails on the PowerPC box. Here is some output from
the kernel log:
[ 36.945820] rtl8192cu: Chip version 0x11
[ 37.026208] rtl8192cu: MAC address: ec:08:6b:15:38:0e
[ 37.031301] rtl8192cu: Board Type 0
[ 37.035074] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 37.040911] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 37.049583] usbcore: registered new interface driver rtl8192cu
[...]
[ 221.588911] rtl8192cu:_ResetDigitalProcedure1():<0-0> #####=> 8051 reset
failed!.........................
[ 221.637599] rtl8192cu: MAC auto ON okay!
[ 221.674610] rtl8192cu: Tx queue select: 0x05
[ 233.233554] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready
fail!! REG_MCUFWDL:0x00030006 .
[ 233.233566] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not
ready to run!
The outputs at 221 starts when I enable hostapd with a minimal AP-starting
configuration.
Do you have any recommendations where the firmware loading problems could come
from, and where we could start to debug? Any pointers would be appreciated.
Thank you,
Simon
On Tuesday, September 6, 2016 8:29:32 AM CEST Larry Finger wrote:
> On 09/06/2016 08:09 AM, Sven Eckelmann wrote:
> > On Dienstag, 6. September 2016 09:40:41 CEST Sven Eckelmann wrote:
> >> On Freitag, 2. September 2016 12:53:28 CEST Larry Finger wrote:
> >> [...]
> >>
> >>> The patch I included in my previous E-mail, and attached here, does get
> >>> the firmware loaded correctly. There is still a problem that prevents
> >>> authentication. I'm still looking for that issue.
> >>
> >> Thanks for the fast update. I am currently testing your patch. It looks
> >> like the initial error is now gone. The hostapd also starts but
> >> beaconing doesn't seem to work at all (no error from the kernel/hostapd
> >> but the device is not sending anything). I am currently checking how
> >> beaconing is supposed to work in your driver. Maybe I will spot
> >> something useful.>
> > Yes, found something similar in the checksumming algorithm. See the
> > attached patch for details.
>
> Just for the record, this is not "my" driver. It was provided by Realtek. My
> contribution has only been to clean it up.
>
> Thanks for the patch. I too had found that checksum code, but I had not sent
> it as there are still problems on BE machines. These difficulties are
> running the NIC in STA mode. I have not tried AP mode. Scan data seem to be
> read OK, but it never authenticates. I do not know if there are further
> errors in setting up the transmit buffer, or if the problem is in the
> encryption/decryption code. I'm still looking.
just as a connected question here - do you know if those devices support
MultiSSID? The capabilities currently don't allow that, but I'm wondering if
that could be implemented, or if there are any hardware/firmware limitations?
Thanks,
Simon
On Freitag, 2. September 2016 12:53:28 CEST Larry Finger wrote:
[...]
> The patch I included in my previous E-mail, and attached here, does get the
> firmware loaded correctly. There is still a problem that prevents
> authentication. I'm still looking for that issue.
Thanks for the fast update. I am currently testing your patch. It looks like
the initial error is now gone. The hostapd also starts but beaconing doesn't
seem to work at all (no error from the kernel/hostapd but the device is not
sending anything). I am currently checking how beaconing is supposed to work
in your driver. Maybe I will spot something useful.
Kind regards,
Sven
On 2-9-2016 10:50, Simon Wunderlich wrote:
> Hi,
>
> we are trying to integrate a RTL8192CU based WiFi adapter (TP-Link TL-WL822N)
> on a PowerPC based platform running a vendor-supplied/modified 3.12 kernel
> using compat-wireless (I've tried 2016-01-06 and 2016-06-20 versions). While
> the adapter works fine on my Laptop (using Debian 4.6 and 4.7 kernels), it
> seems the firmware loading fails on the PowerPC box. Here is some output from
> the kernel log:
>
> [ 36.945820] rtl8192cu: Chip version 0x11
> [ 37.026208] rtl8192cu: MAC address: ec:08:6b:15:38:0e
> [ 37.031301] rtl8192cu: Board Type 0
> [ 37.035074] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [ 37.040911] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [ 37.049583] usbcore: registered new interface driver rtl8192cu
> [...]
> [ 221.588911] rtl8192cu:_ResetDigitalProcedure1():<0-0> #####=> 8051 reset
> failed!.........................
> [ 221.637599] rtl8192cu: MAC auto ON okay!
> [ 221.674610] rtl8192cu: Tx queue select: 0x05
> [ 233.233554] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready
> fail!! REG_MCUFWDL:0x00030006 .
> [ 233.233566] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not
> ready to run!
>
> The outputs at 221 starts when I enable hostapd with a minimal AP-starting
> configuration.
>
> Do you have any recommendations where the firmware loading problems could come
> from, and where we could start to debug? Any pointers would be appreciated.
Hi Simon,
Could it be an endian issue?
Regards,
Arend
> Thank you,
> Simon
>
On Freitag, 2. September 2016 13:13:20 CEST Arend Van Spriel wrote:
[...]
> > Do you have any recommendations where the firmware loading problems could
> > come from, and where we could start to debug? Any pointers would be
> > appreciated.
> Hi Simon,
>
> Could it be an endian issue?
Yes, it could be one (at least I've also guessed this - I could still be
completely wrong). But the problem is now to find a good starting point for
the debugging effort.
I've only looked at Simon's screen once while he gather USB dumps but didn't
spot any obvious at that time. There was also the problem that the comparison
dump looked already a lot different due to some timing differences.
I think Simon can give you later more details (when required).
Kind regards,
Sven
On 09/02/2016 03:50 AM, Simon Wunderlich wrote:
> Hi,
>
> we are trying to integrate a RTL8192CU based WiFi adapter (TP-Link TL-WL822N)
> on a PowerPC based platform running a vendor-supplied/modified 3.12 kernel
> using compat-wireless (I've tried 2016-01-06 and 2016-06-20 versions). While
> the adapter works fine on my Laptop (using Debian 4.6 and 4.7 kernels), it
> seems the firmware loading fails on the PowerPC box. Here is some output from
> the kernel log:
>
> [ 36.945820] rtl8192cu: Chip version 0x11
> [ 37.026208] rtl8192cu: MAC address: ec:08:6b:15:38:0e
> [ 37.031301] rtl8192cu: Board Type 0
> [ 37.035074] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [ 37.040911] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [ 37.049583] usbcore: registered new interface driver rtl8192cu
> [...]
> [ 221.588911] rtl8192cu:_ResetDigitalProcedure1():<0-0> #####=> 8051 reset
> failed!.........................
> [ 221.637599] rtl8192cu: MAC auto ON okay!
> [ 221.674610] rtl8192cu: Tx queue select: 0x05
> [ 233.233554] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready
> fail!! REG_MCUFWDL:0x00030006 .
> [ 233.233566] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not
> ready to run!
>
> The outputs at 221 starts when I enable hostapd with a minimal AP-starting
> configuration.
>
> Do you have any recommendations where the firmware loading problems could come
> from, and where we could start to debug? Any pointers would be appreciated.
Simon,
The patch I included in my previous E-mail, and attached here, does get the
firmware loaded correctly. There is still a problem that prevents
authentication. I'm still looking for that issue.
Larry
On Dienstag, 6. September 2016 09:40:41 CEST Sven Eckelmann wrote:
> On Freitag, 2. September 2016 12:53:28 CEST Larry Finger wrote:
> [...]
>
> > The patch I included in my previous E-mail, and attached here, does get
> > the firmware loaded correctly. There is still a problem that prevents
> > authentication. I'm still looking for that issue.
>
> Thanks for the fast update. I am currently testing your patch. It looks like
> the initial error is now gone. The hostapd also starts but beaconing
> doesn't seem to work at all (no error from the kernel/hostapd but the
> device is not sending anything). I am currently checking how beaconing is
> supposed to work in your driver. Maybe I will spot something useful.
Yes, found something similar in the checksumming algorithm. See the attached
patch for details.
Kind regards,
Sven
On 09/06/2016 08:09 AM, Sven Eckelmann wrote:
> On Dienstag, 6. September 2016 09:40:41 CEST Sven Eckelmann wrote:
>> On Freitag, 2. September 2016 12:53:28 CEST Larry Finger wrote:
>> [...]
>>
>>> The patch I included in my previous E-mail, and attached here, does get
>>> the firmware loaded correctly. There is still a problem that prevents
>>> authentication. I'm still looking for that issue.
>>
>> Thanks for the fast update. I am currently testing your patch. It looks like
>> the initial error is now gone. The hostapd also starts but beaconing
>> doesn't seem to work at all (no error from the kernel/hostapd but the
>> device is not sending anything). I am currently checking how beaconing is
>> supposed to work in your driver. Maybe I will spot something useful.
>
> Yes, found something similar in the checksumming algorithm. See the attached
> patch for details.
Just for the record, this is not "my" driver. It was provided by Realtek. My
contribution has only been to clean it up.
Thanks for the patch. I too had found that checksum code, but I had not sent it
as there are still problems on BE machines. These difficulties are running the
NIC in STA mode. I have not tried AP mode. Scan data seem to be read OK, but it
never authenticates. I do not know if there are further errors in setting up the
transmit buffer, or if the problem is in the encryption/decryption code. I'm
still looking.
Larry
On 09/02/2016 06:26 AM, Sven Eckelmann wrote:
> On Freitag, 2. September 2016 13:13:20 CEST Arend Van Spriel wrote:
> [...]
>>> Do you have any recommendations where the firmware loading problems could
>>> come from, and where we could start to debug? Any pointers would be
>>> appreciated.
>> Hi Simon,
>>
>> Could it be an endian issue?
>
> Yes, it could be one (at least I've also guessed this - I could still be
> completely wrong). But the problem is now to find a good starting point for
> the debugging effort.
>
> I've only looked at Simon's screen once while he gather USB dumps but didn't
> spot any obvious at that time. There was also the problem that the comparison
> dump looked already a lot different due to some timing differences.
>
> I think Simon can give you later more details (when required).
Simon,
Yes, it is an endian issue. I can see part of the problem, but I do not have a
fix yet.
The firmware is read in as an array of bytes, thus it is effectively in
little-endian order. When it is written back to the device in routine
_rtl92c_fw_block_write(), the data output uses 32-bit writes. Of course, all
data supplied in all 2- and 4-byte writes is assumed to be in CPU order. As the
device needs the data to be little-endian, it will be byte swapped on BE
machines. As a result, the firmware is written out in the wrong byte order. I
think that this problem should be fixed with:
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
index 43fcb25..cd7ae70 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -74,18 +74,19 @@ static void _rtl92c_fw_block_write(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
u32 blocksize = sizeof(u32);
u8 *bufferptr = (u8 *)buffer;
- u32 *pu4byteptr = (u32 *)buffer;
+ __le32 *pu4byteptr = (__le32 *)buffer;
u32 i, offset, blockcount, remainsize;
+ u32 data;
blockcount = size / blocksize;
remainsize = size % blocksize;
for (i = 0; i < blockcount; i++) {
offset = i * blocksize;
+ data = le32_to_cpu(*(pu4byteptr + i));
rtl_write_dword(rtlpriv, (FW_8192C_START_ADDRESS + offset),
- *(pu4byteptr + i));
+ data);
}
-
if (remainsize) {
offset = blockcount * blocksize;
bufferptr += offset;
Unfortunately, applying the patch results in a checksum error on my PPC.
I'll let you know what I find.
Larry