**** BEGIN LOGGING AT Thu Feb 24 02:59:56 2022 Feb 24 03:01:07 Does bb-overlays work on linux kernel mainline or just on ti linux kernel (https://github.com/beagleboard/linux) Feb 24 05:05:06 Hi, Everyone Trying to brinup the pruss core in yocto image, linux-ti-kernel 5.10.100, modified the am5729-beaglebone-ai.DTS according to the one in the Beaglebone git page build was successful but couldn't get the pruss core Shows error cannot lookup hwmod pruss1 Feb 24 05:07:41 Include pru-icss , pruss-lld recipes still couldn't brinup the pru cores Feb 24 05:11:43 platform 4b226004.pruss-soc-bus: cannot lookup hwmod 'pruss1' Feb 24 06:58:41 when i try to stop or start pru cores, i usually get an error like IO error , or "/lib/firmware/am57xx-pru1_1-fw deos not exist" any idea why this happens and how i can mitigate it Feb 24 10:40:18 lucascastro: overlays are applied by u-boot, so there's no dependency on particular kernels Feb 24 10:41:16 lucascastro: of course it's still possible for specific individual overlays to depend on non-mainline things (like the gpio-of-helper driver) Feb 24 10:44:02 rasenrhino: I mean, that error sounds pretty self-explanatory: you'll get that error if you try to start a core while its configured firmware file doesn't exist Feb 24 10:48:01 rasenrhino: the firmware filename can be configured via the firmware attribute in sysfs: https://pastebin.com/raw/dbvDPtdR Feb 24 10:50:40 AKN: what exactly did you do to the dts? Feb 24 10:56:51 AKN: it doesn't seem to me like any dts modification should be needed for pruss in ti-linux-5.10 Feb 24 10:57:30 oh huh Feb 24 10:58:09 actually, looks like it does need a small fix Feb 24 10:58:24 replace line 8: #include "dra74x.dtsi" Feb 24 10:58:29 by: #include "am5728.dtsi" Feb 24 11:03:19 looks like they fixed that in every am572x-based dts _except_ the beagleboneai, lol Feb 24 11:12:25 hnv: by default it preserves whatever baudrate the tty is already configured at, and it cycles through a list of baudrates whenever a break is detected Feb 24 11:34:39 hnv: setting a specific baudrate would require a small config file to override the ExecStart of the service instance: https://pastebin.com/pgtSFfuQ Feb 24 11:55:52 zmatt : Thank you, Figured it out kernel 5.10.100 had am57-pruss.dtsi added it to the dts. Feb 24 11:56:05 pruss is alive now. Feb 24 12:41:26 zmatt: Hope I had seen your message sooner. I got the am57-pruss.dtsi from commit mail archive. Feb 24 13:08:53 thanks zmatt Feb 24 13:37:29 What actuall handles a shutdown? Feb 24 13:38:50 I saw a reference to systemd, but what actually does the shutdown? i can't seem to find any shutdown code in the kernel drivers of tps65217. Feb 24 18:17:37 Konsgnx1: the rtc driver Feb 24 18:22:42 Bah, wouldn't have thought to look there Feb 24 18:22:44 Thank you Feb 24 18:25:56 Konsgnx1: it's because the am335x was designed to support keeping the rtc section powered while the rest of the SoC is off, so the rtc controls the on/off request line to the pmic (to also support rtc-triggered power-on) Feb 24 18:27:30 (whether an off-request turns the system fully off or into rtc-only mode is determined by the OFF config bit in the pmic which is set based on a DT property) Feb 24 18:27:31 Gotcha, so in custom boards, we do need to make sure we instantiate the rtc driver correctly in the device tree. Feb 24 18:27:50 (note: rtc-only mode has been defeatured) Feb 24 18:31:24 Konsgnx1: yup, unless you use a different pmic which doesn't work the same way Feb 24 18:31:59 like, one that doesn't suck as much as the tps65217 Feb 24 18:32:26 bahhhhhh Feb 24 18:32:26 &rtc { Feb 24 18:32:26 system-power-controller; Feb 24 18:32:26 }; is all thats needed it seems Feb 24 18:32:29 although iirc when using the improved tps65218 it still works the same Feb 24 18:32:39 crap, sorry bout the newlines Feb 24 18:33:06 From what I've been seeing the dts have both drivers built in by default. Feb 24 18:33:35 both drivers? Feb 24 18:34:03 the rtc is obviously declared in am33xx.dtsi (or a dtsi included by it), like all other SoC peripherals Feb 24 18:39:22 though weirdly in the 5.10 tree I'm noticing that the dts files (or board-specific dtsi files) are declaring 'clocks' and 'clock-names' properties on &rtc which is really strange since if those are needed they should be in am33xx-l4.dtsi, not here: https://pastebin.com/raw/uiWTfmwA Feb 24 18:39:51 I guess it's to indicate that an external 32768 Hz crystal is present? but if so, it's a bit weird that this is how you do that Feb 24 18:40:34 okay, seems to be the same in 4.19 Feb 24 18:41:28 although in 4.19 that's overriding the clocks and clock-names properties declared in am33xx.dtsi (which only declares "int-clk") Feb 24 18:43:03 but in 5.10 those properties are gone Feb 24 18:43:28 weird Feb 24 18:46:11 I don't really understand how this mess in 5.10 even works Feb 24 18:49:11 like, the target-module parent does declare a clock, but it points to a node &l4_rtc_clkctrl that merely controls the enabling of the module clock and contains no info about the actual clock source used itself... so is that now hardcoded into the kernel instead of being declared in DT ? if so, what the fuck was the point of moving from hwmods to declaring all this crap in DT instead? (which I'm not ... Feb 24 18:49:17 ...convinced was really an improvement) Feb 24 19:55:31 haha, now I'm confused. the kernel is panicking on shutdown Feb 24 19:56:51 do you also have ti,pmic-shutdown-controller; on the pmic? Feb 24 20:03:40 hmm. Feb 24 20:04:00 just the stuff included by #include "am335x-osd335x-common.dtsi" Feb 24 20:04:05 so... yes i think Feb 24 20:04:25 ok yep Feb 24 21:36:30 Hi, is BBONE-AI Beagleboard going to be obsolete? Feb 24 21:41:59 Alright, I seem to be getting "WARNING: halt/1639 still has locks held! Feb 24 21:41:59 " Feb 24 21:42:32 not sure where that is coming from, prior to halt command, there is no pid of 1639 **** ENDING LOGGING AT Fri Feb 25 02:59:56 2022