failed to download firmware using rtw_8822cu on 8811cu #11

caydenm · 2020-10-05T05:10:31Z

Firstly thank you for putting together this set of drivers, nothing else I have found comes close to working!

I managed to compile these for openwrt master snapshot build (happy to share hacky package file).

However I have ran into a problem where I get failed to download firmware on both of my test devices (Simplecom NW602, 8811cu based devices with usb ids of 0bda:c811). I tried newer firmware from the debian repo as well (I noticed the existing firmware in the fw directory had a version mismatch between wow and non-wow firmware). I also tested the device on windows and it works perfectly fine.

I was using your 8822cu dev branch.

Once I plug in the device I get:
rtw_8822cu 1-1.3:1.0: USB:2
rtw_8822cu 1-1.3:1.0: Firmware version 9.9.0, H2C version 15
rtw_8822cu 1-1.3:1.0: Firmware version 9.9.0, H2C version 15
rtw_8822cu 1-1.3:1.0: failed to download firmware
rtw_8822cu 1-1.3:1.0: failed to setup chip efuse info
rtw_8822cu 1-1.3:1.0: failed to setup chip information

Steps to setup:
modprobe mac80211
modprobe rtw88_8822cu
plug in usb

Any help would be much appreciated

caydenm · 2020-10-06T09:28:50Z

It appears that I was getting a firmware validation error, this was due to it loading rtw8822c_fw.bin for a 8811cu chip which should use rtw8821c_fw.bin if I understand correctly.Digging through the code a little more I see there are what appears to be the beginings of modules for rtw8821c.

I copied the rtw8822cu and configured it work for the rtw8821cu (changed usb ids in both, changed 8821 to 8822 and added to the makefile). After compiling this I got a kernel panic with the following call stack.

Call stack
rtw_usb_probe
rtw_fw_write_data_rsvd_page
rtw_set_channel_mac
rtw_download_firmware
rtw_chip_info_setup
rtw_usb_probe
rtw_usb_probe_interface
really_probe
driver_probe_device
device_driver_attach
....
init_module (rtw88_8821cu)
Code: bad PC value

caydenm · 2020-10-08T10:10:08Z

At this point I am not sure how to proceed to enable 8811cu. Pointers or advice would be really appreciated

It appears there is an issue that causes the kernel to be "Unable to handle kernel access to user memory outside uaccess routines at virtual address 000000000000008".

I assume that there are modifications to 8821c.c that needs to be made similar to those in 8822c.c to support USB better, however as of current apart from efuse parsing (which the efuses appear from other drives to have the same mapping between 8821ce and 8821cu) I cannot see any that need to be made.

Below are my 8821cu.c and 8821cu.h files. I removed the USB ids from the 8822.c file to ensure both weren't loaded.

// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/* Copyright(c) 2018-2019  Realtek Corporation
 */

#include <linux/module.h>
#include <linux/usb.h>
#include "rtw8822cu.h"

static const struct usb_device_id rtw_8822cu_id_table[] = {
	{ USB_DEVICE_AND_INTERFACE_INFO(RTW_USB_VENDOR_ID_REALTEK,
					RTW_USB_PRODUCT_ID_REALTEK_8822C,
					0xff, 0xff, 0xff),
	  .driver_info = (kernel_ulong_t)&(rtw8822c_hw_spec) },
	{ USB_DEVICE_AND_INTERFACE_INFO(RTW_USB_VENDOR_ID_REALTEK,
					RTW_USB_PRODUCT_ID_REALTEK_8812C,
					0xff, 0xff, 0xff),
	  .driver_info = (kernel_ulong_t)&(rtw8822c_hw_spec) },
	/*=== Customer ID ===*/
	{ USB_DEVICE(0x0bda, 0x2006),
	  .driver_info = (kernel_ulong_t)&(rtw8822c_hw_spec) }, /* Totolink */


	{},
};
MODULE_DEVICE_TABLE(usb, rtw_8822cu_id_table);

static struct usb_driver rtw_8822cu_driver = {
	.name = "rtw_8822cu",
	.id_table = rtw_8822cu_id_table,
	.probe = rtw_usb_probe,
	.disconnect = rtw_usb_disconnect,
};
module_usb_driver(rtw_8822cu_driver);

MODULE_AUTHOR("Realtek Corporation");
MODULE_DESCRIPTION("Realtek 802.11ac wireless 8822cu driver");
MODULE_LICENSE("Dual BSD/GPL");

/* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */
/* Copyright(c) 2018-2019  Realtek Corporation
 */

#ifndef __RTW_8822CU_H_
#define __RTW_8822CU_H_

/* USB Vendor/Product IDs */
#define RTW_USB_VENDOR_ID_REALTEK		0x0BDA
#define RTW_USB_PRODUCT_ID_REALTEK_8812C	0xC812
#define RTW_USB_PRODUCT_ID_REALTEK_8822C	0xC82C

extern const struct dev_pm_ops rtw_pm_ops;
extern struct rtw_chip_info rtw8822c_hw_spec;
int rtw_usb_probe(struct usb_interface *intf, const struct usb_device_id *id);
void rtw_usb_disconnect(struct usb_interface *intf);

#endif

ulli-kroll · 2020-10-08T14:50:44Z

Can use please say which branch you are using
I assume development/chipset/rtl8822cu

Also I assume from the chipname 8811cu this devices
has no bluetooth support ??
And is a 1T1R device, aka one antenna

I might be possible, there is some error in the bluetooth handling.
I've discovered this while working on some chip(s) which are
currently not supported here. don't ask here.

try attached patch.
which is from my no-bluetooth branch, to work on some (currently)
not supported devidces

Note
This is only the basic remove code.
If the device fails sometimes after firmware load, there is more involved

From 27406923600a42839c13b276e8bdaef72fc9568a Mon Sep 17 00:00:00 2001
From: Hans Ulli Kroll <[email protected]>
Date: Thu, 8 Oct 2020 16:40:43 +0200
Subject: [PATCH] rtw8821:partially disable bluetooth support

new rtw8811cu device might have no hardware bluetooth
support, so firmware load fails while accessing these
registers

Signed-off-by: Hans Ulli Kroll <[email protected]>
---
 mac.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/mac.c b/mac.c
index 2ca2b2b948a4..e97e400cf0f2 100644
--- a/mac.c
+++ b/mac.c
@@ -706,15 +706,11 @@ static int __rtw_download_firmware(struct rtw_dev *rtwdev,
 	struct rtw_backup_info bckp[DLFW_RESTORE_REG_NUM];
 	const u8 *data = fw->firmware->data;
 	u32 size = fw->firmware->size;
-	u32 ltecoex_bckp;
 	int ret;
 
 	if (!check_firmware_size(data, size))
 		return -EINVAL;
 
-	if (!ltecoex_read_reg(rtwdev, 0x38, &ltecoex_bckp))
-		return -EBUSY;
-
 	wlan_cpu_enable(rtwdev, false);
 
 	download_firmware_reg_backup(rtwdev, bckp);
@@ -730,9 +726,6 @@ static int __rtw_download_firmware(struct rtw_dev *rtwdev,
 
 	wlan_cpu_enable(rtwdev, true);
 
-	if (!ltecoex_reg_write(rtwdev, 0x38, ltecoex_bckp))
-		return -EBUSY;
-
 	ret = download_firmware_validate(rtwdev);
 	if (ret)
 		goto dlfw_fail;
-- 
2.25.3

caydenm · 2020-10-09T07:38:54Z

Thank you for the reply and the patch!

I am indeed using the development/chipset/rtl8822cu branch and a rtl8811cu, no BT and I believe single antenna. The specific model is a simplecomm nw602.

The patch got me a little further into the boot process. I see it init core and printing the firmware version info.I am now kenel panicing on rtw_usb_write_data with what appears to be a NPE. "Unable to handle kernel execution of user memory at virtual address"

Specifically it seems to be failing on rtw_tx_fill_txdesc_checksum(rtwdev, pkt_info, skb->data);

This line "chip->ops->fill_txdesc_checksum(rtwdev, pkt_info, txdesc);" in rtw_tx_fill_txdesc_checksum fails because there is no function for this in 8821c.c

I commented it out, but I now get error beacon valid. More digging required.

caydenm · 2020-10-09T08:59:24Z

I implemented rtw_tx_filldesc_checksum for 8821c. I have now made it even further through the boot process.

I now get an error rfe 34 isn't supported.

caydenm · 2020-10-09T09:56:55Z

More progress. I added 34 rfe's that are all the same for 8821c and this seemed to correctly load the firmware and get me to a new and exciting error "wiphy should have REGULATORY_CUSTOM_REG".

I am going to take another pass tomorrow and see if I can figure out what I need to do to get this working and why this would be any different for 8821c compared to 8822c.

caydenm · 2020-10-10T01:17:16Z

Using https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtw88/regd.c for rtw_regd_init_wiphy and rtw_regd_init seemed to fix the issue above.

I now have wiphy_register failing with warning on core.c:872.
Call trace:
wiphy_register [cfg80211]
iee80211_register_hw [mac80211]
rtw_register_hw [rtw88_core]
rtw_usbprobe [rtw88_core]
...

in cfg80211 core.c that seems to be either failing on !have_band or validating policy for vendor commands.

I am assuming that this is likely due to the contents of wiphy config passed across rather than a bug in cfg80211 itself. I am not sure how bands would fail from my reading of the code, but I could also be missing something or not seeing something else that is failing.

caydenm · 2020-10-11T01:52:32Z

After adding some more logging to cfg80211 it is failing on !have_band where it belives wiphy has nothing for bands 0-3.

caydenm · 2020-10-11T08:13:35Z

I got this to successfully load and show up in iw dev. It seems that openwrts backported mac80211 and cfg80211 wasn't linked in correctly in my make file.

Scan and AP mode don't seem to work currently, but I will share back a patch if/when I get that working

ulli-kroll · 2020-10-11T12:13:19Z

Ok

on my next round I will add rtw_tx_filldesc_checksum for
development/chipset/rtl8821cu
also I add your
usb ids of 0bda:c811
and check for RFE 34

this will hopefully merged with some other debug Info and other branches into master
/me has some "broken" rtl8822bu device with a not proper filled eeprom

caydenm · 2020-10-13T09:33:06Z

The device seems to not be responding to commands. When trying to use it with openwrt I get these errors. There are no errors in dmesg from the device initializing.

hostapd: nl80211 driver initalization failed.
hostapd: wlan2: CTRL-EVENT-TERMINATING
hostapd_free_hapd_data: interface wlan2 wasn't started
netifd: radio2: RTNETLINK answers: Address not available

The devices show up in iw and I have attached a dump of that information.

I have also attached my 8821cu.c, 8821cu.h and 8821c.c files as you may want to patch mine rather than write your own (happy to send a pr if you would prefer).
iw output rtl8811cu.txt
rtw8821c.zip

Thanks for your continued help. Hopefully my investigation is somewhat helpful to you and others.

ulli-kroll · 2020-10-13T18:40:27Z

Grummel ....

I messed up
development/chipset/rtl8822cu
royalty with USB iD's from rtl8821cu chips
because I've seen your undefined mac address ...
you missed the other layout for USB efuses.
I've taken the layout from my rtl8821au chipset branch, don't ask !

from my new
development/chipset/rtl8821cu
branch

from one of my test boxes running latest kernel

[   72.022009] rtw88_core: loading out-of-tree module taints kernel.
[   83.885877] rtw_8821cu 1-1.4:1.2: USB: 2
[   83.890503] rtw_8821cu 1-1.4:1.2: Firmware version 24.5.0, H2C version 12
[   84.302192] rtw_8821cu 1-1.4:1.2: rfe 255 isn't supported
[   84.316052] rtw_8821cu 1-1.4:1.2: failed to setup chip efuse info
[   84.322148] rtw_8821cu 1-1.4:1.2: failed to setup chip information
[   84.329194] rtw_8821cu 1-5.1.2:1.0: USB: 2
[   84.334021] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
[   84.771503] usbcore: registered new interface driver rtw_8821cu

Welcome to Buildroot
buildroot login: root
Linux buildroot 5.9.0 #359 SMP Tue Oct 13 19:59:40 CEST 2020 x86_64 GNU/Linux
 17:57:28 up 1 min,  2 users,  load average: 0.15, 0.09, 0.03
Module                  Size  Used by    Tainted: G  
rtw88_8821cu           16384  0 
rtw88_8821c            73728  1 rtw88_8821cu
rtw88_usb              20480  1 rtw88_8821cu
rtw88_core            143360  2 rtw88_8821c,rtw88_usb
mac80211              544768  2 rtw88_usb,rtw88_core
cfg80211              311296  2 rtw88_core,mac80211
rfkill                 24576  1 cfg80211
buildroot ~ # iwconfig 
wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          
buildroot ~ # ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I use old tools only for smaller output.
ip and/or iw should work too
device
rtw_8821cu 1-1.4:1.2:
is with a broken/undefined efuse

after wpa_supplicant

buildroot ~ # Successfully initialized wpa_supplicant
[  773.528808] rtw_8821cu 1-5.1.2:1.0: start vif XX:XX:XX:XX:XX:XX on port 0

after dhcp

Failed to add supported operating classes IE
[  780.480927] rtw_8821cu 1-5.1.2:1.0: error beacon valid
[  780.487219] rtw_8821cu 1-5.1.2:1.0: failed to download rsvd page
[  780.494529] rtw_8821cu 1-5.1.2:1.0: failed to download firmware
[  780.509656] rtw_8821cu 1-5.1.2:1.0: leave idle state failed
[  780.530820] rtw_8821cu 1-5.1.2:1.0: failed to leave ips state
[  780.536588] rtw_8821cu 1-5.1.2:1.0: failed to leave idle state

So there some error here.
I didn't checked, if the devices appears on my AP

AP Mode not checked

caydenm · 2020-10-14T09:10:29Z

Thank you so much for the new branch. The efuses piece seemed so obvious in retrospect!

I did some testing today, I found that:

scanning work on both 2.4ghz and 5.8ghz.
AP mode looks like it works, but doesn't show on any devices on either 2.4ghz or 5.8ghz. I get similar errors to the ones you have above
STA client mode fails

ulli-kroll · 2020-10-18T18:25:22Z

Only for clarification ...
scanning is OK
STA may work, but after WPA handshake fails
AP not tested from my side
... maybe I've found something, which is also related with "failed to download firmware"

also related with some error on 8822bu after WPA handshake
transmission stalls after some seconds.

ulli-kroll · 2020-10-19T17:02:06Z

Powersafe is one issue
after disabling this

[  177.522033] rtw_8821cu 1-5.1.2:1.0: Firmware version 24.5.0, H2C version 12
[  177.929691] usbcore: registered new interface driver rtw_8821cu
[  186.171257] rtw_8821cu 1-5.1.2:1.0: start vif aa:bb:cc:dd:ee:ff on port 0
[  191.161455] wlan0: authenticate with AA:BB:CC:DD:EE:FF 
[  203.248822] wlan0: send auth to AA:BB:CC:DD:EE:FF (try 1/3)
[  204.424462] wlan0: send auth to AA:BB:CC:DD:EE:FF (try 2/3)
[  205.468159] wlan0: send auth to AA:BB:CC:DD:EE:FF (try 3/3)
[  206.408011] wlan0: authentication with AA:BB:CC:DD:EE:FF timed out

but 8822bu works with many/lots of stalls

[   77.969467] rtw_8822bu 1-1.1.2:1.0: start vif aa:bb:cc:ee:ff on port 0
[   83.106178] wlan0: authenticate with AA:BB:CC:DD:EE:FF
[   83.253868] wlan0: send auth to AA:BB:CC:DD:EE:FF (try 1/3)
[   83.261084] wlan0: authenticated
[   83.282829] wlan0: associate with AA:BB:CC:DD:EE:FF (try 1/3)
[   83.316897] wlan0: RX AssocResp from AA:BB:CC:DD:EE:FF (capab=0x11 status=0 aid=1)
[   83.326253] rtw_8822bu 1-1.1.2:1.0: sta AA:BB:CC:DD:EE:FF joined with macid 0

maybe I can think of master for testing in the wild, at least for 8822bu.
and upstream may have some fixes too ...
;-)

caydenm · 2020-10-20T07:56:39Z

I gave iw wlan3 set power_save off a go. I seem to just get the errors below.

I have seen instances of start vif <mac> on port 0, but the same pattern below is on repeat.

daemon.notice netifd: Network device 'wlan3' link is up
daemon.debug dnsmasq[1348]: listening on wlan3(#14): fe80::2xxxxxx%wlan3 port 53
kern.err kernel: [  578.820164] rtw_8821cu 1-1.4:1.0: error beacon valid
kern.err kernel: [  578.825465] rtw_8821cu 1-1.4:1.0: failed to download rsvd page
kern.err kernel: [  578.831730] rtw_8821cu 1-1.4:1.0: failed to download firmware
kern.err kernel: [  578.841439] rtw_8821cu 1-1.4:1.0: leave idle state failed
kern.err kernel: [  578.854337] rtw_8821cu 1-1.4:1.0: failed to leave ips state
kern.err kernel: [  578.859920] rtw_8821cu 1-1.4:1.0: failed to leave idle state
kern.err kernel: [  579.018763] rtw_8821cu 1-1.3:1.0: error beacon valid
kern.err kernel: [  579.024038] rtw_8821cu 1-1.3:1.0: failed to download drv rsvd page

ulli-kroll · 2020-10-21T17:48:49Z

The power safe error is in the driver.
Please use current master

This builds all chipsets from rtl8723d, rtl8822bu, rtl8821cu, rtl8822cu
Check also
modinfo rtw88_8821cu.ko
for disable power safe and disable idle module params, for both this is per default on

Also I've added make targets to

load: with beforehand unloading upstream rtw88 drivers
install: install the modules, this will be done after 5 sec danger time
firmware: install firmware

This is/should be documented in newer README
up next in README is

driver stalls in transfer and/or wpa handshake
bug reports

HAVE FUN

caydenm · 2020-10-22T09:41:54Z

Thank you!

I gave master a go with the recommended disable power safe and disable idle params.

I now get
kern.err kernel: [ 579.018763] rtw_8821cu 1-1.3:1.0: error beacon valid
kern.err kernel: [ 579.024038] rtw_8821cu 1-1.3:1.0: failed to download download drv rsvd page

AP appears to set the correct channel etc. but fail to show on any client.

caydenm · 2020-10-22T09:42:39Z

I can add some more logging to the driver if that is helpful and see if I can track down more of what is going on?

ulli-kroll · 2020-10-22T13:21:52Z

NO.
I've not tested AP mode and

kern.err kernel: [ 579.018763] rtw_8821cu 1-1.3:1.0: error beacon valid
kern.err kernel: [ 579.024038] rtw_8821cu 1-1.3:1.0: failed to download download drv rsvd page

on or the other (or both) are misleading
Realtek has combined at least two different (logical) functions in rsvd page

Also some covert bugs in the sources
Maybe I've send them upstream and -stable

ulli-kroll · 2020-10-24T17:51:45Z

I have some question
because I discovered some annoying firmware loading issue ..
.. which I have disabled earlier, but in some parts of of driver this is still active.

Did you use concurrent STA with AP mode ?

caydenm · 2020-10-25T06:46:37Z

I have not been using concurrent STA with AP mode. I have done a scan and run AP mode, but the vast majority of my testing is just AP mode in itself.

ulli-kroll · 2020-12-08T17:52:38Z

I think there something with the antenna.
currently (re)working/hunting bugs on rtw8822cu
driver fails to load after kernel crash due NULL pointer, with
echo "0bda c811" > /sys/bus/usb/drivers/rtw88_8822cu/new_id

#14

This was referenced Oct 19, 2020

USB3 issue ulli-kroll/rtl8822bu#1

Open

Hostpot ulli-kroll/rtl8822bu#14

Open

SeanMollet mentioned this issue Jul 13, 2023

Loading driver problem lwfinger/rtw88#113

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

failed to download firmware using rtw_8822cu on 8811cu #11

failed to download firmware using rtw_8822cu on 8811cu #11

caydenm commented Oct 5, 2020 •

edited

Loading

caydenm commented Oct 6, 2020

caydenm commented Oct 8, 2020

ulli-kroll commented Oct 8, 2020

caydenm commented Oct 9, 2020 •

edited

Loading

caydenm commented Oct 9, 2020

caydenm commented Oct 9, 2020

caydenm commented Oct 10, 2020 •

edited

Loading

caydenm commented Oct 11, 2020

caydenm commented Oct 11, 2020

ulli-kroll commented Oct 11, 2020

caydenm commented Oct 13, 2020

ulli-kroll commented Oct 13, 2020

caydenm commented Oct 14, 2020

ulli-kroll commented Oct 18, 2020

ulli-kroll commented Oct 19, 2020

caydenm commented Oct 20, 2020

ulli-kroll commented Oct 21, 2020

caydenm commented Oct 22, 2020

caydenm commented Oct 22, 2020

ulli-kroll commented Oct 22, 2020

ulli-kroll commented Oct 24, 2020

caydenm commented Oct 25, 2020

ulli-kroll commented Dec 8, 2020 •

edited

Loading

failed to download firmware using rtw_8822cu on 8811cu #11

failed to download firmware using rtw_8822cu on 8811cu #11

Comments

caydenm commented Oct 5, 2020 • edited Loading

caydenm commented Oct 6, 2020

caydenm commented Oct 8, 2020

ulli-kroll commented Oct 8, 2020

caydenm commented Oct 9, 2020 • edited Loading

caydenm commented Oct 9, 2020

caydenm commented Oct 9, 2020

caydenm commented Oct 10, 2020 • edited Loading

caydenm commented Oct 11, 2020

caydenm commented Oct 11, 2020

ulli-kroll commented Oct 11, 2020

caydenm commented Oct 13, 2020

ulli-kroll commented Oct 13, 2020

caydenm commented Oct 14, 2020

ulli-kroll commented Oct 18, 2020

ulli-kroll commented Oct 19, 2020

caydenm commented Oct 20, 2020

ulli-kroll commented Oct 21, 2020

caydenm commented Oct 22, 2020

caydenm commented Oct 22, 2020

ulli-kroll commented Oct 22, 2020

ulli-kroll commented Oct 24, 2020

caydenm commented Oct 25, 2020

ulli-kroll commented Dec 8, 2020 • edited Loading

caydenm commented Oct 5, 2020 •

edited

Loading

caydenm commented Oct 9, 2020 •

edited

Loading

caydenm commented Oct 10, 2020 •

edited

Loading

ulli-kroll commented Dec 8, 2020 •

edited

Loading