**** BEGIN LOGGING AT Tue Mar 09 02:59:57 2021 **** BEGIN LOGGING AT Tue Mar 09 03:54:28 2021 Mar 09 14:23:56 Hi Mar 09 14:24:44 I have trouble to run a script when BBB wakes up from standby sleep Mar 09 14:27:41 I tried two ways: 1. Added a script under /lib/systemd/system-sleep/myresume.sh Mar 09 14:29:07 and I created a service, enabled, tied to my script. I tested with  rtcwake -d /dev/rtc0 -m standby -s 5 Mar 09 14:29:27 both ways are not working Mar 09 14:29:53 any suggestions? Mar 09 14:31:22 That is an odd place to put a shell script. Where did you put the .service file and what did it look like? Did you enable it? Mar 09 14:31:47 I guess you said you did enable it, but showing that would help. Mar 09 14:32:58 I added a service under : /lib/systemd/system Mar 09 14:33:27 enabled using: systemctl enable Mar 09 14:33:29 you should not put anything custom in /lib Mar 09 14:33:39 custom configuration goes into /etc/systemd/ Mar 09 14:33:40 custom stuff should go in /etc/systemd/system Mar 09 14:34:12 service: Mar 09 14:34:14 [Unit] Mar 09 14:34:14 Description=MNU Resume Mar 09 14:34:15 After=suspend.target Mar 09 14:34:16 [Service] Mar 09 14:34:16 User=root Mar 09 14:34:16 Type=oneshot Mar 09 14:34:17 ExecStart=/home/debian/mnu/resume.sh Mar 09 14:34:17 TimeoutSec=0 Mar 09 14:34:18 StandardOutput=syslog Mar 09 14:34:18 [Install] Mar 09 14:34:19 #WantedBy=sleep.target Mar 09 14:34:19 WantedBy=multi-user.target sleep.target Mar 09 14:34:27 please never do that again Mar 09 14:35:02 don't paste anything multi-line into chat, use a paste service like pastebin.com Mar 09 14:37:19 hmmm Mar 09 14:38:01 ok. sorry Mar 09 14:38:25 I'm digging a bit to see what the right way is to get stuff triggered on wakeup, I've never looked into that Mar 09 14:38:41 Thank you very  much Mar 09 14:40:03 If you can help me to run a script waking up from sleep using the command : rtcwake -d /dev/rtc0 -m standby -s 3 Mar 09 14:41:46 pretty sure that bypasses systemd entirely Mar 09 14:41:51 I just tried a service from /etc/systemd/system, and it doesn't work, either Mar 09 14:42:29 if you're using rtcwake to enter suspend then you already have a logical place to do things after resume: namely right after calling rtcwake Mar 09 14:43:43 you're bypassing systemd hence none of the systemd-based mechanisms will work Mar 09 14:44:24 My goal is really not RTCWAKE, this is for me easily to test. I have to set to standby through: echo standby > /sys/power/state, then wakeup by hardware trigger Mar 09 14:44:48 if you're manually echo'ing into /sys/power/state you're still bypassing systemd Mar 09 14:45:32 (and you also have a trivial place to put post-resume actions: namely right after the echo) Mar 09 14:45:45 What if power/state is set through C program? Mar 09 14:46:35 you *are* setting it through a C program, bash is written in C :P Mar 09 14:47:46 use systemdctl to suspend from the commandline or dbus to suspend from software Mar 09 14:47:50 No. I was saying to set the state in C. Because you said echo'ing into state by-pass the sysytemd Mar 09 14:48:25 yes, directly writing to /sys/power/state is bypassing systemd, *how* you write to it is irrelevant of course Mar 09 14:48:43 normally systemd is responsible for writing to /sys/power/state Mar 09 14:49:53 I see. If using systemdctl, will be waked up through a triggering source? Mar 09 14:50:12 ? Mar 09 14:51:20 There are wakeup trigger sources, such as GPIO pin, PWR_BUT, and UART0_RXD pin. Mar 09 14:51:37 I don't actually know how wakeup conditions are configured, but I don't think it matters whether you suspend via systemd or manually, the underlying mechanism is the same either way. Mar 09 14:52:31 OK. Let me try using systemdctl, I will come back. Mar 09 14:52:52 Thank you for your help Mar 09 14:55:53 also I think you should either use sleep.target for both After and WantedBy or use suspend.target for both, not a mix of the two Mar 09 14:56:36 (sleep.target is pulled in by suspend.target, hibernate.target, and hybrid-sleep.target) Mar 09 15:49:37 How to wakeup from sleep through the command: systemctl suspend ? Mar 09 15:51:52 15:51 <@zmatt> I don't actually know how wakeup conditions are configured, but I don't think it matters whether you suspend via systemd or manually, the underlying mechanism is the same either way. Mar 09 15:52:13 Well, Mar 09 15:53:15 It doesn't wake up from suspend, while it wakes up from standby > /sys/power/state. So, there must be some different Mar 09 15:54:15 try configuring SuspendState=standby in /etc/systemd/sleep.conf Mar 09 15:55:22 (that's the string it will write to /sys/power/state) Mar 09 15:59:20 @zmatt: that works. Thank you. Mar 09 16:00:15 And, the script seems activated and run. Great! Thank you so much! Mar 09 18:12:11 hello people sorry for the inconvenience is that I just do not come out of it. I have this 10 inch display and this beaglebone (first version, white) and the related display board. I have not found any guide on how to install a system with a graphical interface to be shown on the display. With the beaglebone I was only able to install several Mar 09 18:12:11 versions of Debian that I connected to it with ssh but I was never able to see anything on the display. How can i do it? thanks! Mar 09 18:12:12 This is the product: Mar 09 18:12:12 https://chalk-elec.com/?page_id=1280#!/10-LCD-LVDS-bundle-with-capacitive-touchscreen-BeagleBone/p/13939433/category=3094860 Mar 09 18:15:38 We have several Beaglebones (Black and Black Wireless) which are powered with our custom cape over the P9 headers. The beaglebone blacks are working great, but with the beaglebone black wireless we have some promblems. sometimes they will not turn on if the power supply will be turned off and on to fast. Sometimes we have to disconnect the power Mar 09 18:15:39 supply for 1 or 2 minutes until the beaglebone black wireless will boot. Mar 09 18:17:14 for debugging we used a ttl cable connected to the beaglebone. but then this problem never apears. Mar 09 18:17:15 maza: odd, P9.05/06 are tied directly to the 5V barrel jack, so there should be no difference between powering via that or powering via P9.05/06 Mar 09 18:18:15 having to disconnect power for extended time is especially weird, that suggests you're waiting for some caps to discharge Mar 09 18:20:00 by "will not turn on" you mean not even the power led? Mar 09 18:20:21 well, sometimes the power led will blink "slowly" Mar 09 18:20:33 sometimes it will be off totaly Mar 09 18:20:38 staying on for how long? Mar 09 18:21:20 sometimes, the power led will flash in a 1 sec frequency Mar 09 18:21:26 sometimes it will never turn on Mar 09 18:21:57 with "flash" you mean the led is on very briefly? Mar 09 18:22:19 correct Mar 09 18:22:32 this sounds like there's too much current being drawn at the moment of power on Mar 09 18:22:34 i know this behaviour if the power supply is to low Mar 09 18:22:53 i saw this when i use a bad usb cable Mar 09 18:23:13 with bad usb cable i mean a long one Mar 09 18:23:17 it would definitely be a good idea to hook up a scope to monitor various supplied while this happens Mar 09 18:23:22 *supplies Mar 09 18:23:50 wer are already doing this Mar 09 18:23:51 :/ Mar 09 18:26:14 and what are the observations so far? the BBBW's wifi chip and associated supplies will no doubt increase power consumption especially at the moment of power-on (I see quite a few 1-10 uF caps and two 47 uF caps in that section of the schematic) Mar 09 18:26:50 does your cape also draw power from the beaglebone (via P9.03-04 or P9.07-08) ? if so, how much? Mar 09 18:27:54 one gotcha I know of with this pmic is that if the supply to it rises too slowly it will enter a lockup state Mar 09 18:28:45 so we are using a tiny86 chip on our board Mar 09 18:29:02 i think that works with 3.3v Mar 09 18:29:05 ill check Mar 09 18:29:39 ("too slowly" = more than 50ms) Mar 09 18:30:02 still, it doesn't sound like the pmic is locking up Mar 09 18:30:38 cycling with brief flashes of the power led means it's attempting to power on yet keeps entering fault state Mar 09 18:31:25 this is very complicated for me, but thank you a lot that you are so patient with me Mar 09 18:32:26 we are useing an atiny86 that will connect to the i2c bus. we are doing this to solve a problem on the beagleobne blacks nic chip. the network adaptor sometimes will not be recognized during booting Mar 09 18:32:51 yeah, I'm quite familiar with that problem Mar 09 18:32:55 realy Mar 09 18:33:00 wow Mar 09 18:33:10 small world Mar 09 18:33:34 note that power-cycling isn't required to resolve it, resetting (by pulling P9.10 low) suffices Mar 09 18:34:07 its occurrence can also be greatly reduced on the BBB by removing the big capacitor on the reset line Mar 09 18:34:34 it appears the ethernet phy has problems with a slowly-rising reset line (even though there's no maximum rise time specified) Mar 09 18:39:06 i think we tried P9.10 but it died not worked Mar 09 18:40:04 I've never seen or heard of a phy problem that actually required power-cycling Mar 09 18:40:26 also, why are you using this cape on a BBBW then? it doesn't have ethernet :P Mar 09 18:40:49 yes Mar 09 18:40:51 ;) Mar 09 18:41:28 the cape is new with this feature. but for this installation we need a wireless version Mar 09 18:41:48 so power-cycling is not the same as sys_reset ? Mar 09 18:43:07 anyway, there isn't enough info here to go on to debug your power issue... I suggest doing a scope measurement (on 5V input, SYS_5V, and VDD_3V3A (which can be measured on the testpoint circled in red here: https://liktaanjeneus.nl/bbbw-tp1.jpg)) to see if that gives some insight Mar 09 18:43:44 for the ethernet phy issue, in my experience using reset is just as reliable as power-cycling, if not more so Mar 09 18:46:05 though in our own application we did arrange for a way to power-cycle the beaglebone if needed, though we didn't use an external power switch, we used a diode to pull the power-button pin (P9.09) low whenever the beaglebone powers off, thus making sure it will automatically power itself back on Mar 09 18:49:46 we also used an external reset-extender on P9.10 which keeps it low for a bit longer during power-up and then causes it to rise faster (by actively driving it high through a resistor). this appears to have greatly reduced the ocurrence of the ethernet phy problem Mar 09 18:52:04 zmatt, do you know what a lanbox is ? Mar 09 18:52:26 the dmx lighting controller? Mar 09 18:53:09 yepp Mar 09 18:54:36 zmatt, i am maza Mar 09 18:54:36 lol, yes it was my dad's creation, I'm the one who write LCedit+ ages ago Mar 09 18:54:42 *wrote Mar 09 18:54:49 pm Mar 09 18:55:56 ? Mar 09 18:56:07 sorry for the confusion Mar 09 18:56:26 i need 10 minutes to adjust something Mar 09 18:56:28 btw here's a post I wrote a while back after doing extensive testing on the ethernet phy issue: https://pastebin.com/z7a7Tn4C Mar 09 19:08:05 so now i am back in the late 90´s using an irc client. Mar 09 19:08:10 :) Mar 09 19:08:15 perfekt feeling Mar 09 19:08:37 I mean, you were using an irc client before too, just one that sucked Mar 09 19:09:37 thats correct Mar 09 19:09:54 5mins Mar 09 23:18:25 e **** ENDING LOGGING AT Wed Mar 10 02:59:56 2021