12:18 <xdarklight> minute: I've been busy with my offline life for a long time but I just sent https://lore.kernel.org/linux-wireless/20231120115726.1569323-1-martin.blumenstingl@googlemail.com/T/#u - you have a similar-ish patch in your tree and been testing this for a while. could you please give your Tested-by ?

12:39 <minute> xdarklight: ok, will test! btw according to my own tests and user reports the bandwidth we get is quite low, around 20mbps

12:42 <xdarklight> minute: depending on the direction (RX or TX) this matches with what I've seen

12:44 <xdarklight> see https://lore.kernel.org/linux-wireless/20230405200729.632435-1-martin.blumenstingl@googlemail.com/ where I say: "TX throughput on a 5GHz network is between 50 Mbit/s and 90 Mbit/s" and "RX throughput on a 5GHz network is at 19 Mbit/s"

16:06 <f_> hi

16:15 <f_> xdarklight: so as said yesterday that hack with the pinmux seems to "work"

16:15 <f_> >mmc_load_image_raw_sector: mmc block read error

16:16 <f_> This time I get a different error.

16:20 <f_> oh

16:20 <f_> CMD_SEND:8 [452/1972]

16:20 <f_> ARG 0x000001aa

16:20 <f_> RET -110

16:20 <f_> CMD_SEND:55

16:20 <f_> ARG 0x00000000

16:20 <f_> RET -110

16:21 <f_> CMD8 and CMD55 both timeout?

16:22 <f_> wait..wait..

16:27 <minute> xdarklight: exactly, 20mbit on 5ghz rx

16:27 <f_> I asked #u-boot to see if there's a minified pinctrl driver..

16:32 <f_> I *just* got the boards.

16:40 <f_> lvrp16: I like the new design of the eMMC modules too

16:41 <f_> Makes me less afraid of breaking the connectors.

17:01 <f_> And they came with heatsinks too, nice.

17:07 <xdarklight> f_: is either of these errors ("mmc block read error" or -ETIMEDOUT) reproducible? also what does "[452/1972]" mean?

17:08 <f_> That [452/1972] is tmux :P

17:08 <f_> and both errors are reproducible.

17:08 <xdarklight> ah

17:14 <f_> lvrp16: BTW where's UART?

17:15 <xdarklight> f_: maybe we're looking in the wrong place. https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/tree/gxl/bl2.c#n528 clear bit 28 (strange, we're missing bit 29...). but that function enables NAND. it's called from https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/tree/gxl/bl2.c#n824 - can you check which boot device the bootrom writes to the GX_AO_SEC_GP_CFG0 register (it should be 0x1 - which means: eMMC)?

17:17 <xdarklight> ah wait, I'm looking at the bl2 code while I should be looking at the bootrom code (I think)

17:19 <f_> xdarklight: Yup, it's 0x1

17:20 <f_> in spl.c I actually check for that

17:20 <f_> xdarklight: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/tree/arch/arm/mach-meson/spl.c?h=wip/spl#n248

17:22 <f_> Oh I should rename uVar1 to boot_device, I completly overlooked storage_load because it wasn't very interesting

17:23 <xdarklight> I'm seeing that https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/tree/gxl/bl2.c#n528 also changes the pull (up/down and enabling of the internal resistors) settings for pins

17:23 <f_> lvrp16: found it.

17:25 <xdarklight> I need to do some housekeeping, then eat dinner and so a bit more for $daytime_job. I'll see if I can come up with a few more ideas later

17:25 <f_> Sure

17:26 <xdarklight> minute: I need to ask Ping-Ke about it at some point. it's especially strange since TX is much faster in my case (and TX is the "non-optimized" code-path: for RX we enable RX aggregation - for TX there's also TX aggregation but we don't support it yet)

17:27 <minute> xdarklight: interesting

17:30 <narmstrong> hmm, note on the a311d it runs on the "broken" mmc controller, meaning the performance will be limited because of an HW bug

18:36 <xdarklight> narmstrong: my RTL8822CS board is using an SM1 (S905X3) SoC, so it's not affected by the A311D SDIO controller DMA

18:37 <xdarklight> narmstrong: for sure, "copy from/to SRAM" will affect performance - but it's not clear (to me) how much

20:39 <lvrp16> f_: we color code the UART, black white green except on La Frite. ground is always towards the edge of the board

20:39 <f_> lvrp16: yeah found it

20:40 <lvrp16> I rip out all of the unnecessary blobs: https://github.com/libre-computer-project/libretech-builder-simple/blob/master/vendor/amlogic/encrypt.sh

20:40 <lvrp16> it's still huge since each of those ddrfw components is 64K...

20:41 <lvrp16> and they're all required it seems

20:42 <f_> "all required" No doubt amlogic just hardcoded that

20:43 <f_> Let's just hope g12b and sm1 boot SPL someday :)

20:44 <f_> But I don't think all of them are required at all..just that bl2 hardcodes stuff

20:45 <f_> and a lot of these fw binaries end up unused

20:45 <f_> (still have to confirm)

20:47 <f_> and aml_ddr.fw isn't actually dram firmware anyway (targets AArch64)

20:48 <f_> (they split the thing)

20:50 <f_> lvrp16: oh also noticed that BL2Z wasn't present \o/

20:50 <f_> Still curious about what it really does.

20:51 <lvrp16> there's a ton of of unused code paths in these things for various vendors

20:51 <f_> No doubt about that lol

21:13 <minute> https://icosahedron.website/@greg/111444809032989858

21:14 <minute> woops, wrong window