10:33 <warpme> apritzel: did you ordered yours h313 box?

10:40 <warpme> junari: i have lpddr3 based box and trying to get it booting using https://github.com/iuncuim/u-boot/commits/h616-dram-lpddr3 I already created defconfig with dram para parsed from box emmc vendor android. Unfortunately detected dram size is 768MiB instead of 2G (reported by android kernel). here is uart output: https://controlc.com/23f84f6c Maybe you have free cycles to look on this issue?

13:46 <junari> warpme: I think that ram size reported by android is fake. Because vendor SPL and u-boot says: Actual DRAM SIZE =1024 M and [00.587]DRAM: 1 GiB

13:47 <junari> you can remove CONFIG_DRAM_LPDDR3_6GBIT_QUIRK=y from defconfig, after that ram size will be 1GB

19:03 <warpme> junari: perfect. Removing CONFIG_DRAM_LPDDR3_6GBIT_QUIRK indeed makes correct dram size detect :-). I checked dram chip soldered and this is indeed 1G RAM + 8G flash from Micron. This is unbelievable: they sold me 1G/8G box as 2G/16G - so is fill fill goods complaint. They sent me another "for sure"2G/16G variant. I booted android and checked reported ram size. Android reported 2G. Then i connected uart and spl says 1G. Then i checked

19:03 <warpme> chip and box has 8Gbit lpddr3 from micron. Huh....

19:06 <warpme> also interesting is that this box has h313 variant which requires mainline h616 atf - not t507 based mod required by other h313 i have (box with ddr3)

19:12 <warpme> apritzel_ : will you find spare cycles to help me to get h616/h313 int.phy Eth working on mainline uboot? I have working patch for older uboot. I updated patch for current uboot - but it not gives me working eth and i can't find why it fails.

21:29 <apritzel> warpme: I dimly remember also trying that before, but I think there was some refactoring in U-Boot that spoiled the old approach

21:30 <apritzel> plus that was a nasty hack anyway

21:30 <apritzel> once we know how the DT design would look like (and we are mostly there), we should rather try to do this properly

21:31 <apritzel> warpme: so do I get this right that you now have two H313 systems, one with the T507 CPU cluster control block, and one with the traditional H616 one?

21:33 <apritzel> I have one U-Boot patch that makes this a compile time option (to go into the defconfig), and am halfway in with making this a compile time option for TF-A as well

21:33 <apritzel> but since this seems rather random now (two devices with H313 being different), I wonder if a runtime selection would be more suitable

21:34 <warpme> yes. I have 2 variants of x96-q: 1) ddr3, axp305, h313 requiring "t507-like"atf; 2) lpddr3, axp1530(aka 313a), h313 going well with h616 atf

21:34 <warpme> so typical Chinese "mess" :-p

21:35 <apritzel> but that's great, so we can maybe figure this out now ;-)

21:35 <apritzel> can you do "sunxi-fel sid-dump" on both and compare them, especially the later bits?

21:36 <apritzel> but it's indeed a shame that both boxes use the same name (and case, I guess?)

21:38 <warpme> yes. they are really impossible to distinguish without looking inside of box

21:40 <warpme> good thing is that i have almost working lpddr3/axp313a variant: so far it looks only eth is missing

21:44 <apritzel> warpme: what version of the AXP313a Linux driver do you use? I posted v10 less than a day ago, it would be great if you could try/test this: https://lore.kernel.org/linux-sunxi/20230401001850.4988-1-andre.przywara@arm.com/

21:49 <warpme> "can you do "sunxi-fel sid-dump" on both and compare them"- sure. i'll do this tommorow. Personally - critical for me is to get int.phy eth hack working on mainline uboot (have working patch on 21052021 uboot) as this will enable me testing all others things (h313 ddr3 dram size detection, h313 lpddr3 support, atf h616 vs t507-like issue on some h313 variants, etc)

21:51 <warpme> for axp313a - currently i'using https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.2/files/0637-drivers-mfd-axp20x-add-support-for-AXP313a-PMIC.patch

21:51 <warpme> so it looks like v8

21:54 <apritzel> warpme: ah, alright, so fairly recent. No real rush, but you might want to update it if you touch that anyway

21:55 <apritzel> for Ethernet in U-Boot: why do you need that, exactly? Do you do TFTP boot, for development?

22:01 <warpme> oh eth is important for me from devel/testing automation perspective. i'm using compressed rsync delta for kernel/dtb between host and target - so any change/recompile on host i'm applying by 1 command on target; then reboot and see results. Regarding Ethernet in U-Boot - i heed this _only because_ of no support int.phy in h313/h616 in mainline kernel. currently i'm getting eth on h616/h313 boxes by: enabled by uboot + not touched by

22:01 <warpme> kernel. not nice but.....works

22:08 <apritzel> ah, I see

22:09 <apritzel> I think Armbian carries some dodgy kernel patches for the H616 internal PHY, based on some early drop from jernej?

22:10 <apritzel> they are still shady, but much better than the ugly U-Boot hack

22:13 <warpme> "Armbian carries some dodgy kernel patches for the H616 internal PHY"- ah i was not aware of this! Is it covers ac300?

22:19 <apritzel> I don't know for sure, but IIRC it was AC200 only. Is it again that some H616 come with an AC200, others with an AC300?

22:27 <warpme> oh - i'm not sure about h616 - but for sure h313 will go more and more with ac300 (and i think h616 also in future). Fortunately - it looks we know what SID bit tells us what ACx00 is used we can do universal hacks (i already have this in eth hack patch)

22:28 <warpme> apritzel : it's pleasure to talk with you but probably time to bed. all best@