**** BEGIN LOGGING AT Wed Dec 01 02:59:56 2021 Dec 01 14:14:09 I recently bought a BB-AI. If i plug the usb connectoer BB-AI tunrs on [ok], if i push the power button it turns off [ok], if i press again the power button just one led tuns on and after 2-3 seconds if goes down again [??]. Any idea ? Is this expected/normal ? Dec 01 15:43:31 Hi! Did someone has any working instructions on buildroot on newest kernel linux-5.10.30-ti-r3 for pocketbeagle? Dec 01 15:52:43 I have an instruction no how to build buildroot but only for kernel 4.14.18 Dec 01 18:35:30 zmatt, ping... our udev rules are really killing bootup speed, any ideas for something "else" or should we just limit the rules to default kernel drivers? Dec 01 18:46:23 zmatt, simple example, but my point. ;) https://gist.github.com/RobertCNelson/2ae048408613916b36840a24bec38dfa Dec 01 19:07:30 * zmatt looks absolutely horrified at lines 10-12 Dec 01 19:09:31 I mean, that gist shows that if you make really awful udev rules, boot time will suffer :P Dec 01 19:12:13 you were doing a recursive chrp/chmod on the sysfs dir for every single device on the system, including the bus devices that are the parent of other devices, causing basically everything in sysfs to be chgrp'd/chmodded multiple times Dec 01 19:44:35 zmatt, where does the %p expand from? i'd like to lock that to: /sys/bus/iio/devices/ Dec 01 19:44:48 %p is the device that the rule matches Dec 01 19:44:50 from: /bin/chgrp -R gpio '/sys%p' Dec 01 19:44:58 the problem isn't the action, the problem is that the rule matches every device Dec 01 19:45:24 yeap with DRIVERS=="*" that matches everyone.. Dec 01 19:45:37 even none iio devices.. Dec 01 19:45:37 DRIVERS=="*" is a pointless criterion Dec 01 19:46:14 if you want to match IIO devices, add SUBSYSTEM=="iio" Dec 01 19:47:06 is it since line 4 doesn't continue to line 10.. (thus ignoring the iio setting for subystem) ? Dec 01 19:47:33 nothing continues from line to line unless joined by escaping the line-break with \ Dec 01 19:49:18 each rule is evaluated separately Dec 01 19:49:59 thanks zmatt, someday i'll figure out udev. ;) Dec 01 19:50:35 I think udev just literally evaluates each rule one by one for each device, given that it supports flow control (GOTO) Dec 01 19:51:13 yay: 10.456s (kernel) + 41.394s (userspace) = 51.851s Dec 01 19:51:24 the main thing that's a bit annoying is that match criteria look so similar to actions Dec 01 19:51:47 this is the original i'm working on, so i'm going to fix it right now.. https://github.com/beagleboard/customizations/blob/master/etc/udev/rules.d/87-iio-noroot.rules Dec 01 19:52:06 (e.g. SUBSYSTEM=="iio" is a criterion, GROUP="gpio" is an action) Dec 01 19:54:02 that's why I often put actions on the next line indented, to make the rule clearer to read, but when doing so you need to be really careful to not forget the join the lines with a backslash Dec 01 19:55:15 so in retrospect I'm not sure whether doing so is actually a good idea, people who might edit or copy rules and overlook that small but very important detail Dec 01 19:55:42 which i had doing, when copying them between different subsystems.. Dec 01 19:55:59 cleaner right? https://github.com/beagleboard/customizations/commit/dfe535158d2cd614298bb436df5296895087dfda Dec 01 19:56:17 aka someone won't confuse it? Dec 01 19:56:31 get rid of DRIVER=="*" it does nothing but waste time Dec 01 19:56:40 also, the GROUP="iio" action got lost Dec 01 19:56:56 (which sets the group of the actual device in /dev) Dec 01 19:59:19 btw, there is an iio group, why not use that instead of gpio ? Dec 01 19:59:53 like the current rule actually does for /dev Dec 01 20:00:12 /dev/iio* I mean Dec 01 20:00:14 so both the gpio and iio "group" was something that i would add by default.. Which meant everyone started creating new groups.. i've moved to just lock everything under 'gpio".. Dec 01 20:00:42 I mean, a bit more granularity isn't a bad idea Dec 01 20:00:59 we'd ended up with gpio, iio, i2c, spi, rpmsg, remotproc, and more... Dec 01 20:01:04 dunno, maybe it doesn't matter I guess Dec 01 20:01:40 proper privilege minimization needs to be custom anyway, so I guess it doesn't matter Dec 01 20:01:41 it got messy when i added gpio support to node-red, some i/o would work, but then spi would fail, etc as the node-red user didn't have every "group" access.. Dec 01 20:01:45 so one group to make it eaiers.. Dec 01 21:42:09 Hi, Which is a simple way to run a program that's not a service, just a compiled executable on boot ? Dec 01 21:53:18 jfsimon1981: I mean... services *are* executables run on boot Dec 01 21:54:44 (see https://pastebin.com/KXVdTNrL for an example on how to create a systemd service) Dec 01 21:59:46 Ok thank you Dec 01 22:13:02 jfsimon1981: I've updated it to recommend Type=exec instead of Type=simple Dec 01 22:13:41 (Type=exec is preferred over Type=simple in almost all cases, unless you're using an ancient version of systemd that doesn't support it yet) Dec 01 22:15:06 ok Dec 01 22:17:01 actually lemme also add a remark on RemainAfterExit... Dec 01 22:17:24 done Dec 01 22:21:17 hmm, the manpage makes a good point about Type=simple still having benefits over Type=exec ... maybe I should rephrase things Dec 01 22:28:10 ok, in fact it remains active all the time Dec 01 22:28:23 (should never exit) Dec 01 22:28:33 yeah then use Type=simple or Type=exec Dec 01 22:34:07 upon further reflection, the benefits of Type=exec aren't that huge anyway... using Type=simple is fine Dec 01 22:35:29 (in situations where you'd consider Type=exec you probably actually want Type=notify and have the service report to systemd when it has successfully started) Dec 01 22:47:13 all right did work Dec 01 22:47:54 it's quite simple but first time with systemd took some time, thanks for help Dec 01 22:48:39 yeah, the basics are quite simple although there are lots and lots of options available for things like configuring dependencies and fine-tuning the environment Dec 01 22:51:02 some of our service files have more than 50 directives Dec 01 22:55:22 there's also a bunch of options related to failure handling, e.g. you can have systemd restart your service if it crashes, but if it crashes 3 times within 10 seconds have it reboot the system instead **** ENDING LOGGING AT Thu Dec 02 02:59:56 2021