00:06 <hnv> like agetty?

00:34 <dmh> yea was just looking how startup does it but not sure now lol

00:46 <hnv> `/sbin/agetty --local-line 1200 ttyUSB0 vt100` _almost_ did the job on my desktop

00:48 <dmh> i was just trying similar

00:48 <dmh> now mine is stuck

01:58 <zmatt> sudo systemctl start serial-getty@ttyUSB0

02:06 <hnv> zmatt: how can I specify the baud rate?

03:01 <lucascastro> Does bb-overlays work on linux kernel mainline or just on ti linux kernel (https://github.com/beagleboard/linux)

05:05 <AKN> 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

05:07 <AKN> Include pru-icss , pruss-lld recipes still couldn't brinup the pru cores

05:11 <AKN> platform 4b226004.pruss-soc-bus: cannot lookup hwmod 'pruss1'

06:58 <rasenrhino> 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

10:40 <zmatt> lucascastro: overlays are applied by u-boot, so there's no dependency on particular kernels

10:41 <zmatt> lucascastro: of course it's still possible for specific individual overlays to depend on non-mainline things (like the gpio-of-helper driver)

10:44 <zmatt> 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

10:48 <zmatt> rasenrhino: the firmware filename can be configured via the firmware attribute in sysfs: https://pastebin.com/raw/dbvDPtdR

10:50 <zmatt> AKN: what exactly did you do to the dts?

10:56 <zmatt> AKN: it doesn't seem to me like any dts modification should be needed for pruss in ti-linux-5.10

10:57 <zmatt> oh huh

10:58 <zmatt> actually, looks like it does need a small fix

10:58 <zmatt> replace line 8: #include "dra74x.dtsi"

10:58 <zmatt> by: #include "am5728.dtsi"

11:03 <zmatt> looks like they fixed that in every am572x-based dts _except_ the beagleboneai, lol

11:12 <zmatt> 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

11:34 <zmatt> hnv: setting a specific baudrate would require a small config file to override the ExecStart of the service instance: https://pastebin.com/pgtSFfuQ

11:55 <AKN> zmatt : Thank you, Figured it out kernel 5.10.100 had am57-pruss.dtsi added it to the dts.

11:56 <AKN> pruss is alive now.

12:41 <AKN> zmatt: Hope I had seen your message sooner. I got the am57-pruss.dtsi from commit mail archive.

13:08 <hnv> thanks zmatt

13:37 <Konsgn> What actuall handles a shutdown?

13:38 <Konsgn> 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.

18:17 <zmatt> Konsgnx1: the rtc driver

18:22 <Konsgnx1> Bah, wouldn't have thought to look there

18:22 <Konsgnx1> Thank you

18:25 <zmatt> 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)

18:27 <zmatt> (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)

18:27 <Konsgnx1> Gotcha, so in custom boards, we do need to make sure we instantiate the rtc driver correctly in the device tree.

18:27 <zmatt> (note: rtc-only mode has been defeatured)

18:31 <zmatt> Konsgnx1: yup, unless you use a different pmic which doesn't work the same way

18:31 <zmatt> like, one that doesn't suck as much as the tps65217

18:32 <Konsgnx1> bahhhhhh

18:32 <Konsgnx1> &rtc {

18:32 <Konsgnx1> system-power-controller;

18:32 <Konsgnx1> }; is all thats needed it seems

18:32 <zmatt> although iirc when using the improved tps65218 it still works the same

18:32 <Konsgnx1> crap, sorry bout the newlines

18:33 <Konsgnx1> From what I've been seeing the dts have both drivers built in by default.

18:33 <zmatt> both drivers?

18:34 <zmatt> the rtc is obviously declared in am33xx.dtsi (or a dtsi included by it), like all other SoC peripherals

18:39 <zmatt> 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

18:39 <zmatt> 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

18:40 <zmatt> okay, seems to be the same in 4.19

18:41 <zmatt> although in 4.19 that's overriding the clocks and clock-names properties declared in am33xx.dtsi (which only declares "int-clk")

18:43 <zmatt> but in 5.10 those properties are gone

18:43 <zmatt> weird

18:46 <zmatt> I don't really understand how this mess in 5.10 even works

18:49 <zmatt> 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 ...

18:49 <zmatt> ...convinced was really an improvement)

19:55 <Konsgnx1> haha, now I'm confused. the kernel is panicking on shutdown

19:56 <zmatt> do you also have ti,pmic-shutdown-controller; on the pmic?

20:03 <Konsgnx1> hmm.

20:04 <Konsgnx1> just the stuff included by #include "am335x-osd335x-common.dtsi"

20:04 <Konsgnx1> so... yes i think

20:04 <zmatt> ok yep

21:36 <Guest60> Hi, is BBONE-AI Beagleboard going to be obsolete?

21:41 <Konsgnx1> Alright, I seem to be getting "WARNING: halt/1639 still has locks held!

21:41 <Konsgnx1> "

21:42 <Konsgnx1> not sure where that is coming from, prior to halt command, there is no pid of 1639