06:58 <junari> jernej: t507 docs https://drive.google.com/drive/folders/1hU6O2xF_I3UEZEEXp8cP_tF7jb0OE55S?usp=sharing

08:39 <sputnik2023> @apritzel Have you tested the EMMC of the H616 under uboot?

08:40 <sputnik2023> I can only work now on a relatively low-speed clock and cannot work in high-speed mode, when the clock is greater than 12Mhz (DDR MODE) emmc read and write becomes very unstable and error-prone

08:41 <sputnik2023> @junari Have you tested the EMMC of the T507 under mainline uboot?

08:46 <sputnik2023> https://github.com/apritzel/u-boot/issues/7

09:08 <apritzel> sputnik2023: I haven't tested it lately, but I guess the issue is still there.

09:08 <apritzel> IIRC the SPL works fine (probably because it runs at a lower speed?), and Linux works fine as well

09:09 <apritzel> sputnik2023: if you want to experiment, there is a patch somewhere to enable DMA mode for MMC in U-Boot proper, my hunch is that might fix it

09:09 <sputnik2023> We tested it was fine under Linux (DDR50 and SDR150)!

09:27 <apritzel> warpme: just a heads up: the T507 SPL support patch and jernej's H616 DRAM rework haven been merged into mainline U-Boot, also there is a new version of the TF-A patches

09:28 <apritzel> warpme: so if you have any LPDDR3 patches, can you rebase and send them to the mailing list?

09:32 <warpme> apritzel : oh great. will test soon (albeit i'm forced to stay on 2021.07 uboot due int.phy Eth hacking...). Re lpddr3 code - i'm using junari code. Isn't be better when orig author will submit? (for me issue is not about submission itself - but rater about correct addressing any comments/change req. from ML regarding patch code....)

09:34 <apritzel> it's better if *someone* actually submits it ;-)

09:34 <warpme> ok. agree. let me play with this ;-)

09:35 <apritzel> my impression is that people have more issues with the submission process itself than with the technical issues

09:35 <apritzel> and we can definitely help with both, but we need some starting point

09:39 <sputnik2023> We use DDR4 on H313 and do a lot of hacking code in the mainline uboot code.

09:47 <warpme> btw: has anybody got predictable working Eth on opi3 lts (motorcomm yt8531 phy)? After some daily usage i see it is problematic regarding eth hw init at boot: half boots ends with wrong 100mbps nego and dead slow transfers. I already tried yt8531 code from net-next and also v5 patches from ML. Both hanging at boot just after phy nego - so only current 6.2 mainline works at all (partially...)

09:54 <apritzel> sputnik2023: please submit patches, so that this can be reviewed and cleaned up. No need for them to be perfect (not even close), but we need some public discussion and most importantly review

09:56 <apritzel> in my experience many of those pragmatic hacks are not only hacks, but often are the wrong and more complicated way to solve the problem

09:56 <apritzel> all of this can be discussed on the list, that's the power of Open Source

09:57 <sputnik2023> We just recently tried to produce 1000 sets of boards, wait for this 1000 sets of boards to test no problem, memory stability is no problem, I test and submit the code

09:58 <apritzel> sputnik2023: if you could do that, it would be great! But there is little reason to wait, review needs some time anyway, so if you send early, we can start to work things out already

11:29 <libv> jernej: nope

11:30 <libv> and apparently, the wiki is down as well

11:33 <libv> poked mnemoc

15:17 <jernej> junari: thanks!

15:20 <jernej> warpme: I have a lot of issues with ethernet PHY on OrangePi 3 LTS. I suspect we have some PHY init order issue, since there are also problems with AC200 EPHY initialization with latest patches.