01:10 <apritzel> so do we have any A133 boards with DDR4 memory (not LPDDR4)? Has the DRAM support been tested for those, if yes, what are the MR values to use?

09:10 <warpme> guys: i compared h616 vs rk3566 in mem transfers ( https://gist.github.com/warpme/663fd6ee809d297c41d152088509b6ac ) It is understandable ddr3 vs ddr4 gives 20..40% diff. But why mem-to-framebuffer is 10x diff? (is a53 vs a55 explanation? no...)?

09:13 <mripard> cacheable vs non-cacheable buffers ?

09:44 <apritzel> warpme: the memory subsystem in the A55 was significantly improved over the A53, so that surely contributes to the gains you see in the *normal* numbers

09:45 <apritzel> but the framebuffer differences are most likely due to cached vs. non-cached, as mripard said

09:46 <apritzel> the tinymembench docs mentions expected numbers between 100 and 300MB/s for uncached framebuffer accesses, so that looks fine

09:47 <apritzel> if you have the OrangePi Zero3, that has LPDDR4 (on A53), so you could see how much this has an impact

09:49 <apritzel> but in general we did not really do any work on optimising DRAM performance in the last years, we are just happy if it works at all and is stable ;-)

10:12 <loki666> apritzel: this is my config https://gist.github.com/loki666/3371e89ab76fc24888b96b1527508692

10:13 <loki666> it works, but I think I needed to add the detection loop hack

10:14 <apritzel> loki666: ah, cool, I was after the MRx register values, many thanks

10:14 <loki666> it was failing about 1 on 10

10:14 <apritzel> if I understood jernej correctly, those would not be board specific, but purely depending on the memory type (DDR4/LPDDR4/DDR3/LPDDR3)

10:15 <apritzel> loki666: what's the symptom when it fails? size misdetection?

10:15 <loki666> wait I'm not sure these are the settings I'm using

10:16 <loki666> apritzel: that was an old non working config... I'm using this now https://github.com/kikuchan/u-boot/blob/593a84420ae25211a99d348dad0b37585bf95276/configs/magicx_mini_zero28_a133p_defconfig

10:17 <apritzel> ok, thanks

10:18 <apritzel> jernej was reworking the size detection lately for the H616, with the aim of porting this to the H6 and A523 driver as well, I guess the A133 would join in

10:27 <loki666> apritzel: yet it was size misdetection

11:59 <apritzel> MasterR3C0RD: did you by chance manage to update the A133 DRAM "driver"? I see you agreed to most of jernej's comments to what I posted in January

11:59 <apritzel> (in here: https://lore.kernel.org/u-boot/d361206f2e25a155e67238770a140ac2@epochal.quest/)

12:01 <apritzel> I wanted to push some of the A133 U-Boot patches, but without the DRAM code this is of course all a bit theoretical

13:04 <apritzel> also if anyone with A133 devices could maybe test the sunxi-fel A133 PR and confirm there that it's working: https://github.com/linux-sunxi/sunxi-tools/pull/220

13:21 <warpme> well - here are some tests also with zero3 (lpddr4): https://gist.github.com/warpme/91c0ced506c0ec6edc9f5611eb7dfff4 With this i'm not sure that having _only_ foss code for dram init is right idea. compare this to rk world where vendor provides spl and this spl gives expected perf (not working perf). I think bringing back alternative allowing use vendor boot0 blob might be preferred by some pragmatic users who prefers perf for

13:21 <warpme> money over 100% foss purism.

13:55 <loki666> apritzel I guess I can test your sunxi-fel branch... Just never used fel so far...

13:56 <loki666> What would be a minimal test ?

13:58 <loki666> Boot device without SD card and run ./sunxi-fel --list --verbose ?

13:58 <apritzel> warpme: sorry, but there is really no alternative really to our FOSS DRAM code, we cannot really accommodate those blobs easily

14:00 <apritzel> loki666: just "sunxi-fel ver" for a start

14:00 <loki666> Ok I'll try that

14:01 <apritzel> loki666: but this wouldn't really test much, so if you have a mainline U-Boot, you should try: sunxi-fel uboot u-boot-sunxi-with-spl.bin

14:01 <apritzel> warpme: and to be honest: most of the BSP code I have seen is shockingly bad, in many aspects

14:02 <loki666> I'll use the u-boot image of my buildroot

14:02 <apritzel> warpme: And my hunch is they don't really understand the DRAM init properly either, so they copy something from the IP vendor and add random hacks that makes it work(TM) for them

14:03 <apritzel> warpme: do you see performance differences between BSP and our DRAM code? Because I think so far we just copy the BSP config, mostly bit by bit

14:04 <apritzel> warpme: so by optimisation I mean optimisations on top of the BSP reference performance, which sometimes looks lacking, just by comparing this to JEDEC parameters

14:08 <apritzel> warpme: I did this exercise once, for the F1C100s chips (because they are simpler and the co-packaged DRAM is less of a moving target): https://github.com/apritzel/u-boot/commits/suniv-dram-WIP/

14:09 <apritzel> warpme: and I got significantly better DRAM performance out of that

15:10 <junari> I'm trying to figure out the gmac1 code and adding the necessary parts from the BSP. In fact, only 700 lines of code have been added now (mostly hacks, but it is necessary for understanding further work). Right now I'm getting error 4510000.ethernet: Failed to reset the dma

15:10 <junari> https://gist.github.com/iuncuim/0553f464c76ca73f5f685db06bb2f12f

15:11 <junari> Is that part missing? https://elixir.bootlin.com/linux/v6.13.7/source/drivers/dma/sun6i-dma.c

15:13 <junari> mdio is working, it can detect link, but I get same error

16:00 <apritzel> junari: do you have an implementation of sun8i_dwmac_dma_reset(), or something hooked into struct stmmac_dma_ops.reset?

18:33 <loki666> apritzel: AWUSBFEX soc=00001855(A133) 00000001 ver=0001 44 08 scratchpad=00042200 00000000 00000000

18:35 <loki666> uboot works also

22:28 <apritzel> loki666: oh great, many thanks for testing! Is there any chance you could confirm this on the Github pull request, so that the maintainers see the confirmation there?

22:54 <loki666> apritzel: will do