Wifi AP6398S + mainline kernel

may be its 15 )) but real price for new apple devices is about 100$-150$ USD i think is too much ))) be sure normal cheap wifi dongle works same fine)))

why ? u dont like realtek ? ))) for me its lil strange

linux-kernel have good support for many realtek wifi chip RTL8xxxx
i have some very nice devices and cheap same time, its work without problems ! whats problem ?

It seems to me that we are talking about mainline support of ampak AP6398, containing Broacdom bluetooth and wifi chips, not Realtekā€¦

1 Like

I also think the new price is expensive, which is why I buy them used on eBay for $13 instead of new for $100-150. Good luck supporting your users with cheap Realtek USB dongles. The mainline kernel has support for older b/g/n chipsets not the current shipping b/g/n/ac chips that most users want to use. The newer chipset drivers are not in-kernbel and are not maintained by Realtek using any public sources, and they break with every kernel bump. Thatā€™s my definition of a crap driver. Your definition and tolerance may be different to mine.

Anywayā€¦ please focus your time figuring out how to get mainline kernel support for the Ampak module that ships in all of your boards.

2 Likes

When can we expect a working driver for VIM3 wifi on Linux side?
I see CoreElec have working wifi with 4.9 - Just for info.

Maybe this time next year if weā€™re lucky.
I already posted the latest kernel AP6398S driver from Ampak that they have working on non Amlogic, Rockchip devices using the 5.3.0 mainline kernel. So someone just has to modify the code to get it working and troubleshoot.
The 4.9 kernel driver code CoreELEC uses will also not work on the 5.3.0 kernel since itā€™s even older.

Sure is, Iā€™m not a lover of Realtek chips either, but they just work

Hello,
Can you guide me to the codes that needs to be modified?

As i see ap6398S firnware is provided by rockchip devices but weā€™re not able to use the same on vim3.

Can someone advice on how we can make use of it?

The 5.3 kernel driver also doesnā€™t work on Rockchip devices.
Also doesnā€™t seem that anyone tried to test it in the last 2 months, which is sad since both the Khadas Edge-V Pro and VIM3 uses this wifi chip.
Maybe someone will try to pick it up and test it again, if it works on Rockchip then it will have a better chance to also work on the Vim 3 later.

https://patchwork.kernel.org/project/linux-wireless/list/?series=215429 was posted to linux-wireless and has been tested on VIM3 and Edge ā€¦ Iā€™m travelling for a few days so VIM3L will need to wait until Iā€™m back home again. This is from a VIM3 on 5.5-rc2 + patches:

VIM3:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr C8:63:14:70:41:C1  
          inet addr:192.168.2.14  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2369 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1697 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2632052 (2.5 MiB)  TX bytes:159725 (155.9 KiB)
          Interrupt:6 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  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)
wlan0     Link encap:Ethernet  HWaddr 6C:21:A2:9B:26:AE  
          UP 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 still see a kernel splat on probing and some other errors from the brcmfmac driver. Iā€™m still getting people to test on other G12A/B devices to rule in/out whether itā€™s something SoC, board, or driver specific that needs investigating. Progress is progress though, and hopefully this means one less reason to need out of tree drivers or 4.9 kernels :slight_smile:

7 Likes

Thatā€™s great news, I will test this patchā€¦

tnx for good news for VIM3 VIM3L users

i just complite test it this patches for VIM3L openwrt 19.07.0-rc2

its works

root@openwrt-vim:~# uname -a
Linux openwrt-vim 5.4.0-rc5 #2 SMP PREEMPT Wed Dec 18 18:01:39 +09 2019 aarch64 GNU/Linux

root@openwrt-vim:~# iwconfig wlan0
wlan0     IEEE 802.11  Mode:Master  Tx-Power=31 dBm   
          RTS thr:off   Fragment thr:off
          Power Management:on

i can get about 23000KB/s in AP mode

PS: i think make new openwrt images for VIM3 VIM3L soon

2 Likes

Please let me know if you see any kernel splats or brmcfmac errors in dmesg. Iā€™ve seen a warning splat on VIM3 and would like to know if itā€™s kernel, defconfig, soc, board, or ??? related.

This is awesome news.

Thanks. Will keep an eye on the patch series and see when it gets applied in linux-next: :slight_smile:

Hello @chewitt

I just sync patches from your LE repo: https://github.com/chewitt/LibreELEC.tv/tree/amlogic-master/packages/linux/patches/amlogic

But it seems not very stable, sometimes work but sometimes not and I got the error:

[    5.149743] brcmfmac: F1 signature read @0x18000000=0x17294359
[    5.157179] ------------[ cut here ]------------
[    5.158863] WARNING: CPU: 5 PID: 42 at brcmf_sdiod_sgtable_alloc+0x130/0x138 [brcmfmac]
[    5.158866] Modules linked in: brcmfmac brcmutil cfg80211 rfkill ip_tables x_tables btrfs blake2b_generic xor xor_neon zstd_compress lzo_compress zlib_deflate raid6_pq libcrc32c gpio_pca953x rtc_hym8563 rtc_meson_vrtc
[    5.184894] CPU: 5 PID: 42 Comm: kworker/5:1 Not tainted 5.5.0-rc2+ #0.7
[    5.184895] Hardware name: Khadas VIM3 (DT)
[    5.184922] Workqueue: events brcmf_driver_register [brcmfmac]
[    5.201445] pstate: 80000005 (Nzcv daif -PAN -UAO)
[    5.201466] pc : brcmf_sdiod_sgtable_alloc+0x130/0x138 [brcmfmac]
[    5.212253] lr : brcmf_sdio_probe+0x2a8/0x920 [brcmfmac]
[    5.212255] sp : ffff8000101aba70
[    5.220759] x29: ffff8000101aba70 x28: 0000000000000000 
[    5.220761] x27: 0000000000000000 x26: ffff800009cc61a0 
[    5.220763] x25: ffff800009cce000 x24: ffff0000af955400 
[    5.220764] x23: ffff800012108000 x22: ffff0000ada67000 
[    5.220765] x21: ffff800009cc6000 x20: 0000000000000023 
[    5.220766] x19: ffff0000af955000 x18: 0000000000000000 
[    5.220768] x17: 0000000000000000 x16: 0000000000000000 
[    5.220769] x15: 0000000000000000 x14: 0000000000000000 
[    5.220770] x13: 0000000000000001 x12: 00000000002bb626 
[    5.220771] x11: 0000000000000005 x10: 0101010101010101 
[    5.220773] x9 : ffffffffffffffff x8 : 7f7f7f7f7f7f7f7f 
[    5.220774] x7 : 00000000000001ff x6 : 0000000000000080 
[    5.220775] x5 : 0000000000000600 x4 : 0000000000000003 
[    5.220776] x3 : ffff0000ace48980 x2 : 0000000000000021 
[    5.257704] x1 : 0000000000000003 x0 : ffff0000ada67000 
[    5.257708] Call trace:
[    5.257728]  brcmf_sdiod_sgtable_alloc+0x130/0x138 [brcmfmac]
[    5.257736]  brcmf_sdio_probe+0x2a8/0x920 [brcmfmac]
[    5.257744]  brcmf_sdiod_probe+0x11c/0x1b0 [brcmfmac]
[    5.257752]  brcmf_ops_sdio_probe+0x140/0x1e8 [brcmfmac]
[    5.257759]  sdio_bus_probe+0x14c/0x1d0
[    5.257763]  really_probe+0x27c/0x458
[    5.257765]  driver_probe_device+0x12c/0x148
[    5.257767]  device_driver_attach+0x6c/0x90
[    5.257768]  __driver_attach+0xb0/0x160
[    5.257772]  bus_for_each_dev+0x74/0xc8
[    5.257773]  driver_attach+0x20/0x28
[    5.257775]  bus_add_driver+0x154/0x238
[    5.257776]  driver_register+0x60/0x110
[    5.257777]  sdio_register_driver+0x24/0x30
[    5.257785]  brcmf_sdio_register+0x14/0x40 [brcmfmac]
[    5.257794]  brcmf_driver_register+0xc/0x18 [brcmfmac]
[    5.257797]  process_one_work+0x1fc/0x3d0
[    5.257798]  worker_thread+0x140/0x548
[    5.257801]  kthread+0x118/0x120
[    5.257804]  ret_from_fork+0x10/0x1c
[    5.257806] ---[ end trace b4816f2be4cfa30f ]---
[    5.271786] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
[    5.280085] systemd-journald[395]: Received request to flush runtime journal from PID 1
[    5.322773] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[    5.325041] brcmfmac: brcmf_sdio_download_code_file: error -84 on writing 595758 membytes at 0x00160000
[    5.334329] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
[    5.347674] mmc0: tuning execution failed: -5
[    5.347694] brcmfmac: brcmf_sdio_htclk: Failed access turning clock off: -5
[    5.348138] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5

Do you ever meet this?

And I find an error about mmc0:

mmc0: tuning execution failed: -5

So I try to slow down the speed, disable sd-uhs-sdr50

diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 3d19b5c..86d99c1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -347,7 +347,7 @@
 
        bus-width = <4>;
        cap-sd-highspeed;
-       sd-uhs-sdr50;
+//     sd-uhs-sdr50;
        max-frequency = <100000000>;
 
        non-removable;

Now it seems been more stable, at least I can see the wlan0 node.

Yes, iā€™ve reported the same warning splat here https://patchwork.kernel.org/cover/11286567/ and Iā€™d like to run some tests with VIM3L and some other G12A and G12B devices I have to see if the issue is related to board or SoC or ā€¦ something else. Iā€™m travelling with work so it will be a couple of days before I can do much testing.

1 Like

Itā€™s not only a warning, there is en error in the end.

[    5.271786] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
[    5.280085] systemd-journald[395]: Received request to flush runtime journal from PID 1
[    5.322773] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[    5.325041] brcmfmac: brcmf_sdio_download_code_file: error -84 on writing 595758 membytes at 0x00160000
[    5.334329] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
[    5.347674] mmc0: tuning execution failed: -5
[    5.347694] brcmfmac: brcmf_sdio_htclk: Failed access turning clock off: -5
[    5.348138] brcmfmac: brcmf_sdio_htclk: HT Avail request error: -5

Load firmware failed, and mmc0 report an error, if I remove sd-uhs-sdr50 in mmc0 it works.
So Iā€™m not sure whether it is a SDIO issue.

Anyway, have a nice vacation.:slight_smile:

I added https://github.com/chewitt/linux/commit/85c6fd04de6741d4751930968ab7e1a13d14a255 to my branch, but I havenā€™t seen issues with loading firmware.

I do see errors in dmesg after connecting to a network:

Dec 19 08:08:19 VIM3 kernel: brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -5
Dec 19 08:08:19 VIM3 kernel: brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
Dec 19 08:08:47 VIM3 kernel: brcmfmac: brcmf_sdio_readframes: RXHEADER FAILED: -5
Dec 19 08:08:47 VIM3 kernel: brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame, send NAK
Dec 19 08:08:47 VIM3 kernel: brcmfmac: brcmf_sdio_hdparse: HW superframe header length error
Dec 19 08:08:47 VIM3 kernel: brcmfmac: brcmf_sdio_rxfail: abort command, terminate frame

Yes, If I remove sd-uhs-sdr50 the firmware loaded well.

I get patches from : https://github.com/chewitt/LibreELEC.tv/tree/amlogic-master/packages/linux/patches/amlogic
But this commit is not in.

Iā€™m using https://github.com/chewitt/linux/commits/amlogic-5.5-integ as a working kernel branch. I sync the commits to patches in https://github.com/chewitt/LibreELEC.tv/commits/amlogic-master every few days, but itā€™s usually behind. Everything is ā€œwork in progressā€ at the moment.

1 Like

Some update:

Linux 5.5-rc2 + AP6398S test results:

VIM2: Works without errors.
VIM3L: Works without errors.
VIM3: Works with some errors. (Need remove sd-uhs-sdr50)
Edge: Works without errors.

Stability still need to be confirm.