02:52 <wens> actually the ramp delay in the PMIC can be turned off. it's just on by default for the 717

02:53 <wens> you can override the ramp delay through the DT, the regulator core will use the value from the DT if provided. if you give a shorter value than what is actually needed, then things will break

03:09 <wens> but the patch in question is simply taking the delay into account. it doesn't change anything on the pmic.

13:31 <warpme> wens: "it doesn't change anything on the pmic" - i'm struggling with understanding: why changing nothing in pmic breaks boot?

13:32 <warpme> reverting only commit brings boot back

13:54 <apritzel_> warpme: I think wens meant the commit just creates a wait in the driver, before it returns success to the caller

13:54 <apritzel_> it doesnt program the PMIC differently

13:56 <warpme> apritzel: so setting ramp to 0 should bring behaviour to pre-commit state?

13:56 <warpme> state->behaviour

14:00 <BroderTuck> warpme: Yesterday, the question "With the patch reverted, do you also see the last line where kernel bring back regulator to 1.5v ?" was asked, but I do't see an answer

14:01 <warpme> "do you also see the last line where kernel bring back regulator to 1.5v" - yes. without commit i have this line as well

14:09 <BroderTuck> Ok. Now I see something tho. Early in that fail log, DRAM_VCC gets set to 1500 mv. Then that last message is about vdd-dram instead also being set to the same value (albeit in microvolts instead of milli) So vcc in one place, vdd in another.

14:21 <apritzel_> BroderTuck: that's just names, I think, for the prints. the latter comes from the DT, the former is hard coded in Syterkit

14:25 <apritzel_> warpme: did you change the voltage in Syterkit's main.c, near the end, in the main function, where it programs DCDC3?

14:26 <apritzel_> line 705 in a slightly older branch

14:29 <warpme> apritzel: L yes of course. My device uses ddr3 while syter code i modified (dram para, dram vdd) are for lpddr4

14:54 <warpme> apritzel : wait sec. it is probable that i done this in mainline syter code - but not sure about your's branch. give me sec - i'm in kodi egl rabbit hole now....

16:41 <warpme> apritzel: this is main.c i'm using: https://gist.github.com/warpme/3d1e81f9bf2826a2d1f3fb9282060f5b

16:41 <warpme> bootlog: https://gist.github.com/warpme/c8d0cbf121a2466366ab750a96ed0901

17:00 <apritzel_> warpme, ah I think that's a misunderstanding about the syterkit design: you need to change the extlinux/main.c

17:03 <apritzel_> each of those directories is a separate target binary, with quite some code duplication indeed

19:41 <Soupborsh> I am trying to understand and write dram initilisation code for b288. Here is some bsp source code. I was not bale to compile boot0 with it. IDK but it looks more simular to a23 rather than h3.

19:41 <Soupborsh> https://github.com/mirkerson/c600/blob/master/brandy/u-boot-2014.07/arch/arm/cpu/armv7/sun8iw10p1/dram/lib-dram/mctl_hal.c

21:31 <Soupborsh> I am trying to reverse engineer libdram.o blob. Ghidra decompiled it well, I need to change every _DAT_address to actual read and write to that address.

21:34 <Soupborsh> Also addresses should be changed to their macro, defined in mctl_reg.h.

21:35 <Soupborsh> That libdram.o is confirmed to work. It has more functions and does more things compared to old available version of mctl_hal.c.

23:03 <Soupborsh> How to add support for emmc in mainline U-Boot?

23:03 <Soupborsh> With emmc support it should be possible to enter usb mass storage mode and flash emmc from pc as regular drive.