09:25 <warpme> hello apritzel

09:25 <warpme> hope you had good weekend :-p

09:26 <warpme> In context of our h313 work from Friday i saw your's comment to jernej about impact of RVBAR on TF-A, and the aarch64 switch in U-Boot. Currently i'm working with jernej to fix correct dram size detection (board has 1G but spl reports 128MiB). but what catching my attention is that uboot just "stops/hangs" on spl. no any infor from atf. it pretends ljke there is no exec jump from spl to atf....

09:27 <apritzel> warpme: did you build U-Boot with a pointer to the TF-A binary?

09:31 <warpme> yes. I'm using BL31=<path to>/bl31.bin

09:31 <warpme> even if i have spl wrongly detecting ram size, i think i should see atf banner, etc

09:31 <apritzel> warpme: on the H616, TF-A is loaded to the beginning of DRAM, so if there are DRAM issues, it could also mean that TF-A doesn't work

09:32 <warpme> ok. lets then fix dram support and next we will see how it goes :-)

09:33 <apritzel> warpme: eventually you need to fix TF-A as well, as this also uses the H616 "CPU cluster control" address

09:34 <apritzel> I had some early patches (for the T507, which has the same issue), just need to dig them out

09:35 <warpme> something like this: https://controlc.com/4ac54199 ?

09:55 <apritzel> warpme: there is more to it, the whole IP block is somewhat different. Actually it seems to be the same as in the R329, which TF-A already supports

09:55 <apritzel> so my patch is refactoring the code so that a H616 can use the R329 CPU control code as a build time option

09:59 <warpme> so maybe i should simply build atf for sun50i_r329?

10:06 <apritzel> warpme: no, the R329 uses a different memory map

10:08 <warpme> ok thx! So i'm silently relaying on you!

12:26 <junari> warpme: your H313 with DDR3 ?

12:28 <junari> Ahh, I think I know what the problem

12:30 <junari> replace the phy_init values by your own

12:33 <junari> that values will be over https://github.com/jernejsk/u-boot/blob/152d1a37b4856c23976cfd0758cab654b84336cd/arch/arm/mach-sunxi/dram_sun50i_h616.c#L230

12:34 <junari> *other

12:47 <junari> in vendor u-boot md.l 0x04800000 0x200, and from 0x048000c0 values that you should replace in phy_init

13:08 <warpme> junari: yes i have h313 with ddr3 (1G ram 8x K4B1G0446E)

13:14 <warpme> junari: i dumped yesterday ram contents under running vendor android. may you help me to extract right data? Will this dump be helpful: https://controlc.com/141d3dd8

13:16 <warpme> and this maybe: https://controlc.com/620f7276

13:19 <junari> the values are the same with h616

13:22 <warpme> junari: is this mean https://github.com/jernejsk/u-boot/blob/152d1a37b4856c23976cfd0758cab654b84336cd/arch/arm/mach-sunxi/dram_sun50i_h616.c#L230 are ok for my h313 board (and effectively issue is elsewhere?)

13:23 <junari> warpme: yes

13:27 <junari> this is the only place where I saw in the disassembled driver the differences between the SoCs

13:35 <warpme> it looks h313 die i have in box seems to be a bit "different" than others h313 steepings as on Friday apritzel discovers to successful switch to aarch64 mode it needs different RVBAR (T507 like; other h313 users have successful booting with h616 uboot). Maybe this h313 steeping (or fused PROM) also impacts dram controller?

15:26 <junari> apritzel: do you know if before bootloaders for h313 and h616 was similar?

15:27 <apritzel> junari: from all we knew so far, the H313 and H616 are the same die in the same package, probably just different bins.

15:27 <apritzel> and definitely H616 builds (both U-Boot and TF-A) booted on other H313 boards before

15:28 <apritzel> (given the DRAM was supported)

15:28 <jernej> junari: afaik boot0 (vendor SPL) is same for h313 and h616, but it's important to know that it runs in 32-bit mode, so RVBAR difference doesn't matter

15:29 <apritzel> I start to wonder if those different CPU cluster blocks are controlled by some efuse or something

15:30 <apritzel> but I don't know why you would choose one over the other

15:31 <junari> looks strange

15:34 <junari> I started to make a separate plat in tf-a, but did not finish it

15:35 <junari> I was switched to another project

15:37 <junari> https://github.com/iuncuim/arm-trusted-firmware/commit/ae5e919ca178176f03cc4b4553d3f352f28bfd56

15:42 <apritzel> junari: does that work?

15:42 <apritzel> then I could take this as a reference

15:50 <junari> apritzel: I haven't checked yet because I haven't finished

15:51 <apritzel> junari: my solution was simpler, because I re-purposed the R329 code

15:53 <junari> t507 have some unique register for psci management

15:54 <junari> #define SUNXI_CPU_UNK_REG(c) (SUNXI_R_CPUCFG_BASE + 0x0070 + (c) * 4)

15:55 <daschaos> apritzel: I tested these patches and they seem to work. Couldn't test our every feature of it, but its booting and didn't get any obvious errors https://lore.kernel.org/linux-arm-kernel/20230320005249.13403-5-andre.przywara@arm.com/

15:56 <apritzel> daschaos: ah, thanks!

15:59 <daschaos> I'm happy that i can help :) I will test u-boot probably in something like two or three weeks, but i need to finish the project prototype first before i will switch from awboot to u-boot

16:24 <warpme> test

16:46 <jernej> warpme: it works

16:56 <warpme> thx. i'm constantly getting issue with irc client reconnect (after laptop sleep). and when issue happens - i see my msgs locally - but they are not appearing to others :-\

17:00 <apritzel> warpme: you could check in the archive, that picks it up pretty quickly

17:01 <warpme> indeed - in fact this is how i discovered that lastly many times i was talking exclusively to mysef....