Closed briansune closed 7 months ago
lwfinger
commented
11 months ago Bringing your interface up is not the driver's responsibility. That is done by your user-space network control software. What are you using? I recommend NetworkManager. It Just Works.
briansune
commented
11 months ago Do you mean the driver is working? This is a cross-compiled insert module method.
I am using networkmanager
` Docs: man:NetworkManager(8) Main PID: 498 (NetworkManager) CGroup: /system.slice/NetworkManager.service └─498 /usr/sbin/NetworkManager --no-daemon
Jul 26 02:08:52 localhost.localdomain NetworkManager[498]:
briansune
commented
11 months ago Let me attach the dmesg:
[ 99.221393] rtw_core: loading out-of-tree module taints kernel. [ 110.501543] rtw_8723ds mmc1:0001:1: Firmware version 48.0.0, H2C version 0
RadxaYuntian
commented
8 months ago I'm also having this issue. The wired thing is I did have this working before on 8723DS :/ I also have ff:ff:ff:ff:ff:ff as MAC address, and I tried both iwd and wpa_supplicant as NetworkManager backend on Debian 12. None of them helps.
Edit: rtl8723ds worked on the same hardware and system.
briansune
commented
8 months ago @RadxaYuntian
I am not sure the root cause but what I had discussed with @lwfinger is that the RTW88 have not default firmware loading when IC is not fused with a firmware and this is my case.
The board hardware is fully custom and IC is not from OEM or broker, which causes the IC is not fused with any default firmware. @lwfinger I am not sure you had update the driver with a default firmware like rtl8723ds old repository or not?
BR Brian
RadxaYuntian
commented
8 months ago The board hardware is fully custom and IC is not from OEM or broker, which causes the IC is not fused with any default firmware.
Same thing here. We are a SBC manufacturer and the affected is one of our product.
I don't quite understand what you mean by firmware. From dmesg it appears to be loaded: Firmware version 48.0.0, H2C version 0. I assume it is using /lib/firmware/rtw88/rtw8723d_fw.bin.
I think you might mean eFUSE. I'll take a look at related code as well.
briansune
commented
8 months ago @RadxaYuntian
Opps typo, it should be IC settings aka EFUSE not firmware. The EFUSE is controlling the TX LUT power and DCDC, XTAL settings.
You are right eFUSE is what I am discussing.
BR
briansune
commented
8 months ago @RadxaYuntian
Why I will discuss @lwfinger with the EFUSE setting is because the XTAL is mostly the case along side with the DCDC. If XTAL is not aligned with the EFUSE then the WIFI 100% won't work. If DCDC is not aligned with EFUSE, the voltage you can measure is off the normal range. Either way will cause the WIFI chip not working, so as long as RTW88 is not update there are not way it could happen.
BR
lwfinger
commented
8 months ago I looked into providing a default EFUSE when it is not programmed, but I got diverted. If the MAC address is all ones, the EFUSE is not programmed.
briansune
commented
8 months ago @lwfinger
Yes, if all ones are shown then EFUSE is not preloaded for the IC. Then the driver need to take place to preload a default one which the old RTL8723DS had provided. But RTW88 does not, which you need to update or extract those from the old repository.
BR
briansune
commented
8 months ago @lwfinger
I am afraid I don't have that ability to transfer the old driver to the new old. I am mostly hardware engineer so this is really out of my scope and I would like to.
=S
RadxaYuntian
commented
8 months ago I see there is Efuse_Read1ByteFromFakeContent in rtl8723ds, but I did not find where fakeEfuseContent got initialized. It appears it has a default value of all 0 and then memset to all 0xFF, and neither looks like some real eFuse data.
briansune
commented
8 months ago @RadxaYuntian
My method to see the EFUSE is using old RTL8723DS repository and make the debug flag to 4 and during driver load there is a series of message that shown the EFUSE are all ZERO and then it will say loading a default one.
RadxaYuntian
commented
8 months ago Thanks for the hint. I have located Hal_InitPGData for detecting invalid eFuse and then a bunch of parse functions. An example of falling back to driver defaults can be found in hal_load_pg_txpwr_info for loading TX LUT.
I'll see what will happen if I inject them in rtw88's rtw8723d_read_efuse.
briansune
commented
8 months ago @RadxaYuntian
Great, would be nice to push back to this repository.
RadxaYuntian
commented
8 months ago Spent last 2 days on this hack: https://github.com/radxa-pkg/rtw88/commit/9d2ffb52718d33f6ecba909e5715d28e5197c16d
Current status and insight learnt:
efuse->addr. All zero or all 0xFF address will be accepted by the system as-is, and NetworkManager won't generate random address for those, so the device cannot be brought up. Wasted a lot of time on this.pg_txpwr_def_info extracted from rtl8723ds both allows the chip to start, even when combined.iw reg set) and can scan and list Wi-Fi networks (via nmcli device wifi rescan/list). The discovered networks are much fewer than what's available, and I haven't been able to get it connected:[ 947.839160] wlan0: authenticate with c8:3a:35:9e:43:61
[ 947.839258] wlan0: 80 MHz not supported, disabling VHT
[ 948.570820] wlan0: send auth to c8:3a:35:9e:43:61 (try 1/3)
[ 949.844179] wlan0: send auth to c8:3a:35:9e:43:61 (try 2/3)
[ 950.836181] wlan0: send auth to c8:3a:35:9e:43:61 (try 3/3)
[ 951.828260] wlan0: authentication with c8:3a:35:9e:43:61 timed outI think to fix it is currently beyond my scope, so we will have to use rtl8723ds in the mean time.
briansune
commented
8 months ago @RadxaYuntian
Do a manual MAC assign make the LO lock? And able to scan WIFI? If a scan is able to get WIFI device then this is much easy to fix otherwise it is just back to beginning.
RadxaYuntian
commented
8 months ago Do a manual MAC assign make the LO lock?
I'm not sure what you mean by LO lock. Also I did not try assigning MAC from user space. The MAC address was hardcoded in the driver for now.
And able to scan WIFI?
Yes, albeit much less that what is available here.
briansune
commented
8 months ago @RadxaYuntian
So the updated driver can work? Could you forward and let me give it a try and see the different? Thank you
As for LO = local oscillator: A simple measurement at the LDO output or the DCDC output when power on the voltage should be low. Once the driver is attached or the EFUSE is loaded then the voltage will be raised to a point that very obvious. And may I ask what XTAL you are using?
RadxaYuntian
commented
8 months ago In case I wasn't clear the driver DOES NOT work for me. I was not able to connect to any network.
If you still want to try it here is a Debian dkms package in zip (since GitHub doesn't allow deb uploading).
I don't have the BOM but I think it is a 24M 12pF crystal. If you are curious here is the schematic for our product:
https://dl.radxa.com/rockpis/docs/hw/ROCK-PI-S_v13_sch_200910.pdf
Search 8723 to see the related page.
briansune
commented
8 months ago @RadxaYuntian
I need a source to cross compile as my platform is not Debian but ubuntu on different ARM system. I think you had only update this sections? https://github.com/radxa-pkg/rtw88/commit/9d2ffb52718d33f6ecba909e5715d28e5197c16d
briansune
commented
8 months ago @RadxaYuntian
As for schematic short review show you are using DCDC setting. The custom board we had here do tired both LDO and DCDC on old RTL8723DS driver. Result both are normal, but DCDC sometime is more easier to be unstable as noise is more subjected to board layout.
RadxaYuntian
commented
8 months ago If you want source code it is available here: https://github.com/radxa-pkg/rtw88/tree/issue_157
RadxaYuntian
commented
8 months ago Looking back I forgot to run with debug_mask and see what was wrong.
briansune
commented
8 months ago @RadxaYuntian
Let's compare and see if the issue is aligned.
briansune
commented
8 months ago @RadxaYuntian
I got the current message:
[ 27.285840] rtw_core: loading out-of-tree module taints kernel. [ 37.657580] rtw_8723ds mmc1:0001:1: rtw88 SDIO probe: vendor=0x024c device=d723 class=ff [ 37.667085] rtw_8723ds mmc1:0001:1: Firmware version 48.0.0, H2C version 0 [ 38.148561] rtw_8723ds mmc1:0001:1: hw cap: hci=0x06, bw=0x03, ptcl=0x02, ant_num=2, nss=1 [ 38.148576] rtw_8723ds mmc1:0001:1: use rfe_def[17] [ 38.148586] rtw_8723ds mmc1:0001:1: rfe 17 isn't supported [ 38.154981] rtw_8723ds mmc1:0001:1: failed to setup chip efuse info [ 38.159943] rtw_8723ds mmc1:0001:1: failed to setup chip information
RadxaYuntian
commented
8 months ago Your eFuse must have been partially populated, as I changed rfe to come from eFuse first: https://github.com/radxa-pkg/rtw88/commit/9d2ffb52718d33f6ecba909e5715d28e5197c16d#diff-bda2ebb54a6c298b057cfa4da3534fd505b263989ec51d3663e3f40d9f3a0ebaL233-R261
You can change line 261 back to efuse->rfe_option = 0;
briansune
commented
8 months ago @RadxaYuntian
Network can scan and WIFI devices are showing up. Compared to previous this RTW88 driver it cannot list WIFI devices. Looks like you had made a different.
And WIFI can ping and connect as well but not sure why nmcli works but not nmtui =S I don't know much kernel stuff.
briansune
commented
8 months ago @RadxaYuntian
But I don't understand what is the major reason to use RTW88 rather than RTL8723DS driver?
@lwfinger What are the different compare between new RTW88-based RTL8723DS and old RTL8723DS driver?
briansune
commented
8 months ago @RadxaYuntian
And there is a catch that looks like it is not too stable compared to old RTL8723DS:
RadxaYuntian
commented
8 months ago That's actually amazing. Although I suspect your chip might have some eFuse fields prepopulated with correct value. On my chip where everything is basically 0xFF I could not get it to work.
Can you run old 8723ds driver with debug enable and output level to 4? It should dump your eFuse content on boot, and I could compare both to see if the default values need to be adjusted.
briansune
commented
8 months ago @RadxaYuntian
Okay I give it a try but that is not possible about all 0XFF because the first few bytes must exist to determine the chip. Otherwise it will be very wrongly defined.
RadxaYuntian
commented
8 months ago Yeah I know the very beginning is not 0xFF as I also saw the eFuse dump. But for my chip at least rfe is also 0xFF which is why I changed the code to test it, instead of simply passing 0 in the orignial.
briansune
commented
8 months ago @RadxaYuntian
lwfinger
commented
8 months ago @briansune - The main difference between the 2 drivers is the one in rtw88 is maintained. The old one from Realtek is not.
The difference in sensitivity is that you are not setting the RX and TX gains. You need to read the old driver to see what it shows, and do the same in your simulated EFUSE. That is where this information should be.
briansune
commented
8 months ago @lwfinger
I didn't mention any sensitivity nor trying to simulated the EFUSE that is what @RadxaYuntian trying to move the old repository RTL8723DS to the new RTW88. Maybe the sensitivity you trying to refer is about the stability of the ping test.
BTW, it is maintained then the EFUSE preloaded feature is also included? As grabbing the old EFUSE is just a temporary fix,
lwfinger
commented
8 months ago The stability of the ping test, the sensitivity of the scan, and the ease of making a connection will all depend on the TX/RX gains. If the device has the EFUSE programmed, then the gains will come from the EFUSE. If not, it will need to be set the way the MAC address is.
RadxaYuntian
commented
8 months ago Do you mean Hal_ReadRFGainOffset? PPG_THERMAL_OFFSET_8723D and PPG_BB_GAIN_2G_TX_OFFSET_8723D are defined as 0xFF in Brian's eFuse, so I guess I'm not looking at the right place. The related power_trim function also seems to be only available for rtw8822.c in rtw88 driver. It appears to be a lot of missing functionality for rtl8723ds.
briansune
commented
8 months ago @RadxaYuntian
I am afraid my expertise's are out of the scope of these coding stuff. I can help on hardware testing and simple cross-compile stuff =S. As for the EFUSE are my extracted same as yours?
lwfinger
commented
8 months ago @RadxaYuntian - There could be missing functionality in the 8723ds code, but it works in the PCI and USB drivers, and for the SDIO drivers that have properly coded EFUSE.
In file rtw8723ds.h, struct rtw8723d_efuse shows the layout of the EFUSE that the program expects. In array txpwr_idx_table should be the parameters that the program expects. I have no idea what the vendor driver does.
briansune
commented
8 months ago @lwfinger
It is possible to add a printout function or debug to the exist RTW88 and allow @RadxaYuntian to compare with a pre-FUSED IC?
lwfinger
commented
8 months ago Of course it is possible, but I won't do it. @RadxaYuntian should tell you what variables he wants to see or send you a patch file. The main repository has to be kept clean.
RadxaYuntian
commented
8 months ago As for the EFUSE are my extracted same as yours?
TL;DR: it is really all 0xFF past first 16 bytes.
In array txpwr_idx_table should be the parameters that the program expects. I have no idea what the vendor driver does.
Vendor driver supplies a device-specific fallback rtl8723d_pg_txpwr_def_info and a generic fallback pg_txpwr_def_info when the value from eFuse or the more specific fallback failed to meet the hal_chk_pg_txpwr_info_2g and hal_chk_pg_txpwr_info_5g checks in hal_load_pg_txpwr_info. I have tested both data on my device but they did not provide good performance. So I think the issue is in the other fields where Brian's eFuse has a different value than the defaults I included from rtl8723ds vendor driver.
Although even if I could make it to work by adjusting my included defaults to match Brian's eFuse dump, we still need a way to notify the network stack that the Phy does not have a MAC address, so user space configuration daemon could handle this task. Hardcoding a MAC in the driver is not acceptable for production use.
briansune
commented
8 months ago @RadxaYuntian
Did you do a read back sanity check after loading those value or the dump is after the write? If you can guide me where should I add the code and do a 2nd read back after write on the old repository driver.
Ignore those meaning behind the seen, just simply clone a working eFUSE and compare the stability first. I am really confused by RTW88 is maintained but some basic features are missing.
RadxaYuntian
commented
8 months ago That is just what the vendor rtl8723ds prints when debug is enabled and log level is set to 4. I believe this is the raw data on the eFuse.
If you want to override the entire eFuse, you need to first update struct rtw8723ds_efuse so the final struct rtw8723d_efuse has the same size of the physical eFuse (0x200):
struct rtw8723ds_efuse {
u8 res4[0x1f]; /* 0xd0 */
u8 ppg_thermal; /* 0xef */
u8 res5[0x2a]; /* 0xf0 */
u8 mac_addr[ETH_ALEN]; /* 0x11a */
u8 res6[0xce]; /* 0x120 */
u8 ppg_bb_gain; /* 0x1ee */
u8 res7[0x10]; /* 0x1ef */
};Then in the rtw8723d_read_efuse function you can overwrite the content of log_map to be that of your emulated eFuse.
briansune
commented
8 months ago @RadxaYuntian
What I am trying to say is that: At the old RTL8723DS do you also print the eFUSE content after the driver have loaded a default eFUSE setting after checking it is incorrect? If so I can also cross-check and provide my dump to compare.
RadxaYuntian
commented
8 months ago The eFuse dumped by vendor driver is the raw eFuse data: https://github.com/lwfinger/rtl8723ds/blob/master/core/efuse/rtw_efuse.c#L2312
You can see the driver check the validity of the eFuse AFTER it was dumped: https://github.com/lwfinger/rtl8723ds/blob/master/hal/rtl8723d/rtl8723d_hal_init.c#L3634-L3649
The vendor driver also did not update the in-memory eFuse dump. The default value is plugged in at run-time, after it checks the eFuse provided value. This is also how I implemented the default value in rtw88 HACK: https://github.com/lwfinger/rtl8723ds/blob/master/hal/rtl8723d/rtl8723d_hal_init.c#L3973-L3975
briansune
commented
8 months ago @RadxaYuntian
First two explains are clear. So the dump is before default settings are loaded in. And printout is also before load.
As for the last then I would suggest why not simply reuse the before loaded print and print out the after load settings and let us do a cross-check if it is the same? (use result to debug should be more easy I guess)
Then after we had confirm both eFUSE after default settings loading the hack can be more sure to start with (I hope)?
lwfinger
commented
8 months ago @RadxaYuntian - Yes, there are features missing for rtw8723ds, but the underllying code for rtw8723d is maintained. If you/we come up with code changes, they can be introduced into wireless-next, and they will ultimately be applied to the kernel. That is what "maintained" means. It does not mean that it is complete at the moment, but the mechanism exists to make it better. BTW, the guy that wrote the kernel's rtw8723ds could not envision that there would be models in the wild with empty EFUSEs. I still cannot believe that vendors would do this!!
As to assigning a MAC address. The first 3 digits should be the Realtek manufacturer values, and the last 3 assigned from a random number. To give reproducibility, we could also set up a module parameter so that the MAC address is read at boot time. Module parameters are frowned upon, but the case could be made for a new one here.
briansune
commented
8 months ago @lwfinger
According to my previous RF company experience the EFUSE is what defines the conformance test and standard. If CE standard then the max power of the TX has to be fixed to a level as well as EMC to fit the location of sell. This do make sense as 3rd party distributor can only got blank IC.
The EFUSE is preloaded between supplier broker and the company agreement. While user can adjust the TX LUT and RX filter but from first place it much be preprogrammed to fit the standard that country going to distribute or sell. Realtek won't even response to small company and this is why WIFI module exist (USB SDIO or PCIE) as they provide 100% verified by the local conformance test and standard.
wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether ff:ff:ff:ff:ff:ff txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0 Interface doesn't support scanning : Network is down
sit0 Interface doesn't support scanning.
lo Interface doesn't support scanning.
Had tried nmcli radio wifi on and restart service.
Module Size Used by rtw_8723ds 16384 0 rtw_8723d 45056 1 rtw_8723ds rtw_sdio 20480 1 rtw_8723ds rtw_core 151552 2 rtw_sdio,rtw_8723d