0

How to remove delay in systemd boot service
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

How to remove delay in systemd boot service

by dhullette on Wed Feb 07, 2018 9:51 pm

Hi;

I am hoping you can help with an issue;

The issue I am having is with doing a boot service via systemd.
My code all works standalone and I finally got it to work with systemd, mostly!!!
I have had to include a 10 to 15 second delay in my .sh script called by my system service.
My script (multiPRU) loads the DTS overlay, setups the GPIOs and thens calls my C code.
that Code for the ARM loads data and text files for both PRU0 & PRU1.

I am using "After=" to avoid putting in a physical delay.
You will see from the .service file that I am waiting for quite a few things before starting the service.
Can you review what I have and see if you can recommend anything else?
Is there something else I need to wait for to avoid using the delay in the script?
I have a included the .service file, the script I am using and the DTS overlay I am using.
You will see that I have disabled the HDMI as I am using the I/Os on the PRU subsystems.

I also included a systemctl status with no delay (fails) and with delay (works).

I noticed in previous systemd cases you have assited on that you asked for;
cat /etc/dogtag
cat /etc/debian_version
cat /proc/cmdline
cat /sys/devices/platform/bone_capemgr/slots
cat /boot/uEnv.txt

Those dumps are below.

What I have is working.
I can shutdown the beagle bone and unplug and then plug the unit back in and everything comes up.
I have a 4 x 20 LCD, an Adafruit 8-Channel 12-bit PWM/Servo Driver driving the adafruit pan/tilt.
I also have a Pressure/temp sensor hooked-up. I have my own bit-banged SPI and I2C running on the PRUs.
I am using the 12k shared memory to allow the two PRUs and ARM to communicate.
These are the early efforts towards a homebuilt ROV I am working on.

Not sure if maybe I need to wait for something in the PRU sub-systems.
Let me know what you recommend.

Thanks for the help
Dan

Code: Select all | TOGGLE FULL SIZE
root@beaglebone:~# more bbbservo.service
[Unit]
Description=BBB servo code
After=generic-board-startup.service syslog.target
After=network.target network-online.target

[Service]
Type=simple
ExecStart=/root/mystartup.sh
StandardOutput=/dev/ttyO0
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


Code: Select all | TOGGLE FULL SIZE
root@beaglebone:~# more mystartup.sh
#!/bin/sh -v

sleep 10s

export SLOTS=/sys/devices/bone_capemgr.9/slots
export PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins
#export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

cd /root
cd /lib/firmware

echo PRUs-GPIO-ENABLE > $SLOTS
cat $SLOTS

cd /root

./setupGPIOs.sh

./multiPRU


Code: Select all | TOGGLE FULL SIZE
root@beaglebone:~/overlays# more PRUs-GPIO-ENABLE-00A0.dts
 // This DTS overlay sets up most of the available PRU I/Os.
 // I/Os for both PRU0 & PRU1 via their Enhanced GPIO mode,
 // which will let us access those pins by writing to R30
 // or reading from R31.

 // "PRUs-GPIO-ENABLE-00A0.dts".

 // Compile with:
 // dtc -O dtb -I dts -o /lib/firmware/PRUs-GPIO-ENABLE-00A0.dtbo -b 0 -@ PRUs-GPIO-ENABLE-00A0.dts

 // Deploy as shown to activate the overlay
 // echo PRU-GPIs-ENABLE > /sys/devices/bone_capemgr.?/slots

 /dts-v1/;
 /plugin/;

 / {
   // This determines which boards can use this DTS overlay
   compatible = "ti,beaglebone", "ti,beaglebone-green", "ti,beaglebone-black";

   part-number = "PRUs-GPIO-ENABLE";
   version = "00A0";

// By disabling the HDMI overlay and also overlaying the mcasp0_pins
// this overlay should provide 19 pins to the two PRUs.
// PRU0 should provide 7 pins and PRU1 should provide 12 pins.
// PRU 0 will use P9-25,27,28,29,30,31,42B
// PRU 1 will use P8-27-30,39-46

// HDMI was disabled by editing uEnv.txt.

exclusive-use =

/* PRU0 Pins */

       "P9.31",  /* PRU0:pr1_pru0_pru_r3x_0 */
       "P9.29",  /* PRU0:pr1_pru0_pru_r3x_1 */
       "P9.30",  /* PRU0:pr1_pru0_pru_r3x_2 */
       "P9.28",  /* PRU0:pr1_pru0_pru_r3x_3 */
//     "P9.42",  /* PRU0:pr1_pru0_pru_r3x_4 - might be BBB specific */
//     "P9.27",  /* PRU0:pr1_pru0_pru_r3x_5 */
//     "P9.25",  /* PRU0:pr1_pru0_pru_r3x_6 */

/* PRU1 Pins */

       "P8.45",  /* PRU1:pr1_pru1_pru_r3x_0 */
       "p8.46",  /* PRU1:pr1_pru1_pru_r3x_1 */
       "P8.43",  /* PRU1:pr1_pru1_pru_r3x_2 */
       "P8.44",  /* PRU1:pr1_pru1_pru_r3x_3 */
//     "P8.41",  /* PRU1:pr1_pru1_pru_r3x_4 */
//     "P8.42",  /* PRU1:pr1_pru1_pru_r3x_5 */
//     "P8.39",  /* PRU1:pr1_pru1_pru_r3x_6 */
//     "P8.40",  /* PRU1:pr1_pru1_pru_r3x_7 */
       "P8.27",  /* PRU1:pr1_pru1_pru_r3x_8 */
       "P8.29",  /* PRU1:pr1_pru1_pru_r3x_9 */
       "P8.28",  /* PRU1:pr1_pru1_pru_r3x_10 */
       "P8.30",  /* PRU1:pr1_pru1_pru_r3x_11 */

/* GPIOS being used */

       "P8.35",  /* lcd_data12.gpio2[08] */
       "P8.33",  /* lcd_data13.gpio2[09] */
       "P8.31",  /* lcd_data14.gpio2[10] */
       "P8_32",  /* lcd_data15.gpio2[11] */

       "P8.37",  /* lcd_data8.gpio2[14] */
       "P8.38",  /* lcd_data9.gpio2[15] */
       "P8.36",  /* lcd_data10.gpio2[16] */

       "P9.15",  /* gpmc_a0.gpio1[16] */
       "P9.23",  /* gpmc_a1.gpio1[17] */

       "pru0",
       "pru1";

// Mode configuration is as follows;
//
// Bit    7         6        5           4         3       2        1      0
//     N/A = 0  slewctrl  rxactive   putypesel   puden   mmode2  mmode1  mmode0
//              0 = fast  0 = off    0 = pulldn  0 = En      0 - 7 pin mode
//              1 = slow  1 = on     1 = pullup  1 = Dis

fragment@0 {
   target = <&am33xx_pinmux>;
   __overlay__ {

gpio_pins: pinmux_gpio_pins {
pinctrl-single,pins = <

/* PRU0 Available Pins - mode = 7 */

//      0x190 0xX7  /* P9_31 - GPIO3_14 */
//      0x194 0xX7  /* P9_29 - GPIO3_15 */
//      0x198 0xX7  /* P9_30 - GPIO3_16 */
//      0x19C 0xX7  /* P9_28 - GPIO3_17 */
//      0x1A0 0xX7  /* P9_42 - GPIO3_18 */
//      0x1A4 0xX7  /* P9_27 - GPIO3_19 */
//      0x1AC 0xX7  /* P9_25 - GPIO3_21 */

        0xD0  0x37  /* P8_35 - GPIO0_08 */
        0xD4  0x37  /* P8_33 - GPIO0_09 */
        0xD8  0x37  /* P8_31 - GPIO0_10 */
        0xDC  0x37  /* P8_32 - GPIO0_11 */

        0xC0  0x17  /* P8_37 - GPIO2_14 */
        0xC4  0x17  /* P8_38 - GPIO2_15 */
        0xC8  0x17  /* P8_36 - GPIO2_16 */

/* PRU1 Avaialbe Pins -  mode = 7 */

//      0xA0  0x17  /* P8_45 - GPIO2_6  */
//      0xA4  0x17  /* P8_46 - GPIO2_7  */
//      0xA8  0x17  /* P8_43 - GPIO2_8  */
//      0xAC  0x17  /* P8_44 - GPIO2_9  */
//      0xB0  0xX7  /* P8_41 - GPIO2_10 */
//      0xB4  0xX7  /* P8_42 - GPIO2_11 */
//      0xB8  0xX7  /* P8_39 - GPIO2_12 */
//      0xBC  0xX7  /* P8_40 - GPIO2_13 */
//      0xE0  0xX7  /* P8_27 - GPIO2_22 */
//      0xE4  0xX7  /* P8_29 - GPIO2_23 */
//      0xE8  0xX7  /* P8_28 - GPIO2_24 */
//      0xEC  0xX7  /* P8_30 - GPIO2_25 */

        0x40  0x2F  /* P9_15 - GPIO1_16 */
        0x44  0x0F  /* P9_23 - GPIO1_17 */

>;

};

pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <

/* PRU0 Available Pins - mode = 5 or 6 */

        0x190 0x15  /* P9_31 - GPIO3_14:pr1_pru0_pru_r30_0 */
        0x194 0x15  /* P9_29 - GPIO3_15:pr1_pru0_pru_r30_1 */
        0x198 0x15  /* P9_30 - GPIO3_16:pr1_pru0_pru_r30_2 */
        0x19C 0x15  /* P9_28 - GPIO3_17:pr1_pru0_pru_r30_3 */
//      0x1A0 0xXX  /* P9_42 - GPIO3_18:pr1_pru0_pru_r3x_4 - might be BBB specific */
//      0x1A4 0xXX  /* P9_27 - GPIO3_19:pr1_pru0_pru_r3x_5 */
//      0x1AC 0xXX  /* P9_25 - GPIO3_21:pr1_pru0_pru_r3x_6 */

/* PRU1 Avaialbe Pins -  mode = 5 or 6 */


        0xA0  0x15  /* P8_45 GPIO2_6:pr1_pru1_pru_r30_0 */
        0xA4  0x15  /* P8_46 GPIO2_7:pr1_pru1_pru_r30_1 */
        0xA8  0x15  /* P8_43 GPIO2_8:pr1_pru1_pru_r30_2 */
        0xAC  0x15  /* P8_44 GPIO2_9:pr1_pru1_pru_r30_3 */
//      0xB0  0xXX  /* P8_41 GPIO2_10:pr1_pru1_pru_r3x_4 */
//      0xB4  0xXX  /* P8_42 GPIO2_11:pr1_pru1_pru_r3x_5 */
//      0xB8  0xXX  /* P8_39 GPIO2_12:pr1_pru1_pru_r3x_6 */
//      0xBC  0xXX  /* P8_40 GPIO2_13:pr1_pru1_pru_r3x_7 */
        0xE0  0x15  /* P8_27 GPIO2_22:pr1_pru1_pru_r3x_8 */
        0xE4  0x15  /* P8_29 GPIO2_23:pr1_pru1_pru_r3x_9 */
        0xE8  0x15  /* P8_28 GPIO2_24:pr1_pru1_pru_r3x_10 */
        0xEC  0x16  /* P8_30 GPIO2_25:pr1_pru1_pru_r3x_11 */

    >;
};

    };
   };

   // This enables the PRU and assigns the GPIO pins to it for use in EGP mode.
   fragment@1 {
    target = <&pruss>;
    __overlay__ {
      status = "okay";
      pinctrl-names = "default";
      pinctrl-0 = <&pru_pru_pins>;
    };
   };

   fragment@2 {         // Enable the GPIOs
      target = <&ocp>;
      __overlay__ {
         gpio_helper {
            compatible = "gpio-of-helper";
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&gpio_pins>;

        };
      };
    };

};


root@beaglebone:~# systemctl status bbbservo.service
bbbservo.service - BBB servo code
Loaded: loaded (/lib/systemd/system/bbbservo.service; enabled)
Active: active (running) since Thu, 12 Nov 2015 14:16:22 -0500; 2 years and 2 months ago
Main PID: 516 (mystartup.sh)
CGroup: name=systemd:/system/bbbservo.service
├ 516 /bin/sh -v /root/mystartup.sh
└ 1063 ./multiPRU

Feb 05 20:16:33 beaglebone mystartup.sh[516]: Enter C for center, j,k,i,m - ...:
Feb 05 20:16:33 beaglebone mystartup.sh[516]: Invalid input
Feb 05 20:16:33 beaglebone mystartup.sh[516]: your key is:
Feb 05 20:16:33 beaglebone mystartup.sh[516]: [1B blob data]
Feb 05 20:16:33 beaglebone mystartup.sh[516]: Enter C for center, j,k,i,m - ...:
Feb 05 20:16:33 beaglebone mystartup.sh[516]: Invalid input
Feb 05 20:16:33 beaglebone mystartup.sh[516]: your key is:
Feb 05 20:16:33 beaglebone mystartup.sh[516]: [1B blob data]
Feb 05 20:16:33 beaglebone mystartup.sh[516]: Enter C for center, j,k,i,m - ...:
Feb 05 20:16:33 beaglebone mystartup.sh[516]: Invalid input


root@beaglebone:~# systemctl status -n50 bbbservo.service
bbbservo.service - BBB servo code
Loaded: loaded (/lib/systemd/system/bbbservo.service; enabled)
Active: active (exited) (Result: exit-code) since Thu, 12 Nov 2015 15:07:30 -0500; 2 years and 2 months ago
Process: 526 ExecStart=/root/mystartup.sh (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/bbbservo.service

Nov 12 15:07:31 beaglebone mystartup.sh[526]: #!/bin/sh -v
Nov 12 15:07:31 beaglebone mystartup.sh[526]: #sleep 10s
Nov 12 15:07:31 beaglebone mystartup.sh[526]: export SLOTS=/sys/devices/bone...s
Nov 12 15:07:31 beaglebone mystartup.sh[526]: export PINS=/sys/kernel/debug/...s
Nov 12 15:07:31 beaglebone mystartup.sh[526]: #export PATH=$PATH:/usr/local/...n
Nov 12 15:07:31 beaglebone mystartup.sh[526]: cd /root
Nov 12 15:07:31 beaglebone mystartup.sh[526]: cd /lib/firmware
Nov 12 15:07:31 beaglebone mystartup.sh[526]: echo PRUs-GPIO-ENABLE > $SLOTS
Nov 12 15:07:32 beaglebone mystartup.sh[526]: cat $SLOTS
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 0: 54:PF---
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 1: 55:PF---
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 2: 56:PF---
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 3: 57:PF---
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 4: ff:P-O-L Bone-LT-eMMC-2G,00...G
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 5: ff:P-O-- Bone-Black-HDMI,00...I
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 6: ff:P-O-- Bone-Black-HDMIN,0...N
Nov 12 15:07:32 beaglebone mystartup.sh[526]: 7: ff:P-O-L Override Board Nam...E
Nov 12 15:07:32 beaglebone mystartup.sh[526]: cd /root
Nov 12 15:07:32 beaglebone mystartup.sh[526]: ./setupGPIOs.sh

root@beaglebone:~# cat /etc/dogtag
BeagleBoard.org Debian Image 2015-11-12

root@beaglebone:~# cat /etc/debian_version
7.9

root@beaglebone:~# cat /proc/cmdline
console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN root=UUID=978205b6-504f-4d59-bb47-8022e8381144 ro rootfstype=ext4 rootwait coherent_pool=1M quiet init=/lib/systemd/systemd cape_universal=enable

root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
cat: /sys/devices/platform/bone_capemgr/slots: No such file or directory
root@beaglebone:~# cat $SLOTS
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
7: ff:P-O-L Override Board Name,00A0,Override Manuf,PRUs-GPIO-ENABLE

root@beaglebone:~# cat /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_pa ... layout_2.0

uname_r=3.8.13-bone79
##uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb

##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb

##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb

##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb

##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb

##BeagleBone Black: replicape
#dtb=am335x-boneblack-replicape.dtb

##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb

cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd cape_universal=enable

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd cape_universal=enable video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##Disable HDMI/eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

##Disable HDMI (v3.8.x)
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

##Disable eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G

##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02


##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

uuid=978205b6-504f-4d59-bb47-8022e8381144

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Thu Feb 08, 2018 5:53 am

Hi, it looks like you are using Debian 7.9 (2015-11-12) which is quite old at this point.

I would suggest moving to a newer BeagleBoard.org Debian image:
Debian 9.3 (Stretch)
or
Debian 8.7 (Jessie)

Would you be able to try one of those?

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Re: How to remove delay in systemd boot service

by dhullette on Thu Feb 08, 2018 9:55 am

Hi Drew;

I have been avoiding updating as I have so much working. On top of that my skills are on the HW side.
That's why I am teaching myself Linux & C via this ROV project.

My main concern about upgrading now is whether things like prussdrv libraries will work without a lot of modification, or worse yet have been replaced with something else.
The learning curve for the PRUs was steep as it was.

If you have any thoughts with my current configuration I would appreciate it.

If not maybe I will try updating with a simpler configuration first. I do have 2 beaglebone blacks.

Thanks
Dan

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by dhullette on Mon Feb 12, 2018 8:58 pm

Hi Drew;

I checked and it seems to me that prussdrv is not available in new releases and I would have to move to remoteproc.
This would involved quite a bit a of work to redo.

Could you suggest what might be the last thing to load during boot that I may need to wait for?
Here is what i am waiting for in my .service file;
After=generic-board-startup.service syslog.target
After=network.target network-online.target

Is there anything that might be happening after that, how about for the PRU devicies.

Thanks
Dan

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Tue Feb 13, 2018 5:47 am

Please paste the output of:
systemd-analyze critical-chain

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Re: How to remove delay in systemd boot service

by dhullette on Tue Feb 13, 2018 9:44 pm

Hi Drew;

Thanks for replying. Well it looks to me that this earlier version of Linux does not support all the verbs that systemd-analyze may now have available. I can only do the following;

root@beaglebone:/lib/systemd/system# systemd-analyze help
systemd-analyze time
systemd-analyze blame
systemd-analyze plot

I will attach a "systemd-analyze blame" copy as that does show the time for some services. I know this shows no sequence but maybe it may suggest something to you. In the meantime I will most likely keep developing as I have been.

I do have a question. If I setup an SD card to boot from with the new version, can I maintain the previous version and setups in flash?
This would allow me the flexibility to work with both versions (i.e. transition at my pace).

Thanks (dump is below signature)
Dan

root@beaglebone:/lib/systemd/system# systemd-analyze blame
8471ms wicd.service
3384ms generic-boot-script.service
3364ms apache2.service
3189ms bootlogs.service
2980ms console-kit-daemon.service
2833ms loadcpufreq.service
2474ms xrdp.service
2425ms ssh.service
2395ms cron.service
1559ms wpa_supplicant.service
1557ms avahi-daemon.service
1503ms systemd-logind.service
1468ms upower.service
1449ms console-setup.service
1402ms networking.service
1195ms lightdm.service
1107ms capemgr.service
894ms polkitd.service
869ms rc.local.service
837ms keyboard-setup.service
770ms udev-trigger.service
684ms motd.service
673ms udhcpd.service
598ms console-kit-log-system-start.service
587ms alsa-utils.service
586ms cpufrequtils.service
523ms udev.service
461ms kbd.service
360ms hostapd.service
351ms screen-cleanup.service
333ms systemd-modules-load.service
323ms systemd-user-sessions.service
296ms saned.service
229ms systemd-tmpfiles-setup.service
215ms hdparm.service
212ms sys-kernel-security.mount
206ms sys-kernel-debug.mount
187ms run-lock.mount
186ms dev-mqueue.mount
176ms pppd-dns.service
148ms run-user.mount
143ms systemd-sysctl.service
125ms systemd-remount-api-vfs.service
55ms sys-fs-fuse-connections.mount
42ms remount-rootfs.service

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Tue Feb 13, 2018 10:27 pm

I spoke with Robert Nelson today, who is the maintainer of the BeagleBoard.org Debian images. He suggested that the issue is that your script requires the root filesystem to be mounted for the dtbo file to be accessible in /lib/firmware.

The solution is to add your device tree overlay (.dtbo) file to the initramfs:
https://elinux.org/Beagleboard:BeagleBo ... stom_capes
Due to limitations in debian wheezy's userspace, the use of an initramfs, and having firmware builtin to the kernel. It is currently not possible to load "custom" capes via: capemgr.enable_partno=xyz. Instead an init script has been set up to load the cape/capes as soon as possible.

The workaround is to add your overlay to /etc/default/capemgr:
CAPE=PRUs-GPIO-ENABLE

Then you can rebuild the initramfs with this script:
sudo /opt/scripts/tools/developers/update_initrd.sh

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Re: How to remove delay in systemd boot service

by dhullette on Tue Feb 13, 2018 10:47 pm

Hi Drew;

Thank you very much for the quick reply :)

I will read through the post and try it.

I am still doing some development so I know I will be adding more I/Os and using the A/D inputs.
I am assuming that as I work with modified or new device overlays that I can either comment out or delete the overlay and recompile.
Then when I have a new working overlay I can add it back or uncomment the line and rebuild if the file name is the same.
Am I correct in saying that?

Again, thanks for the help.

Dan

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Tue Feb 13, 2018 11:45 pm

dhullette wrote:I am still doing some development so I know I will be adding more I/Os and using the A/D inputs.
I am assuming that as I work with modified or new device overlays that I can either comment out or delete the overlay and recompile.
Then when I have a new working overlay I can add it back or uncomment the line and rebuild if the file name is the same.
Am I correct in saying that?


You will want to run sudo /opt/scripts/tools/developers/update_initrd.sh every time you change the device tree overlay.

Also, for discussion of device tree overlays, you may also want to post on the BeagleBoard.org community mailing list as Robert Nelson will see it:
https://groups.google.com/forum/#!categ ... eagleboard

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Re: How to remove delay in systemd boot service

by dhullette on Thu Feb 15, 2018 9:05 pm

Hi Drew;

Well this still didn't work. I removed the overlay from my bash script and added it to capemgr and then compiled.
For the first pass I left the delay in just to make it worked as it did before, which it did.
So I was able to have my overlay available at boot which is really nice.
I then removed the 15 second delay from the script and tried again.
This failed as it did before with a status =1 failure.

Any other suggestions?

Dan

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Fri Feb 16, 2018 4:56 am

Could you take a look at what's in the system log after it boots?
Code: Select all | TOGGLE FULL SIZE
dmesg

journalctl

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Re: How to remove delay in systemd boot service

by dhullette on Sun Feb 18, 2018 7:06 pm

SUCCESS!!!!!

Hi Drew;

I now have my BBB booting into my code with no terminal or requiring me to login and start my programs.
Works from both a reset (pushbutton) and a complete power down.

It seems there was more than one dependency. One I believe you suspected in that the overlay wasn't being loaded early enough.
However even when I tried adding my overlay to the capemgr I still needed the delay.

For some reason I don't have support for journalctl on my system, I also found that I don't have all the options for systemctl.
So I captured dmesg dumps for the working and non-working states to try and determine what the other dependency might be.
Well I had no luck so I looked at what other targets might be available to use with After=.
I am now using just After=multi-user.target and adding my overlay to the capemgr and that is working.

I am going to get one or two more sub-systems working and then I probably should jump to a more recent Linux version.

Which Linux version would you recommend at this point?

Again thanks for all help, if you can provide the linux version you can close out this case.

Thanks
Dan

dhullette
 
Posts: 18
Joined: Sun Feb 28, 2016 4:53 pm

Re: How to remove delay in systemd boot service

by drewfustini on Mon Feb 19, 2018 3:13 am

That is great to hear it is working.

dhullette wrote:Which Linux version would you recommend at this point?


I would recommend Debian 9.3 2018-01-28 4GB SD IoT image from the BeagleBoard.org Latest Firmware Images page.

drewfustini
 
Posts: 844
Joined: Sat Dec 26, 2015 1:19 pm

Please be positive and constructive with your questions and comments.