00:15 <MasterR3C0RD> Kirby64: DRAM type 0x7 in the boot0 binaries I've decompiled has always been LPDDR3

00:15 <MasterR3C0RD> 0x

00:15 <MasterR3C0RD> *0x4 is DDR4

00:15 <MasterR3C0RD> 0x3 is DDR4 and 0x8 is LPDDR4

00:15 <MasterR3C0RD> *DDR3

00:21 <MasterR3C0RD> Kirby64: As for the UART port, that would depend on the device; if U-Boot shows serial outpht then whatever it's using is probably correct

00:29 <Lightsword> is it likely that this pwm driver will make sense to extend for h616 support(like in the ac200 patches) or would it likely be an entirely separate one? https://lore.kernel.org/all/20250427142500.151925-1-privatesub2@gmail.com/

00:48 <apritzel> Lightsword: there has been already a series to support the H616, based on top of this series

00:49 <apritzel> https://lore.kernel.org/linux-sunxi/20240531141152.327592-1-kikuchan98@gmail.com/

07:39 <loki666> MasterR3C0RD: so 0x7 is LPDDR3 ?

07:40 <loki666> And typical voltage is 0.92v ?

09:21 <apritzel> loki666: ah, sorry, 0x7 is indeed LPDDR3, so the voltage would need to be 1.2V

09:31 <loki666> Ah ok but I need a CONFIG flag then

09:32 <loki666> I'm also questioning the values of the PARAMS ... https://gist.github.com/loki666/24c78d7818b792d80002287ffce6eff0

09:34 <loki666> Ah no, the CONFIG flag is for DDR3

09:48 <apritzel> loki666: so this is your T527 device, right? I think there is no LPDDR3 support in the DRAM driver (yet). There are some provisions for LPDDR3, but the type member of struct dram_para wouldn't be set, it only support DDR3 and LPDDR4

09:53 <loki666> Crap

09:55 <apritzel> loki666: don't worry, I think jernej just didn't add it because he had no means to test it

09:55 <apritzel> so we just need to get him excited ;-)

17:14 <spawacz> montjoie: what u-boot are you using on D1?

19:13 <Lightsword> apritzel, so I'm trying to implement clock pwm bypass on top of that patch, for mainline do you think it makes sense to enable bypass based on an explicit device tree entry(like sunxi BSP does) or automagically(like some of the patches against mainline floating around do)?

19:24 <apritzel> definitely automatically, based on the magic frequency (and duty cycle)

19:24 <apritzel> we trigger this then by matching parameters in the pwm-clock

19:25 <apritzel> and it's also what the other PWM drivers do already, if I am not mistaken

19:28 <Lightsword> apritzel, yeah, actually looking at the bsp code again it appears to be a mixture of both automatic and explicit bypass configuration, trying to understand why they would be doing that

19:30 <apritzel> don't bother, there is not much rhyme or reason in much of the BSP code ;-)

19:32 <Lightsword> apritzel, I did confirm that the kernel patches I was using was killing the ac300 by incorrectly configuring the pwm in non-bypass mode, so it only works if I disable pwm configuration in linux at the moment, the pwm config for ac200 and ac300 appears to be essentially the same

19:34 <Lightsword> heh, I seem to get bitten fairly often if I assume vendor/BSP code is doing stuff for no reason at all, usually due to weird edge cases that end up mattering

19:37 <apritzel> well, there is often some kind of reason, but often because they painted themselves in the corner before, or don't see that the kernel already provides a much nicer solution

19:37 <apritzel> which would have all been pointed out early if they would have sent the patches to the list ..

19:41 <Lightsword> apritzel, although to be fair when it comes to handling stuff like efuse based ac200/ac300 phy selection cleanly is non-trivial as mainline doesn't really have great infrastructure for runtime configuration selection of phy's

19:43 <apritzel> ... because it's a botched design

19:44 <apritzel> that's another thing I learned: the hardware design has no consideration whatsoever for how that fits into a clean kernel design

19:44 <apritzel> best shown by them stuffing new bits wherever they find a space

19:46 <apritzel> because they have an embedded mindset, where software changes are cheap and easy, and hacks are completely acceptable

19:47 <Lightsword> apritzel, that's certainly true of a lot of hardware the kernel has to support, lots of hardware quirk special handling in general, I guess it's kinda inevitable in some ways

19:48 <Lightsword> chinese development teams tend to also be fairly heavily siloed in general in my experience

19:48 <apritzel> yes, small quirks happen, but their h/w design seems quite ignorant of the problem

19:49 <apritzel> I think it all boils down to them not getting the right feedback (or any feedback, maybe)

19:50 <apritzel> when reading the code I sometimes see where they are coming from, but someone with experience can quickly them why that's a bad idea and how to do this better

19:50 <apritzel> but they miss this step

19:50 <apritzel> ...quickly *tell* them ...

19:51 <apritzel> and they do stupid things which are a complete no-go, like "#ifdef MACH_SUN50IW9" or such

19:51 <Lightsword> apritzel, I've seen a chinese development team so heavily siloed that they thought the best way to build linux based firmware was to create their own entirely custom build system from scratch with hardcoded paths everywhere, was amazing it even worked at all

19:53 <Lightsword> oh, and they did low level hardware freq/voltage tuning by having web interface cgi code restart c binaries with different params....

20:27 <spawacz> apritzel: I disabled watchdog support in u-boot and the kew kernel booted!! \o/

20:58 <apritzel> spawacz: ah, great!

21:23 <spawacz> Now I wonder if I still will be hitting these sdcard write issues