Debugging RTL8192CU firmware loading on 3.12 powerpc

Debugging RTL8192CU firmware loading on 3.12 powerpc

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Arend Van Spriel]

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
> 

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Larry Finger]

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

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

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



[-- Attachment #2: rtl8192cu_fix_firmware_write.patch --]
[-- Type: text/x-patch, Size: 966 bytes --]

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;

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Sven Eckelmann]

[-- Attachment #1.1: Type: text/plain, Size: 839 bytes --]

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

[-- Attachment #1.2: 0001-rtl8192c-Fix-byteorder-of-loaded-firmware.patch --]
[-- Type: text/x-patch, Size: 1622 bytes --]

From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon, 5 Sep 2016 11:03:44 +0200
Subject: [PATCH] rtl8192c: Fix byteorder of loaded firmware

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
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
index 43fcb25..7c5fc85 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c
@@ -74,16 +74,18 @@ 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) {

[-- Attachment #1.3: 0002-Fix-TX-checksum-on-big-endian-systems.patch --]
[-- Type: text/x-patch, Size: 994 bytes --]

From: Sven Eckelmann <sven@narfation.org>
Date: Tue, 6 Sep 2016 15:00:27 +0200
Subject: [PATCH] Fix TX checksum on big endian systems
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
index 95880fe..6cb46ba 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c
@@ -481,14 +481,14 @@ static void _rtl_fill_usb_tx_desc(u8 *txdesc)
  */
 static void _rtl_tx_desc_checksum(u8 *txdesc)
 {
-	u16 *ptr = (u16 *)txdesc;
+	__le16 *ptr = (__le16 *)txdesc;
 	u16	checksum = 0;
 	u32 index;
 
 	/* Clear first */
 	SET_TX_DESC_TX_DESC_CHECKSUM(txdesc, 0);
 	for (index = 0; index < 16; index++)
-		checksum = checksum ^ (*(ptr + index));
+		checksum = checksum ^ le16_to_cpu(*(ptr + index));
 	SET_TX_DESC_TX_DESC_CHECKSUM(txdesc, checksum);
 }
 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Larry Finger]

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

Re: Debugging RTL8192CU firmware loading on 3.12 powerpc

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]