Re: [beagleboard] Re: Boot is extremely slow/hangs
Really appreciate you answer... my beaglebone now boots 1:30 faster. Did
you figure out the course in the initrd?
On Tuesday, October 17, 2017 at 4:59:34 PM UTC+2, RobertCNelson wrote:
>
> On Tue, Oct 17, 2017 at 9:45 AM, Robert Nelson > wrote:
> > On Tue, Oct 17, 2017 at 9:11 AM, Robert Nelson > wrote:
> >> Hi Alexander,
> >>
> >> On Tue, Oct 17, 2017 at 7:53 AM, Alexander Rössler
> >> > wrote:
> >>> I found a workaround for the problem.
> >>>
> >>> The problems seems to be related to the images I built with the
> >>> setup_sdcard script. I used the Debian Stretch console image builder
> 9.2
> >>> with the following command:
> >>>
> ./setup_sdcard.sh --dtb beaglebone --enable-cape-universal
> --enable-uboot-cape-overlays --boot_label SandyBox --enable-systemd
> --hostname sandybox --img-4gb test.img
> >>>
> >>>
> >>> With the prebuilt image, everything works as expected. For me this
> >>> solution is okay.
> >>>
> >>> My best guess is that it has to do with the boot_label, but I have no
> clue
> >>> why it should only cause trouble with the RT kernels.
> >>
> >> It also could be the "--enable-systemd" that was only for the old
> >> "wheezy", since jessie systemd has been the default and the flag my
> >> change something else..
> >>
> >> if [ "x${enable_systemd}" = "xenabled" ] ; then
> >>cmdline="${cmdline} init=/lib/systemd/systemd"
> >> fi
> >
> > Nope, that didn't make a difference:
> >
> > debian@sandybox:~$ uname -r
> > 4.9.56-bone-rt-r7
> >
> > debian@sandybox:~$ cat /proc/cmdline
> > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
> > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
> > net.ifnames=0 quiet init=/lib/systemd/systemd cape_universal=enable
> >
> >
> > [4.573940] ALSA device list:
> > [4.573948] #0: TI BeagleBone Black
> > [4.575942] Freeing unused kernel memory: 1024K
> > [ 37.414498] EXT4-fs (mmcblk0p1): mounted filesystem with ordered
> > data mode. Opts: (null)
> > [ 37.991016] ip_tables: (C) 2000-2006 Netfilter Core Team
> >
> > debian@sandybox:~$ cat /proc/cmdline
> > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
> > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
> > net.ifnames=0 quiet cape_universal=enable
> >
> > [4.573685] ALSA device list:
> > [4.573870] #0: TI BeagleBone Black
> > [4.575851] Freeing unused kernel memory: 1024K
> > [ 34.504317] EXT4-fs (mmcblk0p1): mounted filesystem with ordered
> > data mode. Opts: (null)
> > [ 35.085202] ip_tables: (C) 2000-2006 Netfilter Core Team
>
> Bingo, it's the initrd.img.. This is only really needed for 3.8.13,
> "kernel overlays" (which are now, not recommended)..
>
> [4.133706] PM: Hibernation image not present or could not be loaded.
> [4.133987] ALSA device list:
> [4.133997] #0: TI BeagleBone Black
> [4.147398] EXT4-fs (mmcblk0p1): mounted filesystem with ordered
> data mode. Opts: (null)
> [4.147467] VFS: Mounted root (ext4 filesystem) readonly on device
> 179:1.
>
> So double check:
>
> cat /proc/cmdline
>
> that's using, root=/dev/mmcblk*
>
> and that /etc/fstab
>
> has "/dev/mmcblk*"
>
> (aka no UUID)
>
> Then your safe to do:
>
> sudo rm /boot/initrd.img-4.*
>
> I'll keep testing, as something in the initrd is blocking the RT kernel..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/88ecb2de-3c62-4a02-91ea-ae83b1f53088%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Using PTP with Beaglebone black
I am a student trying to implement PTP using BBB. I have studied that there are BBB images that already have HW timestamps enabled. Is there any easy way that I can follow to implement PTP without having to compile a Linux kernel by myself? Any help in this regard is much appreciated. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/af3e19bb-94ed-410d-b259-2185b23075ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel
On 12/6/2018 1:59 PM, Jeff Andich wrote: > Hi, > > General question. > > Is it valid to cross compile an out of tree driver with a different version > of the cross compiler/toolchain than the kernel was compiled with? If not, > where do you draw the line? > > Recently we re-compiled an out of tree WiFi driver for the BBB on a PC host > machine, pointing it at the kernel source tree with all of the build > products/generated files in it. The kernel was built with the 6.4.x Linaro > toolchain, however the developer built the WiFi driver with the Linaro 5.4 > toolchain. The developer was able to deploy the WiFi driver to the target, > and it worked just fine. > > I mentioned to the developer that, in general, it's probably safer to use > the same brand and version of the cross toolchain to build the driver and > kernel, but now I'm so sure that this has to be the case. For instance, If > the function call interface is standard for all versions of the Linaro > toolchain, then maybe this doesn't matter. However, if version 4.x uses > one set of registers to pass function parameters to a driver, for instance, > and the driver is compiled with a different version of the compiler which > expects the parameters to be passed in a different set of registers, then > there would be an issue. > > What's the rule of thumb here or what's a good reference to better > understand the interfaces? What you mentioned (register use and parameter passing) is known as calling conventions, which are part of the full ABI (Application Binary Interface) which specifies those and other details of the target platform: https://en.wikipedia.org/wiki/Application_binary_interface As long as the ABI is compatible, you should be able to compile kernel modules using whatever compiler you want. There are lots of different ABIs for the ARM platform because there are a wide range of CPUs with different features (eg: hard floating point, NEON support, thumb instructions, etc). That's why you wind up with long lists of cross-compiler tool chain variants, eg: https://releases.linaro.org/components/toolchain/binaries/latest-7/ -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/64a4c107-f9e9-56f6-1e8e-acbfaca71677%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Debian 9: autorun on boot with systemd does not work
I am really lost here. I have a working application on the BBB platform running Debian from a couple of years ago. It was not easy but I got it completely running, automatically. Now I am trying for two weeks to upgrade to Debian 9.5 and I find the i2c busses are interchanged and hard to use, the autorun does not work anymore and it was pretty hard to get a standard display (4D Systems) working in the first place. To run automatically an application crontab is the wrong way, that is clear, so I tried Services. Services are also not working. Is there any alternative? Do I really waste my time trying to use a BBB? I was not planning to get a PhD in programming. I am a RF user/amateur willing to learn, but this is too hard for me. Sorry if I sound a bit frustrated but this is where I got. I hope some newer version of Debian will all rectify this. Anyway, thanks for your time Jim! Many people are willing to help but in this case it seems without result. Best regards, Harke On Thu, 6 Dec 2018 at 18:48, Jim F wrote: > I was actually thinking you should make sure you run the exact same > python. So if your exec start line says /usr/bin/python2.7 aceme.py then > you should run that. Then pay attention to the comments about the > pythonpath in my previous email. > > But your other descriptions are not promising. I don't think you should be > using a systemd service to start an interactive application with a display. > Usually systemd services are headless. Perhaps I am mistaken there. It > certainly is not typically used that way. > > Jim > > On Thu, Dec 6, 2018, 3:57 AM Harke Smits wrote: > >> Hi Jim, >> >> No problem, I can do that, in fact I have done that many times with the >> same results. I can enter: cd /home/debian/eme/ and then: python aceme.py >> or I can enter: python /home/debian/eme/aceme.py. That works in both ways >> exactly the same. When run under the bash it gives an error saying that >> Tkinter does not work because of a $Display error. When run under QTerminal >> in LXQT it works fine. This is the reason that I must be sure in the >> service file that the graphics modules are loaded first. In fact this is >> the (only) way to start the application. >> Conclusion: the command line: python /home/debian/eme/aceme.py works >> perfectly. However, this is not what I need to put after: ExecStart (as far >> as I understand). Now I have: ExecStart=/home/debian/eme/aceme.py. And >> I made aceme.py executable. >> I do not know bash scripts so if necessary please help me here. >> I hope this helps in the analysis. >> Best regards, >> Harke >> >> >> >> >> On Wed, 5 Dec 2018 at 21:46, Jim F wrote: >> >>> Harke, >>> >>> You should try running your script from the cli using the exact same >>> command you use for the exec start line in your service file. It should >>> give you the same errors you are seeing. That would be good. If not, the >>> problem is that your environment doesn't match. It will probably end up >>> being your PYTHONPATH. In that case you may want to write a short bash >>> script which sets the path and runs your python script, and using that for >>> your exec start command. >>> >>> Fundamentally your python doesn't know where the libraries you want are >>> installed. PYTHONPATH is the environment variable which tends python where >>> to look. Copy the one from your environment and export it in your bash >>> script. >>> >>> Jim >>> >>> On Wed, Dec 5, 2018, 2:50 PM Harke Smits wrote: >>> login as: debian debian@Beaglebone's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Dec 5 18:01:26 2018 from 2001:982:c7c1:1:a96e:5bfc:cb2a:81a7 debian@beaglebone:~$ sudo systemctl status aceme [sudo] password for debian: ● aceme.service - to invoke aceme.py automatically Loaded: loaded (/etc/systemd/system/aceme.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2018-12-05 19:39:44 UTC; 3min 50s ago Process: 986 ExecStart=/home/debian/eme/acemev35.py (code=exited, status=1/FAILURE) Main PID: 986 (code=exited, status=1/FAILURE) Dec 05 19:39:40 beaglebone systemd[1]: Started to invoke aceme.py automatically. Dec 05 19:39:44 beaglebone python[986]: Adafruit_BBIO: version initialized Dec 05 19:39:44 beaglebone acemev35.py[986]: Traceback (most recent call last): Dec 05 19:39:44 beaglebone acemev35.py[986]: File "/home/debian/eme/acemev35.py", line 21, in Dec 05 19:39:44 beaglebone acemev35.py[986]: import serial # serial control module Dec 05 19:39:44 beaglebone acemev35.py[986]: ImportError: No module named
[beagleboard] Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel
Hi, General question. Is it valid to cross compile an out of tree driver with a different version of the cross compiler/toolchain than the kernel was compiled with? If not, where do you draw the line? Recently we re-compiled an out of tree WiFi driver for the BBB on a PC host machine, pointing it at the kernel source tree with all of the build products/generated files in it. The kernel was built with the 6.4.x Linaro toolchain, however the developer built the WiFi driver with the Linaro 5.4 toolchain. The developer was able to deploy the WiFi driver to the target, and it worked just fine. I mentioned to the developer that, in general, it's probably safer to use the same brand and version of the cross toolchain to build the driver and kernel, but now I'm so sure that this has to be the case. For instance, If the function call interface is standard for all versions of the Linaro toolchain, then maybe this doesn't matter. However, if version 4.x uses one set of registers to pass function parameters to a driver, for instance, and the driver is compiled with a different version of the compiler which expects the parameters to be passed in a different set of registers, then there would be an issue. What's the rule of thumb here or what's a good reference to better understand the interfaces? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3c60199f-1830-4455-acbd-7f24bf46db01%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Need || SalesForce Lead Developer || Century City, CA || 6 Months
Dear Associates, Hope you are doing good. Please review the job below & revert back with the suitable profiles along with Current Location, Current Work authorization, contact details & expected hourly C2C(All Inclusive) pay rate to *vams...@svktechinc.com* *Job Title: SalesForce Lead Developer* *Location: Century City, CA* *Experience: 9-10 Years* *Duration: 6 Months* *Visa Status: H1B, GC, Citizens.* *MOI: Telephonic & F2F or Skype.* *Mandatory Skills: * · Sales Cloud, Visualforce · Architect/Lead/developer 10 + years · Hands on experience on salesforce · Salesforce certified architect/developer *Job Description:* · Sales Cloud : 6-8 years of experience. · Strong Visualforce and Apex development skills · Understanding of integration with SF and enterprise systems · Dev I and 2 certified. Other platform certifications desirable. · Person should have strong hands on development experience on these aspects and should be able to work independently delivering on the assigned responsibilities. *Thanks & Regards,* *Vamsheedhar* *vams...@svktechinc.com* *609-904-0020* -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF0CA4vAjdRCnbC0C0k02zYjOtZ5UAkfpciXvqMmcNQh8ET%2Bhg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Debian 9: autorun on boot with systemd does not work
I was actually thinking you should make sure you run the exact same python. So if your exec start line says /usr/bin/python2.7 aceme.py then you should run that. Then pay attention to the comments about the pythonpath in my previous email. But your other descriptions are not promising. I don't think you should be using a systemd service to start an interactive application with a display. Usually systemd services are headless. Perhaps I am mistaken there. It certainly is not typically used that way. Jim On Thu, Dec 6, 2018, 3:57 AM Harke Smits wrote: > Hi Jim, > > No problem, I can do that, in fact I have done that many times with the > same results. I can enter: cd /home/debian/eme/ and then: python aceme.py > or I can enter: python /home/debian/eme/aceme.py. That works in both ways > exactly the same. When run under the bash it gives an error saying that > Tkinter does not work because of a $Display error. When run under QTerminal > in LXQT it works fine. This is the reason that I must be sure in the > service file that the graphics modules are loaded first. In fact this is > the (only) way to start the application. > Conclusion: the command line: python /home/debian/eme/aceme.py works > perfectly. However, this is not what I need to put after: ExecStart (as far > as I understand). Now I have: ExecStart=/home/debian/eme/aceme.py. And > I made aceme.py executable. > I do not know bash scripts so if necessary please help me here. > I hope this helps in the analysis. > Best regards, > Harke > > > > > On Wed, 5 Dec 2018 at 21:46, Jim F wrote: > >> Harke, >> >> You should try running your script from the cli using the exact same >> command you use for the exec start line in your service file. It should >> give you the same errors you are seeing. That would be good. If not, the >> problem is that your environment doesn't match. It will probably end up >> being your PYTHONPATH. In that case you may want to write a short bash >> script which sets the path and runs your python script, and using that for >> your exec start command. >> >> Fundamentally your python doesn't know where the libraries you want are >> installed. PYTHONPATH is the environment variable which tends python where >> to look. Copy the one from your environment and export it in your bash >> script. >> >> Jim >> >> On Wed, Dec 5, 2018, 2:50 PM Harke Smits wrote: >> >>> login as: debian >>> debian@Beaglebone's password: >>> >>> The programs included with the Debian GNU/Linux system are free software; >>> the exact distribution terms for each program are described in the >>> individual files in /usr/share/doc/*/copyright. >>> >>> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent >>> permitted by applicable law. >>> Last login: Wed Dec 5 18:01:26 2018 from >>> 2001:982:c7c1:1:a96e:5bfc:cb2a:81a7 >>> debian@beaglebone:~$ sudo systemctl status aceme >>> [sudo] password for debian: >>> ● aceme.service - to invoke aceme.py automatically >>>Loaded: loaded (/etc/systemd/system/aceme.service; enabled; vendor >>> preset: enabled) >>>Active: failed (Result: exit-code) since Wed 2018-12-05 19:39:44 UTC; >>> 3min 50s ago >>> Process: 986 ExecStart=/home/debian/eme/acemev35.py (code=exited, >>> status=1/FAILURE) >>> Main PID: 986 (code=exited, status=1/FAILURE) >>> >>> Dec 05 19:39:40 beaglebone systemd[1]: Started to invoke aceme.py >>> automatically. >>> Dec 05 19:39:44 beaglebone python[986]: Adafruit_BBIO: version >>> initialized >>> Dec 05 19:39:44 beaglebone acemev35.py[986]: Traceback (most recent call >>> last): >>> Dec 05 19:39:44 beaglebone acemev35.py[986]: File >>> "/home/debian/eme/acemev35.py", line 21, in >>> Dec 05 19:39:44 beaglebone acemev35.py[986]: import serial >>> # serial control module >>> Dec 05 19:39:44 beaglebone acemev35.py[986]: ImportError: No module >>> named serial >>> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Main process >>> exited, code=exited, status=1/FAILURE >>> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Unit entered >>> failed state. >>> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Failed with result >>> 'exit-code'. >>> debian@beaglebone:~$ >>> >>> >>> here is the status of aceme.service immediately after booting. It is >>> clear that serial is loaded on my system, as I use it extensively in the >>> same program script loaded. >>> login as: debian >>> debian@Beaglebone's password: >>> >>> The programs included with the Debian GNU/Linux system are free software; >>> the exact distribution terms for each program are described in the >>> individual files in /usr/share/doc/*/copyright. >>> >>> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent >>> permitted by applicable law. >>> Last login: Wed Dec 5 18:01:26 2018 from >>> 2001:982:c7c1:1:a96e:5bfc:cb2a:81a7 >>> debian@beaglebone:~$ sudo systemctl status aceme >>> [sudo] password for debian: >>> ● aceme.service - to invoke aceme.py automatically >>>Loaded: loaded
Re: [beagleboard] New TI 64-bit SoC
On Thu, Dec 6, 2018 at 9:02 AM Bill Barnett wrote: > > Interesting post on LinuxGizmos.com: > > http://linuxgizmos.com/tis-first-64-bit-soc-debuts-on-linux-driven-phytec-module/ > > The text mentions possible upgrades to the BeagleBoard-X15 and the BeagleBone. Ah "marketing" it's "64-bit" so it "must" be "better"... Remember the "X15" uses a Dual Cortex-A15, with the AM6x you 2 or 4 Cortex-A53.. If we look at this benchmark chart: https://www.cnx-software.com/2015/04/09/relative-performance-of-arm-cortex-a-32-bit-and-64-bit-cores/ An AM6x based X15 would have to be quad, to even be "faster" then the current AM5x X15.. The AM6x also doesn't have the the DSP or EVE, which are really the best features of the AM5x/X15.. And yes, i do have an AM6x, i do think it'll be a nice part for TI, i'm just sad at the removal of other IP blocks from the AM5x family.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjd%2BS_N6Ofcf%2BT6E%2BrvuA5KPr7Qh62-y-FKsDOi6vVuYg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] New TI 64-bit SoC
Interesting post on LinuxGizmos.com: http://linuxgizmos.com/tis-first-64-bit-soc-debuts-on-linux-driven-phytec-module/ The text mentions possible upgrades to the BeagleBoard-X15 and the BeagleBone. -- Bill Barnett -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAP4vyadPgZF0sTv24jJHJp0ve3YkW8NVWkB_4U8HmqRdNSRGrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Network IP address assignments
Richard wrote: > [-- multipart/alternative, encoding 7bit, 107 lines --] > > [-- text/plain, encoding 7bit, charset: UTF-8, 50 lines --] > > Hi! I'm having difficulty understanding and modifying the BBBW network > configuration. > > At boot on the BBBW, somehow, these IP addresses are assigned > SoftAP0: 192.168.8.1 > lo: 127.0.0.1 This is the 'loopback' address and is basically hard-coded and is the same on all systems (though it can be anything in the 127.0.x.x range). It's the address of the (BBB) system itself. Don't try and modify it, it's fundamental to the way IPV4 networks work. > usb0: 192.168.7.2 > usb1: 192.168.6.2 These two addresses are (I think) assigned by the USB drivers in some way, I'm not very familiar with this. > wlan0: 192.168.1.xxx > This address is (almost always) set by the DHCP server on the LAN, it's not set by the BBB at all. The DHCP server is probably a router though it can be another computer on the LAN. The address given to the BBB will usually be the same each time it's booted but it isn't necessarily so. The range of addresses assigned by the DHCP server is usually configurable in the router/DHCP server. (N.B. I've summarised a lot and skipped over lots of details and bits I'm not familiar with, don't take the above as a full description of how it works. There are, for example, other ways the wlan0 address might be set, I've just described the most likely one). -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5v6ndf-ua9.ln1%40esprimo.zbmc.eu. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Debian 9: autorun on boot with systemd does not work
Hi Jim, No problem, I can do that, in fact I have done that many times with the same results. I can enter: cd /home/debian/eme/ and then: python aceme.py or I can enter: python /home/debian/eme/aceme.py. That works in both ways exactly the same. When run under the bash it gives an error saying that Tkinter does not work because of a $Display error. When run under QTerminal in LXQT it works fine. This is the reason that I must be sure in the service file that the graphics modules are loaded first. In fact this is the (only) way to start the application. Conclusion: the command line: python /home/debian/eme/aceme.py works perfectly. However, this is not what I need to put after: ExecStart (as far as I understand). Now I have: ExecStart=/home/debian/eme/aceme.py. And I made aceme.py executable. I do not know bash scripts so if necessary please help me here. I hope this helps in the analysis. Best regards, Harke On Wed, 5 Dec 2018 at 21:46, Jim F wrote: > Harke, > > You should try running your script from the cli using the exact same > command you use for the exec start line in your service file. It should > give you the same errors you are seeing. That would be good. If not, the > problem is that your environment doesn't match. It will probably end up > being your PYTHONPATH. In that case you may want to write a short bash > script which sets the path and runs your python script, and using that for > your exec start command. > > Fundamentally your python doesn't know where the libraries you want are > installed. PYTHONPATH is the environment variable which tends python where > to look. Copy the one from your environment and export it in your bash > script. > > Jim > > On Wed, Dec 5, 2018, 2:50 PM Harke Smits wrote: > >> login as: debian >> debian@Beaglebone's password: >> >> The programs included with the Debian GNU/Linux system are free software; >> the exact distribution terms for each program are described in the >> individual files in /usr/share/doc/*/copyright. >> >> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent >> permitted by applicable law. >> Last login: Wed Dec 5 18:01:26 2018 from >> 2001:982:c7c1:1:a96e:5bfc:cb2a:81a7 >> debian@beaglebone:~$ sudo systemctl status aceme >> [sudo] password for debian: >> ● aceme.service - to invoke aceme.py automatically >>Loaded: loaded (/etc/systemd/system/aceme.service; enabled; vendor >> preset: enabled) >>Active: failed (Result: exit-code) since Wed 2018-12-05 19:39:44 UTC; >> 3min 50s ago >> Process: 986 ExecStart=/home/debian/eme/acemev35.py (code=exited, >> status=1/FAILURE) >> Main PID: 986 (code=exited, status=1/FAILURE) >> >> Dec 05 19:39:40 beaglebone systemd[1]: Started to invoke aceme.py >> automatically. >> Dec 05 19:39:44 beaglebone python[986]: Adafruit_BBIO: version >> initialized >> Dec 05 19:39:44 beaglebone acemev35.py[986]: Traceback (most recent call >> last): >> Dec 05 19:39:44 beaglebone acemev35.py[986]: File >> "/home/debian/eme/acemev35.py", line 21, in >> Dec 05 19:39:44 beaglebone acemev35.py[986]: import serial >># serial control module >> Dec 05 19:39:44 beaglebone acemev35.py[986]: ImportError: No module named >> serial >> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Main process >> exited, code=exited, status=1/FAILURE >> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Unit entered failed >> state. >> Dec 05 19:39:44 beaglebone systemd[1]: aceme.service: Failed with result >> 'exit-code'. >> debian@beaglebone:~$ >> >> >> here is the status of aceme.service immediately after booting. It is >> clear that serial is loaded on my system, as I use it extensively in the >> same program script loaded. >> login as: debian >> debian@Beaglebone's password: >> >> The programs included with the Debian GNU/Linux system are free software; >> the exact distribution terms for each program are described in the >> individual files in /usr/share/doc/*/copyright. >> >> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent >> permitted by applicable law. >> Last login: Wed Dec 5 18:01:26 2018 from >> 2001:982:c7c1:1:a96e:5bfc:cb2a:81a7 >> debian@beaglebone:~$ sudo systemctl status aceme >> [sudo] password for debian: >> ● aceme.service - to invoke aceme.py automatically >>Loaded: loaded (/etc/systemd/system/aceme.service; enabled; vendor >> preset: enabled) >>Active: failed (Result: exit-code) since Wed 2018-12-05 19:39:44 UTC; >> 3min 50s ago >> Process: 986 ExecStart=/home/debian/eme/acemev35.py (code=exited, >> status=1/FAILURE) >> Main PID: 986 (code=exited, status=1/FAILURE) >> >> Dec 05 19:39:40 beaglebone systemd[1]: Started to invoke aceme.py >> automatically. >> Dec 05 19:39:44 beaglebone python[986]: Adafruit_BBIO: version >> initialized >> Dec 05 19:39:44 beaglebone acemev35.py[986]: Traceback (most recent call >> last): >> Dec 05 19:39:44 beaglebone acemev35.py[986]: File >> "/home/debian/eme/acemev35.py", line 21, in >> Dec 05 19:39:44
