09:11 <narmstrong> minute: you mean the image you get on https://www.armbian.com/bananapicm4io/ works fine ?

10:34 <minute> narmstrong: i was using Armbian_23.02.0-trunk_Bananapicm4_bullseye_current_6.0.14_minimal.img

10:35 <minute> that's what bpi were linking to

10:35 <minute> ah i see, there's a newer one at armbian. should i try it as well?

12:07 <narmstrong> minute: not sure they are based on the same kernel/dt/whatever, I pushed the initial dt on armbian

12:08 <narmstrong> but armbian have plenty of fixes & hacks, and I got reports of broken BT, not wifi

17:34 <minute> narmstrong: the version you linked has kernel 6.1 and the one i tried so far has 6.0. of course, they are using the out-of-tree driver for rtl8822cs that is the realtek driver with small changes. i also built this driver for current mainline but it doesn't seem to do anything useful (doesn't report any APs)

17:39 <minute> as the mainline rtw88 driver has been reported to work in general with rtl8822cs i would think that the problem is located on the a311d setup side... or the out of tree driver (rtl88x2cs) does something fundamentally different so the problem is not triggered

17:40 <minute> the problem also seems to appear only with bigger packets. as long as you only ping or deal with small packets, it seems like it's working. but using HTTP it falls apart

17:43 <minute> what's baffling is that the symptom is basically exactly this https://patchwork.kernel.org/project/linux-wireless/patch/20230522202425.1827005-2-martin.blumenstingl@googlemail.com/

17:43 <minute> but... the fix doesn't work for my case

17:44 <minute> moreover, the rtw_sdio_writew and rtw_sdio_readw patch _is_ required, as 16 bits writes also fail like with sunxi-mmc

17:45 <narmstrong> hmm

17:46 <narmstrong> xdarklight: can you try on your sm1 platform with the `amlogic,dram-access-quirk` property ?

17:46 <narmstrong> it should put you in the same situation as minute on the g12b

17:48 <narmstrong> since the quirk is the only way to use the sdcard controller, it also limits the sdio buffer size to 1536bytes, max_segs and a very low max_blk_count

17:48 <narmstrong> *max_segs to 1

17:48 <narmstrong> so if the upstream rtl8822cs driver doesn't have a way to split packets it will fail

17:49 <narmstrong> so far it works fine with the vendor & upstream brcm drivers, and the athk11

17:50 <minute> i have observed that, for example if you get a 12000 byte buffer, the data is ok up to a point shortly before the end

17:50 <minute> i.e. the packets contain garbage only when getting close to the end of the buffer, i.e. the last part

17:51 <minute> so i tried discarding the last part of buffers with an arbitrary cutoff (like 512 bytes), but then also some packets were lost and things stalled

17:51 <narmstrong> minute: did you try reducing the mtu to something small ?

17:52 <minute> yeah, the minimum is 1280 apparently

17:52 <minute> it doesn't fix the problem also

17:52 <narmstrong> oh ok, yeah it's bad

17:54 <minute> i'm reading and comparing the downstream code a bit...

17:55 <narmstrong> minute: this is what is used by armbian https://github.com/armbian/build/pull/5265

17:56 <minute> narmstrong: oh, that's new then

17:56 <minute> exciting

18:11 <minute> hmm, the patchset they use for 6.3 is a bit different than what is merged in 6.4

18:15 <minute> one significant difference: their patchset does not have rtw_sdio_use_memcpy_io

18:46 <minute> ok so it is a regression in the rtw88 driver

18:47 <minute> i now have a working rtw88 driver!

18:48 <minute> i did it by carefully restoring sdio.c/h and mac.c to the state from an earlier (rfc) patchset that also armbian uses

18:49 <minute> cc xdarklight

18:49 <minute> now i just need to find out which change exactly caused the regression...

19:39 <minute> hmm, rtw_sdio_rx_aggregation size/timeout are different

19:43 <minute> ah, in the older driver version, rx_aggregation was always false (not turned on), in the newer version, it is always turned on

19:45 <minute> yep, that's it!

19:45 <minute> xdarklight: narmstrong: the issue is rx_aggregation. when turned on, the problems appear.

19:57 <minute> the fix is to disable the line "rtw_sdio_enable_rx_aggregation(rtwdev);" in rtw_sdio_start

20:43 <xdarklight> minute: narmstrong: d'oh, I thought that amlogic,dram-access-quirk is part of meson-g12-common.dtsi which means that it would've been included by meson-sm1.dtsi, but it's not! great find

20:48 <narmstrong> xdarklight: it’s only on g12a and g12b but the flag should work on any meson-gx mmc slot (gxbb, gxl, … sdcard and mmc included)

20:49 <narmstrong> The fix should probably enable agregation depending on host controller capabilities

20:50 <xdarklight> narmstrong: I'm looking into making rtw88 honor the host capabilities as we speak ;)

20:54 <narmstrong> Noice!

21:12 <xdarklight> minute: weird, with amlogic,dram-access-quirk; I can't even get the firmware download (to the rtw88 chip) to work

21:15 <xdarklight> minute: only compile-tested: http://ix.io/4xMF - if I understand the rtw88 registers correctly this patch should a) keep RX aggregation enabled b) limit RX aggregation to a size that the host controller supports. if you still have trouble with this then please enable the rtw_dbg() message from that patch (easiest way: replace rtw_dbg with rtw_warn and drop the RTW_DBG_SDIO argument)

21:31 <minute> xdarklight: wow, that was quick! and this makes a lot of sense to me suddenly ^^ will test & report tomorrow