00:04 <libv> i actually live only 5kms or so away from that machine (hetzner)

00:04 <libv> so long cable indeed

00:06 <libv> but it seems down indeed

00:07 <libv> in-circuit is probably ddossing the wiki now ;p

00:08 <libv> actually, given the timeframes they work on, their ddos will hit us in 2032 or so ;p

00:08 <gnarface> apritzel: hey, so i put the pine64+ cpu freq governor in "performance" mode, moved the pinebook right up to it, like right up to it, and ran a bunch of tests catting various binary blobs of 20-50MB in size through it to a machine on the other side of the gig-e... i got one clocked in at nearly 2.6MB/s! (2.58MB/s) and a couple at 2.1MB/s, but most of them coming in at just about exactly 2.0MB/s... my iw station

00:08 <gnarface> dumps say the same thing as yours though

00:09 <gnarface> and i did some local tests on the pinebook (same SoC as i understand it) and it's getting ~22MB/s locally piping from microSD to /dev/null, so the bottleneck isn't there

00:09 <gnarface> (which also proves the bottleneck isn't the SDIO speed as you correctly diagnosed... but that doesn't leave a lot of other options)

00:11 <gnarface> down to maybe something wrong with the driver or hostapd unless you can replicate this behavior on your own pine64+ board

00:12 <gnarface> incidentally, were you using a direct connection or hostapd, or were you using the SDIO wifi device as a client of another, possibly higher grade, wifi router?

00:13 <gnarface> a number of times i've suspected that the spectrum crowding here is triggering some anti-congestion feature of the crda/regdb stuff that linux is handling "correctly" while all the commercial wifi devices around me are simply illegally flouting

00:44 <apritzel> mmh, I dimly remember that hostapd had (performance) issues in the past on some devices? I used it just as a client against my provider's (fairly newish) router

00:49 <gnarface> hmm, well a earlier version of hostapd did definitely have a performance issue during the wifi handshake part that was causing all my devices to time out either during connect or before even actually managing to put it in a populated list of nearby networks, but this version has otherwise been working reliably

00:53 <gnarface> definitely worth looking into again i suppose... but let me know if you get different numbers from your pine64+ board

01:11 <tokyovigilante> apritzel: still getting a usb timeout after "DRAM: 1024 MiB" in the console

01:12 <tokyovigilante> sudo ./sunxi-fel spl ../u-boot/spl/sunxi-spl.bin -> usb_bulk_send() ERROR -7: Operation timed out

01:14 <libv> well, the machine is back now

01:15 <libv> uptime is 30mins

01:15 <libv> not sure what happened there

01:33 <tokyovigilante> spl_relocate_stack_gd

01:33 <tokyovigilante> ptr: 1340079648

01:33 <tokyovigilante> doesn't seem quite right

11:14 <apritzel> tokyovigilante: ah, good point, forgot about the relocated stack!

11:16 <apritzel> so if you also set CONFIG_SPL_STACK_R_ADDR to 0x50000, that might solve it

13:57 <libv> ok, so i now got results for a10, a20, a23, a31, a64, a523, a80, a83t, h6, h616 and h700, and i can distinguish between them by process of elimination on certain values

13:58 <libv> tokyovigilante: i just extracted the dts from a 35xxp image (with its totally legal content btw ;p), and the dram_para embedded in there is totally wild

13:59 <libv> the seperate dram_para blocks are just not for this hw

14:00 <libv> and the dram section also contains some wrong fields, zq usually does not appear anymore, and odt_en is actually para0

18:04 <apritzel> libv: please note that some parameter names are not what they seem (anymore): ODT_EN used to be a boolean value, to enable or disable on-die termination

18:05 <apritzel> but for instance in the H616 it consists of eight 4-bit fields

18:05 <libv> dram_dx_odt

18:05 <apritzel> which admittedly doesn't make much sense, but IIRC jernej confirmed that this was the name used in libdram

18:06 <apritzel> no, CONFIG_DRAM_SUN50I_H616_ODT_EN

18:07 <apritzel> it's not used on every board (it depends on TPR10_DX_BIT_DELAY0 being set)

18:07 <apritzel> see orangepi_zero3_defconfig, and the code is arch/arm/mach-sunxi/dram_sun50i_h616.c

18:11 <libv> cool, will try to grab some images

18:29 <wingrime-ww> libv: https://aliexpress.ru/item/1005006190279073.html what do you think about this piece of obscure hw?

19:11 <apritzel> wingrime-ww: so that's a A133 tablet with a keyboard then, right? (it says Android 12)

19:12 <wingrime-ww> y A133p

19:13 <wingrime-ww> laptop factor 2g ram

19:15 <wingrime-ww> worst thing is power-vr I presume

19:17 <apritzel> the A133/A100 is .. meh ..., but it's not well supported mainline, mainly due to the lack of interest

19:31 <libv> at least not an SGX

19:59 <wingrime-ww> there where some news about power-vr wanted to be somehow opensoure

20:13 <apritzel> yes, some PowerVR versions have Open Source drivers now, but I am not sure if the GE8300 in the A100/A133 is covered

20:15 <apritzel> Mesa only lists three products, and the GE8300 is not among them, though the supported GX6250 is from the same "Rogue" series

23:09 <tokyovigilante> Not so good with CONFIG_SPL_STACK_R_ADDR=0x50000

23:10 <tokyovigilante> DRAM: 64 MiB

23:10 <tokyovigilante> spl_relocate_stack_gd

23:10 <tokyovigilante> ptr: 327680

23:10 <tokyovigilante> ptr: 327200

23:10 <tokyovigilante> that's ptr at start and end of spl_relocate_stack_gd, doesn't seem to be crashing there though

23:10 <tokyovigilante> seem to be running out of non-assembler parts of SPL to check

23:16 <tokyovigilante> should there be a board_init_r in board/sunxi/board.c?

23:24 <apritzel> tokyovigilante: no, we use implementation in common/spl/spl.c for the SPL, see https://linux-sunxi.org/U-Boot/Boot_process#SPL_AArch64_boot_flow

23:24 <apritzel> (at the very end)

23:25 <tokyovigilante> oh right, ta

23:25 <tokyovigilante> just wondering if it actually makes it here, will chuck some logs in

23:27 <tokyovigilante> yes

23:31 <tokyovigilante> should CONFIG_SPL_ATF be enabled?

23:35 <tokyovigilante> interestingly it doesn't make it to board_init_r without that stack relocation address change

23:35 <tokyovigilante> but with it it reports the wrong amount of DRAM

23:50 <tokyovigilante> GOT IT

23:50 <tokyovigilante> board_init_r

23:50 <tokyovigilante> spl_set_bd()

23:50 <tokyovigilante> mem_malloc_init()

23:50 <tokyovigilante> bootcount_inc()

23:50 <tokyovigilante> timer_init()

23:50 <tokyovigilante> Trying to boot from FEL

23:52 <tokyovigilante> Had CONFIG_LOG enabled, and it was hanging there for some reason (not enough memory)? Disabled that and it has gone all the way through to u-boot proper

23:52 <tokyovigilante> Starting U-Boot (0x40000000).

23:52 <tokyovigilante> Store entry point 0x40000000 to RVBAR 0x08100040, and request warm reset with RMR mode 3... done.

23:52 <tokyovigilante> nothing more in the serial console though... Still, smells like progress