An older rev B BeagleBone Black is used as the primary control board. This uses Angstrom Linux. I cannot speak to the differences between this and rev C with Debian distributions. I will say that I find the Angstrom distribution slightly more difficult to work with as I am accustomed to the standard unix utilities and configuration approach. Angstrom’s use of select packages such as connman and busybox help resource footprint but often send me to the web searching for how to do basic system administration and configuration actions I have done for years. Said differently, I believe you can do all of these and at least as easily with Debian on a rev C board.
The following steps are in the notes.txt file in the BREC/SynHttpd software. The text here provides a little more background and narrative beyond the terse command notes.
The first step is to disable a set of default services that are not used and that use the http default port 80. There are plenty of good tutorials on the web and all boil down to “systemctl disable <svc>”, where <svc> is cloud9.service, gateone.service, bonescript.service, bonescript.socket, bonescript-autorun.service, avahi-daemon.service, gdm.service, and mpd.service.
The next step is to setup the synthesizer application to start automatically at boot time. Again, there are plenty of good tutorials on the web and there are examples in the BREC/Scripts directory of the software. I configured a service to start a bash script via systemd. The main script is placed in /home/root with the rest of the executables and the script launches the actual applications. To me, systemd has quirks like crond, you don’t have the exact same environment as your normal shell (just enough to throw things off) and the configuration files take some getting used to. You can use “systemctl status <service you defined>” to check on the application and its children’s status and see any stdio. It takes some getting used to. There are items to be aware of like exiting with a good status or having your processes “cleaned up” for you. You need to start the applications and get them in the background before a predefined time limit or the service process tree is killed as being hung. All of these things can be adjusted in the configuration files or in your startup script – you just have to pick an approach and understand the subtleties of the configuration you have defined. There are also issues to be aware of with starting so quickly on boot. One of particular importance is “/dev/uio0” not being present for a brief period of time. This is the special file the libpru code uses to access the PRU. I found that startup services I created would randomly seem to not start. It turned out that sometimes by the time they went to open the pru the special file was available and sometimes not. By just checking for the existence of the special file in the startup of the service script the service reliably starts every time.
So at this point you have a BBB that lets you start your own web service on startup. The next step is to safely allow shutdowns without other action. To do this the root disk is mounted as read only. There are several examples on the web as well as a sample /etc/fstab in the BREC/SynHttpd/fstab-ro file. To make root writeable you just issue “mount –o remount,rw /” and everything is back to a standard writeable file system. I have to admit this works really well and consider using this on normal development boards where I write to the root partition. A read only root file system speeds the boot time but also helps when working with a new board and linux gets powered down without warning. There are posts and comments on the web regarding early perceived issues with a read only file system on BBB (e.g. applications could not access the gpio pins through sysfs), however, I experienced no issues – everything works as expected including all device interfacing and other system services.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.