13:59 <ecdhe> tmlind: I set my yocto recipe to build 5.13-rc6 but ran into an error: the yocto recipe that ti ships wants the file ti_config_fragments/defconfig_builder.sh; this file is present in the commits targetted by linux-ti-mainline/linux-ti-staging but it's not present in mainline

13:59 <ecdhe> Again, just trying to reproduce (or confirm the absense of) my am3517 booting issue with this

15:33 <ecdhe> tmlind: I managed to get a build of 5.13-rc6! But it also exhibits the same error listing in the earlycon output as earlier kernels 5.4, 5.10, 5.12

15:52 <ecdhe> tmlind: on your suggestion that the n900 is an actively supported omap3 platform, I wanted to see what the difference was between it and the am3517. So I did a dependency analysis on the dts files in arch/arm/boot/dts

15:53 <ecdhe> My error listing on earlycon contains about 70 warnings like this: [ 0.000000] ti_clk_get_reg_addr: clk-provider not found for mcbsp5_gate_fck!

15:54 <ecdhe> the names, like mcbsp5_gate_fck, gpio1_dbck, wdt2_fck are all defined in omap3xxx-clocks.dtsi

15:54 <ecdhe> And the kernel appears to not like how they're nested

15:55 <ecdhe> The dependency graph for this file on the am3517-evm is: am3517-evm.dts -> am3517.dtsi -> omap3.dtsi -> omap3xxx-clocks.dtsi;

15:56 <ecdhe> But looking at the n900, it turns out it ALSO depends on this file: omap3-n900.dts -> omap34xx.dtsi -> omap3.dtsi -> omap3xxx-clocks.dtsi;

15:57 <ecdhe> So it looks like the n900 shares the problem code with the am3517-evm

16:03 <ecdhe> The ti_clk_get_reg_addr() function is failing when it doesn't find a node->parent that it considers valid

16:05 <ecdhe> The file omap3xxxx-clocks.dtsi nests all clocks in a device tree node called &prm_clocks {}. However, on omap5 the clocks are nested in the same structure: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/omap54xx-clocks.dtsi?h=v5.10.44#n454

16:06 <ecdhe> So I think the clocks in the device tree are probably actually correct, since the same structure is working for other platforms.

16:56 <ecdhe> Just tested on kernel v4.19 and still have the issue. Tried to reach back a little farther but the yocto recipe needed tweaking

17:18 <ecdhe> NishanthMenon: I have the patchwork submission address linux-omap@vger.kernel.org but wondered if there's a good email list to which I can submit a couple of questions

18:21 <ecdhe> tmlind: I found only one other example on the web of the ti_clk_get_reg_addr error in the wild, and it didn't seem to be the cause of the poster's issue. Since the dtsi files that cause it are common to a known-working platform (n900) I wonder if it's just a warning I could ignore.

18:21 <ecdhe> tmlind: here is the earlycon output I get: https://pastebin.ubuntu.com/p/9T39qWWXWQ/

18:23 <ecdhe> The only symptom I have is that I get no more output after that, and no files seem to be written to /var/tmp, /var/log (so I don't think it's booting silently to a tty I can't read.)