13:58 <ecdhe> kristo: any ideas on the above pastebin? Just trying to get linux-ti-staging from yocto/meta-ti to boot on an am3517-evm platform. Defconfigs are all there, kernel builds, but at boot all I have is the earlycon output you see there.

13:59 <kristo> hmm don't have immediate thoughts, it would be good to add some printks to kernel to see why the clk-provider is not found

13:59 <ecdhe> kristo: there are other dmesg logs where this doesn't seem to be an issue

14:00 <kristo> try printing out info about the registered providers at omap2_clk_provider_init

14:00 <ecdhe> I mean, that particular error is present, but as the clocks are already configured (and linux doesn't need to reconfigure them) the boot proceeds unaffected

14:01 <ecdhe> kristo: will debug omap2_clk_provider_init to see what's going on

14:01 <kristo> having some of those prints is typically okay

14:01 <kristo> but having a huge amount like in your log, seems something goes terribly wrong

14:01 <kristo> also, print some info about the nodes being compared at ti_clk_get_reg_addr

14:02 <ecdhe> kristo: I'd bet a lunch that the array is empty

14:03 <ecdhe> And the way the array initializes is through the device tree, it is not?

14:03 <kristo> yeah, it is initialized based on DT data

14:03 <ecdhe> Which means the device tree is corrupt or the device tree loader is corrupt

14:03 <ecdhe> This seems unlikely as this issue is consistent from 4.19 to 5.13

14:04 <ecdhe> And the DT has been validated on other platforms

14:04 <ecdhe> It *could* be corrupted but I calculated my kernel/dt bounds where U-Boot loads them and they do not overlap

14:04 <ecdhe> Also, I'd assume more of a panic in that case

14:05 <kristo> so you have a custom DT? have you modified the hierarchy somehow?

14:06 <kristo> the clock driver is quite picky about the relationship of clocks and the clock-provider nodes

14:57 <ecdhe> kristo: I'm using stock dt from meta-ti

14:57 <ecdhe> the am3517-evm platform ones

15:00 <ecdhe> kristo: the am3517-evm in the 2.6.37 tree from TI works. So it may be a matter of making small jumps forward and bisecting. Tedious but could yield a solution in time.

17:50 <kristo> ecdhe: i think it would be faster just to add a few prints to see whats going wrong; also bisecting probably will just point to some generic clock driver patch which may not help too much; we have had compatibility breaks with omap platforms before