What timing! Just saw today's Freefall http://freefall.purrsia.com/ff4100/fc04009.png and now I'm thinking maybe I should instead write "It's absolutely impossible to write a mainline driver for rtl8723cs!!!!" and hope someone does just to prove me wrong? :meowGiggle:
After a closer look at #rtl8723cs I can say I'm not surprised there's still no upstream driver. That code is a horrible mess, and the options are a) fully untangle and clean up the mess for upstreaming or b) untangle enough to understand what you need to know to write a new, clean driver. Or maybe extend one of the existing mainline drivers? There seem to be some similarities with the rtw88 SDIO parts at least. I think I'll keep trying (leaning towards option b), but help would be very, very welcome. :meowPout: #MobileLinux#PinePhone
@airtower Is rtl8723cs very different from rtl8723bs? Anyway I guess understanding if existing driver can be adapted is the first step. Not sure about good introductions, but network drivers are conceptually quite simple, and wifi is not an exception. Good luck :-).
Scaffolding for a driver based on rtw88. Rtw88 already supports a similar SDIO 802.11n chip, so it takes care of the SDIO communication, but I'll have to implement the chip operations and figure out initialization commands and values and similar. Right now it'd crash if you tried to run it because required chip operation function pointers are NULL, but it compiles.
A little tool that creates proper firmware files from the firmware arrays included in #rtl8723cs.
What's interesting is that the old driver calls the wifi chip RTL8703B, as part of the combined wifi/bluetooth RTL8723CS module. I'll probably share code when I have it so far that it doesn't crash and logs something about detecting the chip. :blobcatpeek:
8703B seems to have a happy amount of overlap with 8723D, which is already supported by rtw88. Not enough to just use that one, but being able to avoid reinventing things like the EFUSE data parsing is nice.
I said I'd share code when I have something that doesn't crash, and I do now: https://github.com/airtower-luna/linux/commit/5926d4aa22e6db72a3f7941e297a4b796f5746fb The "rfe 0 isn't supported" error is because data tables with transmit power and regulatory information are missing, so that'll have to be the next thing. Help with that or other parts welcome! :blobcatcoffee:
One thing that really worries me is if the firmware can be accepted into linux-firmware this way ("extracted from array in vendor driver files marked as GPL-2"), and if the driver could be accepted upstream (later, when it supports at least station mode) if not. Reading the README of the linux-firmware repository gives me doubts at least.
Does anyone know how that works? Or even better, has a contact at #Realtek who could see about getting the firmware released directly? Or at least at #Pine64 or some other Realtek customer who could poke them?
I have #rtw8783cs at the point where it sets regulatory information (that's after uploading firmware and reading efuse), and then crashes because setting tx power index isn't implemented yet (AKA NULL function pointer). Progress! :meowBox:
The problem with testing a new kernel build is having to reboot if it went wrong, after a NULL pointer dereference so many seemingly unrelated things can break weirdly. :meowSweat:
But hey, #rtw8783cs gets through SDIO probe and initialization now, and then crashes in MAC init (when it's actually supposed to become a network interface). :blobcat_mlem:
Good news about the firmware issue, I asked about it on the linux-wireless mailing list and the rtw88 maintainer who works with Realtek offered to add the Signed-off-by needed for a linux-firmware patch. So that's looking solvable, which leaves "only" the technical issues. :blobcatpeek: #rtw8723cs
The old rtl8723cd driver has an unbelievable amount of macros defining register address. Not just one per register, so many that when searching for one a typo might find a macro with the expected address, but then no further matches (that just happened to me). REG_APE_PLL_CTRL_EXT, REG_AFE_PLL_CTRL (this one actually gets defined in four different headers), REG_AFE_PLL_CTRL_8703B all point at 0x0028, and that's already excluding variants with other chip type suffixes. :meowSweat:
The reason I'm searching around for register definitions is that I need to find out how the driver sets them while setting up the phy, because a new driver will have to do (approximately) the same. Again the sequence looks very similar to what the mainline rtw8723d driver does, but I have already found subtle differences, so I can't just reuse its phy setup. Unless I later find those differences aren't actually relevant… #rtw8723cs
Now this is peculiar… #rtw8723cs can't get a proper MAC address from EFUSE (no, ff:ff:ff:ff:ff:ff isn't one), so I assume something must be wrong about the way I'm reading it. Except then I figure out how to get the old 8723cs driver to dump its EFUSE data, and it's exactly the same! Now where does it get its permanent MAC from? It even writes ff:ff:ff:ff:ff:ff in the log after, but then it changes that… :meowSweat:
So many data tables... Hopefully it's enough now to get started on implementing the functions needed to get the chip to actually send and receive anything. Like the one to set the channel. #rtw8723cs
So I added stubs for not yet implemented functions avoid NULL function pointer dereferences while testing. New error type unlocked: "kernel write to read-only memory". :meowGiggle:
Apparently query_rx_desc is the most important thing to implement next, because mac80211 is spewing warnings about invalid rate information when receiving. If I understand the stack right that means the chip is actually receiving packets, so that's nice. :blobcattea: #rtw8723cs
No new #rtw8723cs commits today, but instead two #pmbootstrap MRs because I finally tried out envkernel.sh, mostly because I got too annoyed about #clangd not working on the kernel sources. The kernel has a helpful scripts/clang-tools/gen_compile_commands.py script to generate the compile_commands.json file, but it requires build output, which I don't get from pmbootstrap build --src. With envkernel.sh and a little extra tweaking it works now. :blobcat_mlem:
And now there's a third #pmbootstrap MR from this, which fixing building a pmOS kernel package from the kernel built using envkernel: https://gitlab.com/postmarketOS/pmbootstrap/-/merge_requests/2231 So now I have a full working envkernel workflow. Would anyone be interested in a little writeup about the clangd part? :blobcatcoffee:
Also, I have first scan results from #rtw8723cs! Only from the default channel (no channel switching yet), and signal strength isn't processed, but it's a very clear "it's working" sign. :meowSmile:
Register address definitions like #define R_0x950 0x950 are… not very helpful to figure out what the register is for. What I know so far is that bit 11 says whether some LNA (low noise amplifier) status uses 3 or 4 bits (and the expected value is 1 for RTL8703B), and in some other chips other bits seem to have things to do with driving different antennas. Now what do I call my own macro for that register? :blobcatsurprised: #rtw8723cs
And it gets even weirder… No matter the value of that bit, only 3 bits are actually read. The 4 bit value is just a bitwise OR with (1 << 3). And the result only ever gets used in a switch with hardcoded numbered cases! I think I get what's going on though: Depending on that bit the 3 bits of rx power information received from the chip need to be interpreted differently, and they chose about the most convoluted way possible to do it. :meowSweat: #rtw8723cs
And sometimes things are simpler than they seem. I was looking for clues how to calculate the channel bandwidth of a received packet from an rxsc field in the phy status like the other rtw88 drivers do, but the rxsc field in the 8723cs phy status is a) half as wide as that used by the later models (2 instead of 4 bit), and b) entirely unused in the vendor driver. Turns out it just uses a field from the RX descriptor instead. :meowSweat: #rtw8723cs
And RX PHY status parsing is working, I'm getting reasonable signal information! Monitor mode works as long as you only care about the default channel. One issue is that the driver gets (and then needs to drop) packets with length zero, based on timing my guess is that it's Bluetooth interference: BT coex isn't implemented yet, and they always appear/disappear with state changes there. Channel switching is my next target. :meowBox: #rtw8723cs#MobileLinux#Pinephone
If anyone wants to help and pick a component I'm unlikely to get to very soon, BT coex would be a great candidate. Just saying. :meowAngel:
Interesting, the mainline rtw8723d driver has a similar workaround, but for significantly fewer channels: only 13 and 14, as opposed to 5 through 8 and 13 and 14. I guess they improved the hardware in between? :blobcat_mlem:
And I have channel switching working, scan finds my home wifi now! Code needs some cleanup before I commit, but it's working, and in some parts simplified compared to the old driver! :meowBox: #rtw8723cs
@airtower this is amazing, do you by any chance have an idea how close the 8723bs is to the cs? It's quite annoying that these have two completely different drivers
Why do all these Realtek drivers (both old 8723cs and other rtw88 drivers) use "IQK" as acronym for "IQ Calibration"? Still need to figure out what that is and what exactly "IQ" means in the wifi context, but it's something about signal quality, and apparently temperature matters. :meowSweat: #rtw8723cs
Hm. Missing signal quality calibration could explain why the signal currently gets bad really quickly with distance and walls in between. My phone connects to wifi just fine across the room from the router, but walking two rooms over it can't connect any more. Now the question is, do I switch focus from BT coex to IQK? I'm pretty sure lack of BT coex is leading to dropped packets and WPA handshake often needing a few tries. :catThink: #rtw8723cs
Random find from the 8723cs source code: The thermal change threshold to trigger LCK (a kind of calibration) is 8, and a comment says that's 20°C. So the sensor measures (or transmits, at least) in steps of 2.5°C. I pushed some BT coex stuff for #rtw8723cs last night, but switched focus to calibration for now because the short range bothers me more. The BT coex stuff as far as I got seems to reduce wifi issues during connection, but BT still isn't usable with wifi on. :blobcattea:
Took a deep dive into the rtl8723cs code TX power track code, and compared with rtw8723d code. Looks like I can reuse a lot for #rtw8723cs again, but not all, the main difference is how settings are written to registers (and of course data tables with settings for different rates, modulations, etc.). Another nice thing is that I can start using only those tables and implement calibration later. Maybe the defaults will be enough to connect from two rooms away from my AP? :blobcattea:
Nope, power path without actual calibration doesn't help, but at least it was a good split of tasks. And a little test with ping from phone to AP, with tcpdump running on the router indicates TX is indeed where the problem is. For all packets that showed up on the router the phone also received the response. So IQK has to be next. #rtw8723cs
Finally got the range issue fixed (implementing IQK didn't), and I'll probably never trust an EFUSE without verifying again. Turns out the one in the RTL8723CS chip in my #Pinephone doesn't contain valid TX power data (like the general rtw88 infrastructure expects). Upon closer inspection the old driver detects that case and uses a built-in array instead. :blobcatevil: #rtw8723cs
If you try #rtw8723cs, please enable CONFIG_RTW88_DEBUG in the kernel build, and enable as many of the rtw88 debug flags as possible without flooding your log too much when loading the rtw88_core module. I currently have this in a modprobe.d config for general use:
options rtw88_core debug_mask=0x000200a0<br></br>
The value is a bitwise OR of the flags, so 0xffffffff enables everything (especially RTW_DBG_FW and RTW_DBG_COEX produce a lot of messages). You can change the value at runtime by writing to /sys/module/rtw88_core/parameters/debug_mask. If anything goes wrong, the debug messages might provide hints what it was. :meowSmile:
Still trying to figure out BT coex. The annoying thing is that while the general logic is pretty much the same between rtl8723cs and rtw88, and both use tables in the same format to configure BT coex, they use the tables in different ways. This includes rtw88 using indices that simply aren't defined in rtl8723cs, and rtl8723cs modifying some TDMA table entries under certain conditions (e.g. a device with A2DP profile being connected). Not having documentation on what each index is supposed to mean on either side makes it hard to make adjustments, I might have to create some based on under exactly which conditions which driver uses which index. :meowSweat: #rtw8723cs
Oh, and to make it even weirder I found a few cases where rtl8723cs applies a modification that never changes anything. For example, a bitwise OR 0x11 | modify, where modify is guaranteed to be 0x01 or 0x00. The result is always 0x11 anyway. :meowSweat: #rtw8723cs
So, got BT coex working. Turns out there were two invalid EFUSE bytes affecting it, of which I had found and fixed only one before. :meowSweat: The nice part is that the coex tables are the same format between devices, so I can just reuse the rtw8723d tables to adjust for the different indices rtw88 uses.
I also added very detailed EFUSE parse logging, and I'll go through all those 0xff values and see if they might cause trouble elsewhere. Rtw88 does some validation, but the fallback usually isn't what's needed for 8703B. I'm really curious if other people's RTL8723CS chips (#Pinephone or otherwise) also have almost entirely invalid EFUSE data. If you want to check: Load the module with RTW_DBG_EFUSE enabled in rtw88_core debug_mask (scroll up the thread a little for details), and look for "EFUSE raw logical map" and the about 70 lines after in the kernel log. If your EFUSE is also mostly 0xff the last relevant line will be mac_addr=ff:ff:ff:ff:ff:ff.
Anyway, this means #rtw8723cs now does all I need in daily operation, which is a huge step! :blobcattea: #LinuxMobile
For anyone who's using #rtw8723cs from my Git repo, I've rebased the rtw88_8723cs branch on top of megi's 6.7.2 tag (orange-pi-6.7-20240127-1717), plus the patches in the pmOS 6.7.2 package, plus rtw88 changes in 6.8-rc2. Of course I want 6.7.2 in general, but I also want to minimize the diff for sending patches. The pre-rebase version is still available at rtw88_8723cs-6.7 for now, but I'm not going to work on that any more. :blobcatcoffee:
Why is scripts/checkpatch.pl complaining if you have the SPDX-License-Identifier in a // comment (not /* ... */) in a header, but also complaining if you don't use // for the same thing in a .c file? Can't you just pick one style and stick with it? :meowSweat: #Linux
Is there a guideline for how long I should wait for a response when asking people if they want a Suggested-by line? Obviously (and documented) I can't just add it without asking, so I'm wondering how long I should wait before sending the patch without, without that being rude. :catThink: #rtw8723cs#Linux
Add comment