08:21 <vigneshr> ecdhe: CONFIG_SERIAL_EARLYCON=y and CONFIG_SERIAL_8250_OMAP=y. Also DT should have stdout-path correctly

08:22 <vigneshr> ecdhe: note that earlycon won't work if a) boot loader has not configured UART instance, b) kernel fails even before DT setting up early DT

13:05 <ecdhe> vigneshr: U-Boot is talking out the uart in question so I believe a) is not an issue

13:23 <ecdhe> Does it matter that I am using linux-ti-staging on an am3517?

13:57 <ecdhe> I confirmed those config items in my kernel config, and my dts is the TI-generated one (from meta-ti through yocto) with stdout-path = "/ocp@68000000/serial@49020000";

13:58 <ecdhe> When I boot from U-Boot my bootargs include earlycon=uart8250,49020000

14:16 <vigneshr> ecdhe: I have no experience with am3517, maybe tmlind can help. But adding plain "earlycon" to cmdline args is enough as long as stdout path is set in DT. Also, try if this format helps: earlycon=uart8250,mmio32,49020000,115200n8

14:36 <ecdhe> vigneshr: earlycon by itself worked to get earlycon output!!! thanks for that breakthrough!

14:37 <ecdhe> I've got a ton of error messages, it looks like kernel-ti-staging_5.10 doesn't like the device tree it built for itself, the ti_clk_get_reg_addr() can't find a 'clk-provider' function

15:02 <ecdhe> I'm going to guess that the .dts for the am3517-evm is actually not being maintained properly compared to the kernel, and that kernel 5.10 now requires properties which were introduced more recently than the last time the am3517-evm machine in meta-ti was updated

15:02 <tmlind> ecdhe: good to hear you got earlycon working :) yeah please add chosen with stdout-path to your board specific dts file, my guess is nobody has touched am3517 stuff for few years now

15:04 <ecdhe> tmlind, bootargs=earlycon works because the device tree has the correct path so TI already has this working

15:04 <ecdhe> tmlind: if I patch the am3517-evm files, can I upstream them?

15:05 <ecdhe> or /how/ can I upstream them?

15:06 <tmlind> ecdhe: great, yes please do send patches against current mainline linux to linux-omap@vger.kernel.org list

15:10 <ecdhe> tmlind: thanks! So the am3517-evm is a 32-bit omap3 platform. Do you know if there are any omap3s that ARE still updated? beagle something? Just looking for a reference so that my fixes are consistent with common practice

15:12 <tmlind> ecdhe: yeah folks are still using other omap3 variants, probably the n900 and logicpd folks are the most active for omap3 boards

15:14 <tmlind> ecdhe: oh and gta04 folks are also actively maintaining omap3 boards

15:15 <tmlind> ecdhe: is the ethernet still working fine on am3517-evm?

15:16 <ecdhe> tmlind: I'm actually using a old logicpd som that has always been built with the am3517-evm defconfig etc

15:16 <ecdhe> I haven't got this new kernel booted yet so I don't know about ethernet

15:17 <tmlind> ecdhe: ok

15:17 <ecdhe> logicpd's devboard appears to be the reference am3517-evm, or at least a additions-only modification

15:17 <ecdhe> but they shipped kernel 2.6.37 for it (simply linking to an Ubuntu 10.04 .ova VM that TI published once with an SDK installed on it)

15:40 <ecdhe> tmlind, I'll spare you the pastebin but I have about 50 messages like: ti_clk_get_reg_addr: clk-provider not found for mcbsp5_gate_fck!

15:41 <ecdhe> I thought at first that this meant the device tree was lacking a 'clk-provider' property but looking at the n900 dts files for reference, I don't actually see any 'clk-provider' properties there either

15:43 <ecdhe> The actual error is raised here: https://elixir.bootlin.com/linux/v5.10.44/source/drivers/clk/ti/clk.c#L277

15:45 <ecdhe> This is just an iteration looking to ensure that the device tree node's parent is equal to a known clock in the array clocks_node_ptr

15:48 <ecdhe> Since the clocks it's stumbling on are defined in a file that's common to many omap3 processors (see https://elixir.bootlin.com/linux/v5.10.44/source/arch/arm/boot/dts/omap3xxx-clocks.dtsi#L89 ) I would say either my clocks_node_ptr[] array is being built incorrectly, or all omap3 processores are broken in the 5.10 kernel release and the n900 users are pinned to an older version

15:51 <tmlind> ecdhe: omap3 should be working, can you please test with v5.13-rc6? if that works then you can request upstream patches backported to 5.10.y stable series

15:52 <ecdhe> tmlind: I'll see what I can build!

18:41 <ecdhe> I reproduced the issue on 5.4, 5.10, 5.12. I'm working on 5.13-rc6, just struggling to get a yocto recipe

18:56 <NishanthMenon> ecdhe: if you add ARAGo_BRAND=mainline, it should give you 5.12 kernel

18:58 <ecdhe> NishanthMenon: add it to where?

19:02 <NishanthMenon> local.conf

19:02 <NishanthMenon> ecdhe, https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-kernel/linux/linux-ti-mainline_git.bb

19:03 <NishanthMenon> ecdhe, i made a typo ARAGO_BRAND=mainline -> if you are using meta-arago distro

19:03 <ecdhe> NishanthMenon: can you get me 5.13-rc6 with a single parameter?

19:03 <NishanthMenon> change the SRCREV

19:04 <NishanthMenon> SRCREV = "9f4ad9e425a1d3b6a34617b8ea226d56a119a717" to the upstream commit ID.. I think we should start a mainline-bleeding option that tracks upstream tags directly..

19:04 <ecdhe> I cloned linux-ti-staging_5.10.bb into linux-ti-staging_5.13-rc6.bb, then set the SRC_URI to git://git.ti.com/ti-linux-kern

19:04 <ecdhe> el/ti-linux-kernel.git;protocol=git;tag=v5.13-rc6

19:04 <NishanthMenon> that should work as well :)

19:05 <ecdhe> WARNING: linux-ti-staging-5.13-rc6-r127a do_fetch: Failed to fetch URL git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git;protocol=git;tag=v5.13-rc6

19:05 <NishanthMenon> oh.. ti-linux-kernel is probably wrong GIT_URI

19:05 <ecdhe> I know from cloning that repo that the tag exists there

19:05 <NishanthMenon> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"

19:07 <ecdhe> NishanthMenon: that's the uri in linux-ti-staging (which I'm okay with) -- the same commit hash is in both repos

19:07 <ecdhe> I will try the kernel.org link

19:07 <NishanthMenon> ecdhe, is that how you managed to test 5.12 ?

19:08 <ecdhe> NishanthMenon: no, that was the linux-ti-mainline recipe you recommended

19:08 <ecdhe> I just set PREFERRED_PROVIDER_virtual/kernel = "linux-ti-mainline" to get that

19:08 <NishanthMenon> aaah ok. that is probably the cleanest path.. i know since I personally test that recipie (unfortunately on am335x)

19:09 <NishanthMenon> all my automated omap3/am3 boards are no longer available for me :(

19:19 <ecdhe> NishanthMenon: I finally got something to pull

19:20 <NishanthMenon> Cool

19:20 <ecdhe> do_fetch() is working anyway!