07:08 <hexdump0815> xdarklight: narmstrong: some more info below

07:09 <hexdump0815> i tried to build a kernel based on xdarklights (=arch) config and that one simply seems to lock up later in boot - might be an arch vs ubuntu thing or maybe a dtb thing

07:09 <hexdump0815> xdarklight: can you please upload your working dtb, dts and best also the kernel an modules somewhere so that i can simply try all this?

07:10 <hexdump0815> next thing is clocks in older kernels: it did not work well in older kernels - what made it look like that was that back then i had the eth phy defined in rmii mode instead of rgmii

07:12 <hexdump0815> i guess this results in it wanting a different clk freq which the ccf properly puts to the fixed clk area - with rgmii it wants another freq and for that for some reason the ccf puts it to mpll which we do not want

07:12 <hexdump0815> i tested that by also switching the older kernels to rgmii in the dtb and then they end up at mpll as well

07:13 <hexdump0815> also i think i slowly start to understand all that clock thing myself: we want the eth to be on a fixed clock and not on mpll - right?

07:15 <hexdump0815> i also found out what the dependency to the audio is: starting point due to some ccf problems we end up on mpll which is ok if no audio is loaded - https://pastebin.com/raw/ePeqj1Nn - we get out 125mhz ... then audio gets loaded and changes the mpll clocks - https://pastebin.com/raw/fMv3GbZW

07:16 <hexdump0815> as a result we no longer have the 125mhz we need and eth is not working ... the fact that audio changes the clocks seems to be ok as the audio modules seem to have some set clk symbols in them

07:17 <hexdump0815> so the goal is to somehow make the eth end up at the proper fixed clk

07:21 <hexdump0815> there are two things which might be the reason: 1. my box has really some different hw setup - or 2. legacy u-boot is usually doing some preparation the current clk/eth setup is based upon (reminder: i'm using mainline u-boot directly on the box)

07:21 <hexdump0815> regarding 1.: so far all amlogic boxes i have seem were very close to the reference design so i do not expect those ones to seriously differ in that case

07:23 <hexdump0815> regarding 2.: maybe i should check the u-boot setup code for the odroid c4 and khadas vim3l as they both are tested and do not have a legacy u-boot below and thus will have to setup everything on their own from scratch (narmstrong: any potential idea?)

07:24 <hexdump0815> i'm using the sei510/610 u-boot configs right now for my u-boot and so far all worked well - maybe i should try to find another sm1 box with legacy u-boot to cross check or to revert that box emmc to android/legacy u-boot

07:29 <hexdump0815> is there a way to maybe force the eth to end up at the proper clock - even if maybe only for testing

08:34 <hexdump0815> ok - i managed to borrow anoher such box which still has android on it (but no serial console) - here is the android clk-summary: https://pastebin.com/raw/cpENM6LF - which i think is quite useless

08:36 <hexdump0815> here is the clk summary of my old chainload booting (see to of the paste - second legacy u-boot was to fix the display problem wih the box legacy u-boot) the same disk a i booted with mainline u-boot before: https://pastebin.com/raw/r0zGynQe

08:37 <hexdump0815> eth is not working in this case - here is the eth relevant part of dmesg: https://pastebin.com/raw/HwhJZ4j1 and for comparison the mainline u-boot dmesg with working eth (no audio in both cases): https://pastebin.com/raw/EX8SfEu2

08:40 <hexdump0815> the legacy u-boot and mainline u-boot clk summaries differ a bit, but i'm not sure if that chainloading orgy i changing something too, but maybe it gives you some good base anyway

08:53 <hexdump0815> i simplyfied the chainloading now - only legacy u-boot chainloading mainline u-boot - clk-summary: https://pastebin.com/raw/S5W2e9sa

09:20 <hexdump0815> surprise: i tried to simplify the boot even more to directly load the kernel via s905_autoscript and was wondering why it was still booting my mainline u-boot although i moved it away ... in the end it looks like the box was booting the boot block on the sd card (which was still there) while still having a full android on emmc - first time i see

09:20 <hexdump0815> something like this on an amlogic box ...

09:22 <hexdump0815> wiping the boot block from the sd card stopped booting the mainline u-boot but i did not get a pure legacy kernel load working - for that a serial console would be good - does anyone have working load addresses for uinitrd, uimage and dtb for sm1 bootm?

09:51 <xdarklight> hexdump0815: with phy-mode = "rmii" it will not configure that RGMII clock tree and take whatever has been supplied by the bootloader. that however means that CCF can disable the RGMII clock tree at any point. also you may be lucky (haven't tried this): in RMII mode the SoC may output a PHY clock of 25MHz -> that matches the RGMII TX clock for 100Mbit/s connections, but not for 10Mbit/s or 1000Mbit/s connections

09:53 <xdarklight> hexdump0815: I will look into your other observations later, but it seems like we should probably ignore the second clock input

10:21 <hexdump0815> xdarklight: looking forward to your findings :)

10:22 <hexdump0815> btw. i found out why the other box was booting from sd card: looks like the emmc died ...

10:48 <hexdump0815> can it be that i have fried it with the mainline u-boot setting some wrong voltages somewhere or is it more likely just the low quality of those boxes ... initially it wa sat least still working

11:00 <xdarklight> hexdump0815: re findings: I just did the maths for my fixed_pll_dco and I am a bit surprised to see that in my calculator it gives me 4GHz straight while in clk_summary I see 3999999939Hz (off by 61Hz, which then means MPLL2 has higher precision which then means CCF will choose MPLL2)

11:00 <xdarklight> can you please pastebin your /sys/kernel/debug/regmap/dummy-system-controller@ff63c000/registers output

11:13 <xdarklight> stop, that's me. I should have had breakfast

11:30 <hexdump0815> xdarklight: this would be the dump you asked for: https://pastebin.com/raw/z8BHfFUA

11:30 <xdarklight> hexdump0815: thanks, 2a0 and 2a4 are the same on my board

13:22 <xdarklight> hexdump0815: can you please try https://pastebin.com/6Xf3yD6v on top of https://pastebin.com/MauF040X

13:23 <xdarklight> jbrunet: do you know if there's a way CCF can migrate one leaf clock from one parent to another? for Ethernet hexdump0815 is experiencing that CCF chooses MPLL2 as parent first which works fine. then as soon as the audio drivers load these change the rate of MPLL2 (which is no problem by itself). but at the same time the Ethernet clock is not updated (it should be migrated to FCLK_DIV2 as parent)

13:24 <xdarklight> so in the end MPLL2 uses the audio rate and then the RGMII TX clock is still using MPLL2 as parent (which is obviously not a multiple of 125MHz anymore...)

13:56 <hexdump0815> xdarklight: sure - will try ... can you btw. put your dtb somewhere so that i can try the kernel i compiled with your config with that to see if it no longer hangs the system that way?

13:57 <xdarklight> hexdump0815: yes, I can upload that later. but I'm sure it doesn't have audio stuff in it

15:42 <hexdump0815> xdarklight: fyi - with your latest patch (no clkin1) and the one from before i'm still ending up on mpll

15:58 <xdarklight> hexdump0815: can you please run: cat /sys/kernel/debug/clk/ff3f0000.ethernet#m250_sel/clk_possible_parents

15:59 <hexdump0815> xdarklight: fclk_div2 mpll2

16:00 <xdarklight> huh, how does it still see mpll2?

16:06 <hexdump0815> xdarklight: you mean because it is already its parent? maybe all possible parents are shown?

16:08 <xdarklight> hexdump0815: it shouldn't know about mpll2 anymore because https://pastebin.com/6Xf3yD6v removes it as possible parent

16:19 <hexdump0815> xdarklight: that patch is in for sure - maybe making clkin0 to NULL? are there any config options which might (negatively) influence this clk behaviour in a bad way maybe?

16:22 <xdarklight> hexdump0815: in your .dts "clkin0" should reference fclk_div2. and I am not aware of any Kconfig option that would have an impact on any of this