00:00 <ItsKaitlyn03> yeah i can compare, i'll take a look at it fairly soon. assuming uboot has no LCD support for allwinner and that has to be done yourself? (never touched uboot very much)

06:56 <junari> apritzel: what is better if-else or switch-case when I add lpddr4 support for h616?

08:47 <warpme> hexdump0815 : i saw your q regarding h618 stability from 22/07. (sorry for late replay: prof. life loaded me last days...) Also I see on my el-cheappo vontar box issues with a bit strange stability issue: va memory paging violations on gpu - but only when i pause (for some time) videoplayer durring playing of audio with visualizers (gl based so gpu is used). Interesting that i.e. hd video playback seems ok. next days i'll try do some

08:47 <warpme> more checks (Vgpu/Vdram/Vcpu checking; playing with Vgpu etc). Also i should have zero3 - so i will compare stability of diff. boards with h618 soc....

14:57 <apritzel> ItsKaitlyn03: LCD support is more a driver issue than Allwinner platform related. Older Allwinner tablets and some boards have LCD support, but not sure how hacked this is by today's U-Boot standards

14:58 <apritzel> junari_: typically switch/case is preferred, although it depends a bit on the specific occasion

14:59 <apritzel> warpme: those failures under high memory pressure are typical for not-quite-correct DRAM parameters - that's what the old lima-memtester was looking for

15:01 <apritzel> warpme: a quick solution could be to lower the DRAM frequency, though that's a bit chickening out from fixing the real parameters - but this is hard to do

15:02 <apritzel> it might be worth comparing the DRAM controller registers between mainline and BSP firmwares, to see if there is some difference

15:06 <warpme> apritzel : well - i'm a bit puzzeled with this issue as i'm using the same uboot (so spl) on all my H313/H616/H618 boxes. Only h618 vontar box so far has this specific issue. I have plan for 2 tests: 1)put this h618 sytem for all night live tv playback (where video pipeline has deinterlacer which is gpu shaders based - so this will be good stress test i think); 2)i will try to provoke issue on different h618 board (zerpi3) Let see

15:06 <warpme> what will happen....

15:07 <warpme> re: reading drma ctrl regs: unfortunatelly box has broken adb (ui says it is enabled) but adb not showing device (so i don't have cosole under vendor android :-( )

15:08 <warpme> drma->dram

15:17 <warpme> ram chips are micron ddr3-1600 so quite standard. I need to look on dram voltage - maybe here is something wrong?

15:29 <apritzel> normally each *board* would need specific DRAM timing parameters, considering the exact traces on the PCB. As far as we understand, some boards get those, by virtue of Allwinner providing them, somehow

15:29 <apritzel> but many boards just go with either some "safe" default values (leaving performance on the table)

15:29 <apritzel> or they just copy the parameters from some other board and hope for the best

15:31 <apritzel> so I'd say it's independent of H616 vs. H618 - from all we know I'd assume the DRAM controller is the same in these

15:31 <apritzel> the traces on the PCB play a role, though many boxes probably copy some reference design, so inherit those parameters

15:32 <apritzel> individual DRAM chips can of course also play a role

15:33 <apritzel> in the past there were extensive tests with DRAM timing parameters across several instances of the same board, and settings that worked well on most boards failed on some others

15:35 <apritzel> warpme: look for the first hits in the Wiki when just searching for "DRAM"

15:37 <warpme> apritzel: thx! will do.

19:32 <hexdump0815> warpme: thanks for your response and there is no pressure from my side, so no problem at all when it takes time :)

19:34 <hexdump0815> my impression on the h618 boxes is that they are typical tv boxes, i.e. low quality hw - they are quite cheap and one gets what one paysfor them

19:35 <hexdump0815> if i read my boxes android dtb properly it seems to have opp points for 6 or even more soc bins defined and i guess the tv boxes will usually use the worst of them

19:36 <hexdump0815> warpme: and a big thanks (to you and others involved) for all the work you put into getting all this going somehow

20:24 <apritzel> hexdump0815: so is there some common set of OPPs for all H616 SoCs?

21:32 <hexdump0815> apritzel: i would assume so - i already saw that when i looked at my h313 and h616 boxes and their dtbs and even back then they had a few different opp points depending on some hw flag

21:33 <hexdump0815> right now i'm running my h618 with h616 opps and i think warpme does so to

21:35 <hexdump0815> in the android dtb of the h618 bo there is opp-supported-hw with values 0x01, 0x0b, 0x0d, 0x2c, 0x2d, 0x50, 0x52, 0x7e, 0x7f

21:36 <hexdump0815> and the opp points have opp-microvolt-a0..opp-microvolt-a6 and not all opps are enabled for all hw and not each opp has all the microvolt levels defined

21:37 <hexdump0815> so i assume there seems to be a large zoo of different h616 versions/bins and i would guess that h313/616/618 are in principle very similar

21:39 <hexdump0815> also interesting is that my two different h618 boxes have completely different temp readings (one looks right, the other completely off), so maybe different calibrations - but all this is older temp code from warpme - will have to double check with his latest patches

21:42 <hexdump0815> apritzel: maybe time for you to get a h618 box as well? :) ... at least the ones sold from spain via ali seem to be non fake, cheap and quickly delivered

21:42 <hexdump0815> h618 boxes seem to come with axp313a by default

21:44 <apritzel> my OPi03 should arrive any time now

21:45 <apritzel> and those Spain warehouses don't deliver to UK (anymore, you know why ...)

21:46 <apritzel> hexdump0815: I was asking about the OPPs in the hope for someone sending mainline patches ;-)

22:09 <hexdump0815> apritzel: i fully understand you and support your point, but time and skill are limiting factors here and from what i read trying to upstream stuff seems to be not really a nice activity

22:10 <hexdump0815> but you are right in that if the code does not go mainline it will get lost at some point

22:10 <hexdump0815> on the other side i think people like warpme who do the first steps to make something work at all are very important too

22:11 <hexdump0815> either at some point things get upstreamed or maybe someone else i picking it up and upstreaming it

22:19 <apritzel> it would be nice if someone at least tries to upstream this: by creating one set of patches and posting them

22:19 <apritzel> so that people can start reviewing and commenting

22:21 <apritzel> it's much easier to take over an existing series from the list, than to pick patches from someone's github, where they probably miss Signed-off-by: tags and stuff

22:22 <apritzel> ItsKaitlyn03: I actually just found an A133 U-Boot support patch I hacked up last year, in one of my branches

22:39 <ItsKaitlyn03> Oh? xP

22:47 <apritzel> ItsKaitlyn03: it needs some rebase, give me some minutes, I will push it later

22:48 <ItsKaitlyn03> ah, understandable, I'm just cloning u-boot src right now to my machine

23:00 <apritzel> ItsKaitlyn03: https://github.com/apritzel/u-boot/commit/d56985d0fb4823dc1a4c367c0ce8bb25ca65700a

23:11 <ItsKaitlyn03> taking a look now

23:20 <ItsKaitlyn03> iirc doesn't a133 support ddr4?

23:31 <apritzel> yes, the whole DRAM is fake in this series

23:31 <apritzel> Even the H616 supports DDR4 already, though U-Boot doesn't yet

23:47 <ItsKaitlyn03> bought me some more solder, going to add UART to my device soontm. just forgot to get more solder, so I'm doing so now.

23:53 <apritzel> ItsKaitlyn03: I fixed the patch, so that it compiles now: https://github.com/apritzel/u-boot/commits/a133-WIP