Unisoc UWE5621DS on RK3566 device? calling Orange Pi experts

[dieselnutjob]

Hi

I have an RK3566 board with a Unisoc UWE5621DS wifi/BT chip on it.

I have had a number of kernels running on this board (4.19.209 BSP, 6.0 mainline, 6.1-rc1 mainline) but the wifi is a problem.

I noticed that there is an Orange Pi 5.17 kernel that includes a driver for UWE5622.  I'm not sure how close 5621DS is to 5622

Also I think that this kernel is meant for the Orange Pi 4 which has an RK3399, whereas I have RK3566.

Anyone any thoughts on what is most likely to work?

[dieselnutjob]

I just noticed that the Orange Pi 4-LTS is fully supported by Armbian and has a UWE5622 chip, so I'm having a play with that.

[dieselnutjob]

if I lift the driver out of armbian's mainline and drop it into a vanilla mainline from Linus Torvalds I get this

$ make Image modules
  SYNC    include/config/auto.conf.cmd
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  CHK     include/generated/compile.h
  UPD     kernel/config_data
  GZIP    kernel/config_data.gz
  CC      kernel/configs.o
  AR      kernel/built-in.a
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  AR      init/built-in.a
  LD      vmlinux.o
  MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN     modules.builtin
  LD      .tmp_vmlinux.kallsyms1
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
  SYSMAP  System.map
  SORTTAB vmlinux
  OBJCOPY arch/arm64/boot/Image
  MODPOST modules-only.symvers
ERROR: modpost: "sched_setscheduler" [drivers/net/wireless/uwe5622/unisocwcn/uwe5622_bsp_sdio.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
make: *** [Makefile:1746: modules] Error 2

 

Can anyone tell me what this means?

[jock]

Vanilla means version 6.1 coming from git repository on kernel.org?

Not sure why your compilation lacks sched_setscheduler symbol; it is indeed in the kernel, but maybe your .config misses some directives (looking at the source code, maybe you need CONFIG_SMP, even though it looks strange to me...)

 

Couldn't just use the .config provided by armbian and see what happens?

[dieselnutjob]

yes by vanilla I mean 6.1rc4 straight from the torvalds repo

where can I find the armbian .config ?

kernel source seems to be build/cache/sources/linux-mainline/linux-5.15.y

but I can't see a .config in there

 

[dieselnutjob]

maybe build/config/kernel/linux-rockchip64-current.config ?

[dieselnutjob]

I copied the kernel out of build/cache/sources/linux-mainline/linux-5.15.y into my own directory

Then I copied build/config/kernel/linux-rockchip64-current.config to .config in my own directory

When I then run make menuconfig it strips all of the UWE5621 stuff out of the .config

So there must be some things missing from build/cache/sources/linux-mainline/linux-5.15.y compared to what is actually compiled by the armbian build scripts I think

[dieselnutjob]

more info here https://github.com/armbian/build/pull/3770

[dieselnutjob]

I think I found the secret.

wifi-4003-uwe5622-driver.patch

wifi-4004-fix-uwe5622-park-link-policy.patch

wifi-4004-fix-uwe5622-warnings.patch

wifi-4005-uwe5622-makefile.patch

from build/patch/kernel/archive/rockchip64-5.15

[jock]

AFAIR, the distro from the vendor came with kernel 5.10 and there uwe5622 was working right there.

Yes, those 4 patches for the uwe5622 wifi/bluetooth bring support and fixes in the armbian rockchip64-5.15 patch directory.

If you would want to go with vanilla 6.1, you should probably start with the other patches in rockchip64-5.19 directory though.

 

About the device tree, there are three nodes (uwe-bsp, sprd-wlan and sprd-mtty) starting here:

https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.19/add-board-orangepi-4-lts.patch#L361

 

And also notice the comment about the pwrseq that handles the power on/off of the chip with this line:

https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.19/add-board-orangepi-4-lts.patch#L358

 

Notice also that the pwrseq reset-gpio property has to have the polarity reversed compared to the wl-reg-on property.

[dieselnutjob]

thank you.

right now I would be very happy if I could get the wifi to work with any kernel.  So last night I just tried the standard Armbian 5.15 one with those four patches applied.

This morning I tried the armbian .config but unfortunately the kernel stops because it cannot mount it's root file system (which is an ext4 partition on a microSD card).

There must be some essential line missing for the storage controller or ext4 or something.  It will take some work to figure that out.

Next I tried a config from rockchip 5.10 BSP kernel, but with the wifi settings set to match the ones in the Armbian .config

I am loosing the serial console at this line

[    0.754894][  T157] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    0.755786][  T157] cfg802�

 

My suspicion is that something in cfg80211 is hanging it, but it's difficult to be 100% sure because it's always possible that at exactly at that moment is when something is interfering with the serial UART, but I don't think so.

 

Another thing that would be really useful would be if someone has an older (like 4.19 BSP) dts / dtb file for the Orange Pi 4 LTS that is known to have working WiFi

 

I have a dtb for my device that has wifi working on Rockchip 4.19.193, but no source code for that kernel.  I would like to compare a 4.19BSP dts/dtb (if it exists) for the Orange Pi 4 LTS with a the 5.15 one to see how it changed.  Seeing how it changed on the Orange Pi 4 LTS might help me to make the same translations from my devices 4.19 dtb to one that might work with 5.15.

 

This Unisoc wifi module is an absolute pain.  I really wish that better source code was available for it.  It seems to me with the patching that you have done that you may have actually produced the best source code that exists, and for that I thank you.

[dieselnutjob]

Hi Jock

You have made me think.

I actually ported the 5.10-rk3399 driver back to 4.19BSP, because the Rockchip 4.19 BSP kernel is the only one I have that displays to the LCD panel on my device (for now).

This was quite a lot of work, including pulling the SHA256 code from 5.10 back into 4.19.

This is the dts fragment from the vendors 4.19 kernel:-

	uwe-bsp {
		compatible = "unisoc,uwe_bsp";
		wl-reg-on = <&gpio0 RK_PC0 GPIO_ACTIVE_HIGH>;
		bt-reg-on = <&gpio0 RK_PC1 GPIO_ACTIVE_HIGH>;
		sdio-ext-int-gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
		unisoc,btwf-file-name = "/vendor/etc/firmware/wcnmodem.bin";
		sdma-tx;
		sdma-rx;
		bt-wake-host;
		bt-wake-host-gpio = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
		blksz-512;
		keep-power-on;
		status = "okay";
		//phandle = <0x1d7>;
	};

 

Some notes / questions:-

1. I don't know why the dtb had a phandle to the device.  I couldn't find anything else in the dtb that refers to it.  I am a bit concerned that the compiler would surely only create a phandle to something if something actually refers to it, but maybe that isn't true.

2. I realised from what you said that wl-reg-on is moved to sdio-pwrseq in the 5.10 driver.  Of course I am still on 4.19BSP, but then I have back ported the driver from 5.10 so I guess actually I suppose that my dts needs to follow the 5.10 paradigm not the 4.19 one (that I don't have source code for).

3. Was driver that worked from Orange Pi the orange-pi-5.10-rk3399 branch or the orange-pi-5.10-rockchip64 one?

 

I think that I should have another go and port your 5.15 with the four patches and port that onto my 4.19 kernel.  Do you think I'm wrong?

[jock]

10 hours ago, dieselnutjob said:

. I don't know why the dtb had a phandle to the device.  I couldn't find anything else in the dtb that refers to it.  I am a bit concerned that the compiler would surely only create a phandle to something if something actually refers to it, but maybe that isn't true.

That phandle is absolutely spurious and not needed, it is possible that it has been left there.

 

10 hours ago, dieselnutjob said:

I realised from what you said that wl-reg-on is moved to sdio-pwrseq in the 5.10 driver.  Of course I am still on 4.19BSP, but then I have back ported the driver from 5.10 so I guess actually I suppose that my dts needs to follow the 5.10 paradigm not the 4.19 one (that I don't have source code for).

Well, you can use either wl-reg-on or sdio-pwrseq, but sdio-pwrseq is better to do because it is non-proprietary and kernel is informed about the on/off switch and can control it via rfkill. wl-reg-on is "simpler" though, because does not involve another node and subsystem and you may start with this to avoid an unnecessary bring-up complication IMHO.

 

There is no "kernel paradigm" though: the device tree properties are actually interpreted by the driver and not by the kernel itself. The kernel will read some "common" properties like compatible, pinctrl-names, and some others. You have to use the nodes and properties you found in the 5.10 device tree because you took the driver from there and ported in your 4.19 kernel.

 

10 hours ago, dieselnutjob said:

3. Was driver that worked from Orange Pi the orange-pi-5.10-rk3399 branch or the orange-pi-5.10-rockchip64 one?

Actually I don't remember exactly, I should check back the discussion with Igor and which one was hinted by Orange Pi people themselves. I had several headaches with 5.10 driver because there were issues with either newer kernels and firmware. I remember also that the 5.10 driver was having issues with recent wpa_supplicant revisions (ubuntu jammy was able to connect to wifi, for example). At last, the driver which is in the 5.15 rockchip64 kernel flavor is the best choice, is working quite well and I would suggest to go with that.

[dieselnutjob]

when you said "the driver which is in the 5.15 rockchip64 kernel" did you mean the patched Armbian one?  or do you mean the orange-pi-5.17-rockchip64 branch of the orangepi-xulong github linux-orangepi, or did you mean something else?

 

Another thing I don't understand is that 4.19BSP seems to use a special Rockchip rfkill stack and the driver is in /drivers/net/wireless/rockchip_wlan directory.  I don't understand what has to be done to a driver to be put in /drivers/net/wireless/rockchip_wlan rather than just in /drivers/net/wireless

 

The orange-pi-5.10-rk3399 branch orange-pi-5.10-rk3399-cros (what does cros mean?) seems to have the same paradigm, whereas -rockchip and later variants don't.

[jock]

17 hours ago, dieselnutjob said:

when you said "the driver which is in the 5.15 rockchip64 kernel" did you mean the patched Armbian one?  or do you mean the orange-pi-5.17-rockchip64 branch of the orangepi-xulong github linux-orangepi, or did you mean something else?

Yes, I mean the armbian patched one

 

17 hours ago, dieselnutjob said:

Another thing I don't understand is that 4.19BSP seems to use a special Rockchip rfkill stack and the driver is in /drivers/net/wireless/rockchip_wlan directory.  I don't understand what has to be done to a driver to be put in /drivers/net/wireless/rockchip_wlan rather than just in /drivers/net/wireless

This is one of the reasons to stay away, whenever possible, from the "proprietary" kernels: they use customizations in place of standard kernel sunsystems.  Sometimes there is no other way, but that rockchip_wlan is a duplicate framework that has been superseded by kernel "power sequence" (pwrseq) framework.

Anyway the two frameworks can coexist.

 

The driver in the armbian trunk works fine without the rockchip_wlan framework and you should not try to integrate it into.

17 hours ago, dieselnutjob said:

The orange-pi-5.10-rk3399 branch orange-pi-5.10-rk3399-cros (what does cros mean?) seems to have the same paradigm, whereas -rockchip and later variants don't.

No idea 🤷‍♂️

[dieselnutjob]

Thanks jock.  You have given me something else to try.  Maybe eventually one of them will work.

[SteeMan]

6 hours ago, jock said:

what does cros mean?

My guess would be "Chrome OS", or the linux kernel used for a chrome os install

[dieselnutjob]

I managed to port the Armbian driver back to 4.19.232 BSP, but I just can't get it to actually work.

 

My device has a chip that says UWE5621DS on it.  Whereas the O Pi 4 LTS spec says that it has "CDW.20U5622-00".  The .config of both devices is the same though.

Do we know for certain whether they are actually the same device?

 

What I really need is the source code for the driver that actually came on my device, which came with Rockchip Linux 4.19.193.  Does anyone have any clever ideas how to get hold of that?

 

Maybe I should buy an O Pi 4 LTS.  Do any of the vendor ROMs for it come with older 4.19 kernels and does the WiFi work on them?

[dieselnutjob]

So it seems from youtube videos that the default Linux distro on the O Pi 4 LTS uses a 4.4 kernel and that WiFi does work.

This must be this kernel https://github.com/orangepi-xunlong/linux-orangepi/tree/orange-pi-4.4-rockchip64

So I thought I would have a go at cross compiling it myself first because if I can't get my own kernel working on the board then there isn't much point in buying one, and, I suppose that the WiFi driver from 4.4 will be easier to port forward to 4.19.

 

The thing is that I can't compile it.  I get this error over and over

In file included from crypto/echainiv.c:26:
include/linux/module.h:130:9: warning: 'init_module' specifies less restrictive attribute than its target 'echainiv_module_init': 'cold' [-Wmissing-attributes]
error, forbidden warning:module.h:130
  130 |     int init_module(void) __attribute__((alias(#initfn)));
      |         ^~~~~~~~~~~
crypto/echainiv.c:178:1: note: in expansion of macro 'module_init'
  178 | module_init(echainiv_module_init);
      | ^~~~~~~~~~~
crypto/echainiv.c:168:19: note: 'init_module' target declared here
  168 | static int __init echainiv_module_init(void)
      |                   ^~~~~~~~~~~~~~~~~~~~
In file included from crypto/echainiv.c:26:
include/linux/module.h:136:7: warning: 'cleanup_module' specifies less restrictive attribute than its target 'echainiv_module_exit': 'cold' [-Wmissing-attributes
error, forbidden warning:module.h:136
  136 |  void cleanup_module(void) __attribute__((alias(#exitfn)));
      |       ^~~~~~~~~~~~~~
crypto/echainiv.c:179:1: note: in expansion of macro 'module_exit'
  179 | module_exit(echainiv_module_exit);
      | ^~~~~~~~~~~
crypto/echainiv.c:173:20: note: 'cleanup_module' target declared here
  173 | static void __exit echainiv_module_exit(void)
      |                    ^~~~~~~~~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:284: crypto/echainiv.o] Error 1
make: *** [Makefile:1036: crypto] Error 2

 

can anyone help me with this?

[dieselnutjob]

I think I finally made some progress.

My device shipped from the manufacturer with Rockchip 4.19.193 and Android.

So I decided to see if I could get as close as possible to what they shipped but with Debian rootfs

So I took the Rockchip BSP 193 source that I have and added on the wifi bits from the Orange Pi 4.4 and used the factory dtb.

The dmesg output is a mess, but it does appear to find the wifi module and load the firmware.

line 3133

[   11.069140] WCN: combin_img 4 marlin_firmware_write finish and successful

 

line 3369

[   11.457254] WCN: marlin_write_cali_data sync init_state:0x0
[   11.479146] wifi_platform_bus_enumerate device present 1
[   11.479175] ======== Card detection to detect SDIO card! ========

 

but then it all goes to hell at line 4698

[   20.326231] INFO: task systemd-rfkill:308 blocked for more than 10 seconds.
[   20.326269]       Not tainted 4.19.193 #4
[   20.326277] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[   20.326285] systemd-rfkill  D    0   308      1 0x0000000c
[   20.326295] Call trace:

 

@jock please can you look at my complete dmesg and tell me if you think I'm getting anywhere and what you think might be the problem?

see https://termbin.com/55zy

[dieselnutjob]

well this is telling though:-

Android firmware

[   24.636580] WCN: marlin_get_wcn_chipid: chipid: 0x56630001

 

My 4.19.203 with 4 4 wifi driver

[    8.584566] WCN: marlin_get_wcn_chipid: chipid: 0x0

 

😞

[jock]

Looking at the log all those sdiohal messages does not seems right at all, you should understand why you get all those messages.

The bus seems to have been probed correctly, although the frequency of 200MHz looks a bit too high to me. I would reduce it to 100MHz to exclude possible data integrity issues at first.

Anyway I'm no expert with the rockchip_wlan framework, but it really looks to me there is something wrong with the communication with the chip.

Maybe some wrongly configured gpio pins (check the pullup/pulldown configurations), maybe the frequency is too high, or the chip is somehow in reset state - if you use the rockchip framework don't use the sdio-pwrseq; surely the chipid should be rightly detected, otherwise the driver won't go anywhere.

 

[dieselnutjob]

thank you for looking.  I spotted a critical difference I think

Android:-

[    1.793413] WCN: marlin_init entry!
[    1.793904] WCN: marlin_parse_dt chip_en gpio=16
[    1.793943] WCN: marlin_parse_dt reset gpio=17
[    1.793960] WCN: wcn config keep power on
[    1.793965] WCN: wcn config bt wake host
[    1.793976] WCN: marlin_parse_dt bt-wake-host-gpio=15
[    1.794124] WCN: marlin_wakeup_host_register bt wake irq number 91
[    1.794180] WCN: wcn config wifi wake host
....
[    1.797772] WCN: marlin_probe ok!

 

Orange Pi 4.4 driver:-

[    2.058772] WCN: marlin_init entry!
[    2.059192] WCN: marlin_parse_dt reset gpio=17
[    2.059223] WCN: wcn config keep power on
[    2.059231] WCN: wcn config bt wake host
[    2.059244] WCN: marlin_parse_dt bt-wake-host-gpio=15
...
[    2.062810] WCN: marlin_probe ok!

 

Same dtb.  For some reason I think it's not picking up the chip_en gpio from the dtb.

 

Edit: hang on the above is with my 4.19.232 kernel

with 4.19.193:-

[    2.644779] WCN: marlin_init entry!
[    2.645170] WCN: marlin_parse_dt chip_en gpio=16
[    2.645205] WCN: marlin_parse_dt reset gpio=17
[    2.645225] WCN: wcn config keep power on
[    2.645235] WCN: wcn config bt wake host
[    2.645249] WCN: marlin_parse_dt bt-wake-host-gpio=15
...
[    2.648678] WCN: marlin_probe ok!

so slightly different again.

Edited November 8, 2022 by dieselnutjob

[pprdr]

On 10/16/2022 at 8:02 PM, dieselnutjob said:

Can anyone tell me what this means?

@dieselnutjob How did you solve the problem with: "ERROR: modpost: "sched_setscheduler" [drivers/net/wireless/uwe5622/unisocwcn/uwe5622_bsp_sdio.ko] undefined!" I have exactly the same problem but while compiling linux-orange po for Orange Pi Zero 2 target

[dieselnutjob]

I don't think that I did.  I have an Orange Pi 4 LTS now (it arrived this morning).  My first task is to get 6.1 working on it, after that I will have a go at compiling the 5621/5622 driver for 6.1.

[pprdr]

dieselnutjob If you manage to compile 5621/5622 for 6.1 please let me know, it can be in this thread. Btw. I solved this problem above, don't know what exactly caused the problem, but I used a different defconfig (linux-5.16-sunxi64-current.config) and it compiled and linked without errors. Maybe I will compare my current and previous defconfig to see the difference.

Edited November 24, 2022 by pprdr

[Igor]

FYI. I had to give up and disable those wireless drivers due to extreme lack of time in order to move all our kernels to 6.1.y https://github.com/armbian/build/pull/4570 You are welcome to pick up from here and fix the code in case you want to have running WiFi with this kernel. 

 

 

 

[ning]

https://github.com/zhangn1985/linux-stable/tree/sbc6.4 this is tree for orangepi-800