01:09 <MasterR3C0RD> Is there a difference between the A133 and A133P/"Plus", or is it just marketing? Going to look for another device with a different DRAM setup so I can test on a non-DDR4 device

01:13 <apritzel> MasterR3C0RD: I am afraid nobody knows until you boot that device :-(

01:16 <MasterR3C0RD> The only info I can find about the A133P is that it may be a slightly overclocked version, running at 1.8GHz instead of 1.5GHz

01:16 <apritzel> I have an A133 tablet, apparently with LPDDR4: [638]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)

01:16 <apritzel> [647]DRAM SIZE =2048 MBytes, para1 = 310a, para2 = 8000000, dram_tpr13 = 7523 [655]dram_tpr11 = 241f1b22,dram_tpr12 = 12141312

01:19 <apritzel> happy to test your patches, but cannot promise much, as I couldn't really get it out of non-secure state, so no 64-bit reset, for instance

01:24 <MasterR3C0RD> Just knowing if it works on another device would be great. I'll need to port over LPDDR4 timings and double check that none of the special parameters I skipped temporarily will affect it before it'll boot on your device; also, do you have the socid/"chipid" that's printed out during UART?

01:25 <MasterR3C0RD> Similarly to the H616 there's a different phy_init that has to be loaded when the chip ID is of a certain type

01:26 <MasterR3C0RD> s/is of a certain type/matches certain values/

10:16 <apritzel> tokyovigilante: will you be able to send a v2 of the H616 audio patches? I guess it's like 2 weeks left for v6.13 material...

16:03 <junari> apritzel: tpr6 parameter is correct for LPDDR4 memory. Don't waste your time on this

16:05 <junari> If the trp10-12 parameters that I specified earlier are written down, then there should no longer be differences between the stock firmware and the mainline in the register dumps

16:07 <junari> At what point does the incorrect memory amount determination occur? Is it only a cold start without a battery?

16:11 <apritzel> that's one question I need an answer to, still. I saw it very occasionally, but never recorded under what circumstances, exactly

16:14 <apritzel> ah, I think loki666 said it happens on cold boot, and pressing the reset button "a few times" makes it eventually work

16:29 <loki666> Indeed, and I think it happened both with battery connected since last power cycle, and with battery freshly plugged in. For practical reasons I almost never power up my device via USB power

16:30 <loki666> With macromorgan TRP6 settings I didn't encounter the issue... Yet

16:32 <macromorgan> I need to double check my settings again, because I *did* encounter that issue... let me go do that

16:37 <macromorgan> my most stable settings were 0x40808080 for TPR6 along with DCDC3 set to 1100 in U-Boot

16:48 <junari> currently the default value for tpr6 is 0x3300c080 where 0x33 is the value for ddr3, 0x00 is the value for ddr4, 0xc0 is for lpddr3 and 0x80 is for lpddr4. So the value 0x40808080 is just a placebo as it does the same thing for lpddr4 memory, namely writes the value 0x80 to a specific register

16:51 <apritzel> yes, we only use one byte, but isn't it different and it writes the high byte for LPDDR4? case SUNXI_DRAM_TYPE_LPDDR4: val = para->tpr6 >> 24 & 0xff;

16:53 <apritzel> so macromorgan's change would write 0x33 instead of 0x40?

16:54 <apritzel> all LPDDR3 and DDR3 boards seem to use 0x80, but the value actually differs between the LPDDR4 boards (0x40, 0x44, 0x48)

16:59 <junari> yes, you right about byte order

17:00 <junari> For my lpddr3 board default value is 0xc0

17:03 <MasterR3C0RD> Similar controller on A133; default vref for my DDR4 is 0xa0

17:03 <apritzel> junari: but the byte order is the same between mainline and BSP code? So it's not that we mixed something up there?

17:05 <apritzel> MasterR3C0RD: is "vref" the name you found for this value? So is it something voltage related?

17:06 <junari> this thingshould be double checked

17:06 <MasterR3C0RD> apritzel: The function that writes the value is called `mctl_phy_vref_config`

17:07 <MasterR3C0RD> So assumably yes it's related to reference voltage

17:09 <MasterR3C0RD> There is a difference in how it seems to be mapped though on my A133 boot0 vs H616 U-Boot; DDR4 is TPR6 >> 8 and LPDDR3 is TPR6 >> 16, whereas on H616 LPDDR3 uses TPR6 >> 8

17:11 <MasterR3C0RD> However, DDR3 and LPDDR4 locations match up as TPR6 >> 0 and TPR6 >> 24; I haven't looked into H616 boot0 at all so I can't confirm whether that's an implementation error or a difference in handling

17:11 <MasterR3C0RD> handling in H616 boot0

17:15 <apritzel> MasterR3C0RD: thanks, I might dig into a boot0 to figure that out

17:20 <MasterR3C0RD> In other words 0x40808080 does actually change vref for tpr6, if A133 is to be believed the true default for TPR6 would be 0x33808080, as boot0 sets the default vref (when val = 0) to 0x80 for all types except LPDDR4, and 0x33 for LPDDR4

17:22 <MasterR3C0RD> val being the extracted byte from TPR6

17:33 <gamiee> apritzel: About mentioning Allwinner, it is on product page. Or you meant on different place?

17:34 <gamiee> About the UART in USB-C, I need to take look