Installing Florence and Matchbox_Keyboard

The article which describes how to use the SD copier to export and compress the Pi OS: https://www.raspberrypi.org/blog/another-update-raspbian/

A post about installing Matchbox Keyboard on the pi, which had warnings in the middle from users who had encountered problems with their desktop icons disappearing (due to Matchbox interfering with the file browser pcmanfm): https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=14719

Another post about the conflict between Matchbox and pcmanfm. At the bottom there is a suggestion that it was somehow fixed in an update, presumably an update to PCMANFM: https://www.raspberrypi.org/forums/viewtopic.php?t=153003

The spec for the touchscreen itself mentions Matchbox, with a quick description of using sudo apt-get install: https://www.element14.com/community/docs/DOC-78156/l/raspberry-pi-7-touchscreen-display

The documentation for Florence itself just shows doing a simple sudo apt-get install: http://florence.sourceforge.net/english/index.html

PCMANFM deleting bookmarks

I accidently hit the eject symbol for the MicroSD card on a file browser in Raspbian. To my surprise, the system continued to function, contrary to what I'd read elsewhere. I think that what happened was not an ejection of the OS but it deleted a link which opens the browser to the OS top level. After some frantic searches, I was reminded that this browser is called PCMANFM and learned that the links in the side panel are "bookmarks". The following article provide enough info for me to manually reestablish the bookmark. It seems like the browser app remembers changes to the list of bookmarks even through restarts. Here is the article that helped me get a handle on what was going on: https://www.raspberrypi.org/forums/viewtopic.php?t=107216

debian set file browser default view to list

Duh, it's a setting for the browser. Find "Preferences" under "Edit" and set it there.

The link that helped me realize this simple answer. The funny part is that this forum thread is for Ubuntu: https://ubuntuforums.org/showthread.php?t=1179613

Debian how to enable pcf8563 in device tree

Clearing browser tabs from an old effort to try again to get the pcf8563 RTC chip to install into my Debian OS using Device Tree. I was never able to figure out how to get the chip installed this way, instead I got the driver module compiled. These links mostly don't make sense to me but I'm saving them for future reference if I eventually grow to understand Device Tree better.

An email or forum thread from somebody who made some changes to the commonly available driver for some reason associated with Device Tree interfaces. I'm not sure what lkml is though: https://lkml.org/lkml/2012/7/18/241

Another message from the same thread from somebody who made changes to the driver because of Device Tree needs: https://lkml.org/lkml/2012/7/18/241

A list which seems to indicate that the pcf8563 is "trivial" and supported by Device Tree. But I have no idea how that helps: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/i2c/trivial-devices.txt?v=3.14

More about Device Tree and I2C, in this case for Raspberry Pi. This should help somehow with the pcf8563 which is an i2c device. This document seems to show how to enable RTCs including the pcf8563, and may actually work but I couldn't figure it out: https://www.raspberrypi.org/forums/viewtopic.php?t=97314

This seems to be a tutorial on how to write Device Tree overlays, and mentions the pcf8563 but again I wasn't sure what to do here: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

Beaglebone Black switch monitors

Since I've swapped the BeagleBone on my project with a BeagleBone Black, I would like to benefit from the Black's on-board HDMI capabilities and be able to hook up an external monitor when I need to even though my system is presently working with the LCD7 cape. The problem is that there doesn't seem to be any capability for the BBB to "switch monitors" like for Windows PCs. From experimenting, having the LCD7 cape connected to the BBB (which works) prevents the image from being sent to the HDMI port. If I disconnect the BBB from the LCD7 then when the BBB boots it can connect to an HDMI monitor fine. So far what I think I have learned is that the issue has to do with screen resolutions. It has been hinted on some forums that cape HDMI adapters are essentially monitoring the same signals that are used to generate the HDMI on-board the BBB, and there is no way to "switch" between them as a result. It has also been stated that screen resolution can only be set at boot time for reasons that I don't quite follow. The LCD7 has a resolution of 800x480, which is rare for most other monitors. So what seems to be happening is that during boot, the LCD7 is being recognized and the HDMI resolution is being set accordingly, and either the step for retrieving monitor resolutions from devices connected on the HDMI bus is not happening or the connected monitors would show an image if they supported 800x480. If the latter possibility could somehow be verified it would at least prove that the HDMI connections are in fact parallel. In any case, here is the documentation so far of my research into how this works:

Here is a thread which starts off with somebody having a problem with the BBB just outputting an HDMI signal, despite trying mixing various combinations of known good monitors and cables. Somebody asks the question how to force a particular resolution. Gerald has people try different OS releases, which doesn't work for some but for some people it fixes the problem. One guy turned out to have a bad HDMI adapter cable despite initially thinking that his cable was good. It turns out that bad cables are a huge cause of problems with BBB HDMI not working. Some people report having success with using HDMI to DVI adapter cables. There is a discussion of a configuration information called EDID, and forcing the resolution using the uEnv.txt file. There's a fbset command and a xrandr command. It is proposed to troubleshoot the problem by forcing resolution to 640x480@60 which apparently "all displays are required to support." One guy gives a gorgeous example of using xrandr to read info about the connected display, parse-edid to get info on the monitor, ID.txt file to get info on the OS, xrandr to set a new resolution and fbset for something. Then there is a discussion with a guy who has two BBBs with one that isn't working, but his problem is solved by reinstalling his OS on the board that's giving him trouble. Amazingly, this guy gets responses from Robert C. Nelson himself with this issue!
https://groups.google.com/forum/#!topic/beagleboard/0fMTXLPuGS4

A lot of the hints from Gerald and other users on the various google group threads that I've found are (uncharacteristically) well-summarized in this wiki page, which shows how to use xrandr, parse-edid, and how to mdify the uEnv.txt file: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI

Here is a google group thread where somebody asks exactly the same question that I have about running an LCD cape and HDMI video output at the same time. Except his case is slightly different in that he's trying, optimistically, to design an LCD cape of his own. He is also using Ubuntu which apparently has the HDMI output always on. This is the thread where Gerald mentions that it would work if the monitor and the LCD are the same resolution. Gerald later states that "the HDMI function needs to be disabled to allow something other than 1024x768 to be sent to those pins," which seems to contradict his earlier statement that the HDMI framer and LCD can be run in parallel. Also, the link given by Gerald is to the FAQ which specifically says "The HDMI framer cannot be disabled via SW" and mentions the pins are configured using the Capemanager and mentions a workaround. The workaround seems to require use of the uENV.txt file which can only be edited via USB. Astonishingly, the OP figures out how to disable the HDMI and does something that enables LCD4 firmware. None of which I've been doing when I switch between the LCD7 and the HDMI monitor. Perhaps it's not actually necessary? The OP asks about signal timing and Gerald starts getting snotty for some reason. Other people ask questions I need to know the answer to and Gerald just replies with "search the forum." That is particularly snide considering that the forum tree has "Newbie" in the path. https://groups.google.com/forum/#!topic/beagleboard/-4Q3UnqxY3k

This is the work-around of disabling the onboard HDMI by editing the uEnv.txt file. It also shows checking a configuration file for the capemanager: http://elinux.org/Beagleboard:Weather_Cape_Work-Around

Interestingly, the forum thread from the HDMI question above is a branch of a forum thread tree that starts at beaglebone/hdmi. Promisingly, one of the first threads in the list is LCD as well as HDMI. Here's the topic list, there is so much potential information here: https://groups.google.com/forum/#!categories/beagleboard/hdmi

So, I followed the instructions from the wiki for running xrandr --verbose to get the information on whatever monitor which the BBB is booting to. Strangely the HDMI monitor on my desk seems to support only one resolution: current, min and max are all 1280x720. When using the LCD7, current, min, and max are all 800x480. This may imply that the LCD7 does not support 640x480 as supposedly required.

Looking at the problem a different way, maybe I could find a way to write a script to selectively enable or disable the LCD7 cape so that if it's disabled the HDMI framer finds my monitor. Is there a way to disable a cape from the command line? Hard to say. Here are some links:

Here are some instructions for modifying uEnv.txt. It seems like it's being done from the command line. But maybe it's through the USB. Must re-re-reread: https://groups.google.com/forum/#!topic/beagleboard/aU__9RGq3xU

Here is another example of setting up uEnv.txt. It's for a completely unrelated example, but still helpful. http://tinkernow.com/2015/01/beaglebone-black-rs232-uart-setup/

Here's a link I've gone through before while trying to get Device Tree working for installing the RTC chip; it shows using overlays to install and deinstall a cape, but in the end it finishes up with editing the uEnv.txt file for permanent installation of a cape. This link also has one a very friendly example of chekcing the capemanager slots file to see what is installed. : https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay

When I check the slots file with the LCD7 installed, it does not list the virtual HDMI cape for some reason! It shows the LCD7 cape in slot 0 and the eMMC in slot 4 but nothing else. Is the driver for the LCD7 completely deinstalling the HDMI cape at bootup?

Here is perhaps what I was looking for. This is a fairly long forum thread. It starts off with somebody trying to edit uEnv.txt in /boot and not getting the desired result, somebody confirms that it's "the wrong uEnv.txt". They suggest "mounting the FAT partition of the EMMC". Somebody else looks at the environment variables and is interested in what it says about the locations of the uEnv.txt file and the fdt file (which seems to be the device tree setup), and proposes changing the setup to use a different uEnv.txt. The OP finds that the FAT partition can be found through a roundabout method of using fdisk to see all partitions and then picking the one that looks most likely to be the right one and mounting it. Note that the partition name used, mmcblk0p1, is mentioned in several other sources which I haven't had time to list yet. The guy that wants to try changing what file is used at boot time tries a though experiment but in the end he comes up with no answer. https://groups.google.com/forum/#!msg/beagleboard/77IuIt1OCss/O2-kKXHFTmQJ

This is the link that explained why the LCD7 and the HDMI couldn't seem to play together. It turns out that it's because the LCD7 is a touch screen also, and it's apparently set up to use both chip selects on the SPI1 bus which apparently locks out the HDMI interface. I wasn't quite able to figure out from this how the drivers figure out how to not enable the HDMI if the LCD7 is connected, but it confirmed that the two are exclusive and I could never as a result have gotten an HDMI signal at any resolution if the LCD7 is connected. Interestingly, this is a github page which is usually used for code repositories, but this page is set up like a wiki page and is the most exquisitely referenced of any I have ever seen from the BeagleBone community. I should eventually read every link in this page:
https://github.com/notro/fbtft/wiki/BeagleBone-Black

While trying to find the previous link again, I did this google search which unearthed some incredibly juicy looking links about interfacing LCD screens in general that I'd love to get back to again:
https://www.google.com/?gws_rd=ssl#q=beaglebone+black+hdmi+lcd+spi+bus

So, now my idea is to see if there is some way to disable the LCD7 cape without disconnecting it, in such a way that the HDMI interface is allowed to boot up. My first idea was to find whatever Device Tree file is used for the LCD7 cape and either modify it or change its name so it can't be accessed, or maybe modify the main Device Tree files to disable the loading of the LCD7 cape. In the end it didn't work at all; there are no dtbo files for the LCD7 in the appropriate directory and I couldn't find the .dti file for the system (I guess in retrospect it wouldn't have been useful since my system Device Tree was already compiled, duh). The LCD7 seems to be one of the capes that is essentially "built in" to the kernel. However, as a result of all this searching, I read through a lot more very good links about Device Tree and also the Capemanager.

Update 3/10/2016: So, after all that searching, I learned enough to discover that the problem was not as difficult to solve as I had feared. After failing to find a way to disable LCD booting through messing around with .dtb files, I began investigating my options for modifying the uEnv.txt file. Many sources have reported that it is only accessible from the FAT partition over USB, but I had links which showed how to mount that partition into my Linux session so I tried that. I was able to find and mount the partition, but to my surprise, there was no uEnv.txt file there! It had nfs_uEnv.txt and all the html files that come up when you connect the bone as a thumb drive, but no uEnv.txt. A look at nfs_uEnv.txt clearly showed that it didn't have the functions that uEnv.txt does. /boot did have a uEnv.txt file, often described as not the one used for booting, but I tried adding a line to it to disable the LCD cape and boom the BBB rebooted with the LCD disabled and it found the HDMI screen that was connected. So, this file is fairly easy to make a shell script for that switches it between disabling or not disabling the LCD, without requiring any additional partition mounting! I think that the reason why this turned out to be easy after all is that I am running the BBB from SD card; probably when running from eMMC it must use the uEnv.txt file from the FAT partition. Either that or maybe it has a hierarchy of going to the /boot directory if it doesn't find uEnv.txt in the FAT partition, and I got lucky because my particular distro (3.8.13.bone-70) didn't come with that file in that partition.

Beaglebone Black Boot Only From SD Card

After my unpleasant experience with the BBB crashing and corrupting it's own OS in eMMC, I decided that to use BBB in my application I have to ensure its reliability by forcing it to boot from SD card like the original Beaglebone. After a bit of a scare where it seemed as though this always required the boot button to be pressed on the board itself (it does not always require this, only when there is a viable OS in eMMC), I uncovered various sources which explained which configuration file on the BBB to lobotomize to make it boot from SD card every time without having to push any buttons on the board.

This link is typical of most instructions for booting from SD in that it mentions holding the boot button on the card without explaining any further. Also it includes the usual instructions for using the SD card to load the OS into the eMMC. Despite not being what I was looking for, this was notable for being one of the clearest guides to getting started with upgrading the BBB to Debian outside of BeagleBone's own web pages: http://thethingsystem.com/dev/Bootstrapping-the-BeagleBone-Black-with-Debian.html

The BeagleBone:Debian wiki is a maze of poor documentation, I'm afraid. Here is the map through the maze that I've developed as a result of feeling my way through it multiple times:

Here is the top-level wiki page for how to install Debian. It makes mention of an image "that can run from a microSD card" but that link just goes to another wiki page. It's actually easier just to get the SD image from the BeagleBoard.org page; through trial and error I've verified that the same image works fine on both the original BeagleBone and BBB. Further down the page, it mentions having to hold the boot button and provides a link to a FAQ that supposedly answers how to boot from SD every time. That FAQ is just a link to yet another page. http://elinux.org/Beagleboard:Debian_On_BeagleBone_Black

Here's where the link to "an image that can run from a microSD card" goes. It's a confused tangle of a whole pile of different images, from ones for eMMC, stripped down ones, ones for other Beagle products, and in there is a prebuilt image for SD card. Again, easier just to go to BeagleBoard.org. http://elinux.org/BeagleBoardDebian#BeagleBone.2FBeagleBone_Black

Here is a different page on the wiki for an image for SD card. In a block quote, it has the first clue about what modifications on the eMMC to cause it to go to the SD card by default. The hint has us deleting the MLO file (which apparently can only be accessed by mounting the BBB as a thumb drive). However, other instructors mention just renaming the file which is clearly a wiser method. http://elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD

Here is one of those corroborating links for the method of deleting/renaming the MLO file: http://perf.tamu.edu/perftech/beaglebone-black-boot-from-the-minisd-card/

In my case, since the eMMC had been fully corrupted, I didn't have to touch the MLO file. I was able to move the SD card from my BeagleBone to the BBB and everything worked exactly the same, except that now I can hook up an HDMI monitor (more on that later). In fact, when I connected the BBB to my PC via USB, nothing mounted, so I never got a chance to try out this hint. I might go through the steps for flashing the OS to the eMMC just to see if I can restore my BBB to factory settings so I can rehearse this hint!

Linux write message to log file from .service

As part of trying to debug the .service that I set up for installing the RTC chip on my BeagleBone at boot time, I was interested in writing messages to the Linux system logs from the shell script that it called. This turns out to be fantastically easy; there seems to be a couple of different commands that can be used, I went with the 'logger' command, as described in this link:

http://www.cyberciti.biz/tips/howto-linux-unix-write-to-syslog.html

Notes from compiling a kernel module from scratch

Found the debian SD image for BeagleBone that I started testing with so long ago. It's probably obsolete by now, but at least I know that it works.

Its name is bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img

Used Win32DiskImager to write it to a blank 4G SD card from AdaFruit.

Beaglebone booted to LXDE desktop after a worrying 45 second pause (It might have been setting up the ethernet connection)

perform apt-get update

sudo apt-get update

Update Tkinter just because

sudoe apt-get install python-tk

start python, verify tkinter installed to make sure that the last installs worked.

$ which python
$ python
import os
import Tkinter
^d

get my kernel version:

$ uname -r
3.8.13-bone70

attempt to get the source tree headers:

$ sudo apt-get install kernel-headers-$(uname -r)
E: Unable to locate package kernel-headers-3.8.130bone70
E: Couldn't find any package by regex 'kernel-headers-3.8.13-bone70'

$ sudo apt-get install kernel-headers
E: Unable to locate package kernel-headers

Try searching the cache for anything that might be what I'm looking for:

$ apt-cache search kernel | grep headers
$apt-cache search headers | grep bone70
linux-headers-3.8.13-bone70

Note: from above searches, I discovered that the cache had headers up to and probably past bone79.
trying again to get the source tree headers:

$ sudo apt-get install linux-headers-$(uname -r)

Worked great.

Download hello.c and Makefile from google cached version of this site (which seems to be not responding right now for some reason) http://www.cyberciti.biz/faq/add-remove-list-linux-kernel-modules/

Copy Makefile and hello.c to new folder under /home/debian, cd to folder, run 'make'. Compiled .ko file as promised.

Run the following commands. Kernel module seems to be installed, although there is an extra message in the /var/log/messages file saying: "hello: module license 'unspecified' taints kernel"

$ modinfo hello.ko
$ sudo insmod hello.ko
$ lsmod
$ rmmod hello
$ tail -f /var/log/messages

Pulled raw rtc-pcf8563.c file from https://github.com/jeffegg/beaglebone/tree/master/drivers/rtc and tried to put it in its own directory under /home/debian with the Makefile from the hello example, changing the name of the object to compile, got some compile errors. Specifically it doesn't like THIS_MODULE and the module property declarations at the end.

The makefile at https://github.com/jeffegg/beaglebone/tree/master/drivers/rtc has a bunch of options for compiling other things like rtc-lib.o, rtc-core.o, all of which seem like I might need them.

Looking at the linux headers directory that I downloaded earlier, I am surprised to find the exact same makefile under /usr/src/linux-headers-3.8.13-bone70/drivers/rtc!!!! This may indicate that I might be able to find the kernel module in the source tree and just build it after all. The question is how to get the source tree. After a lot of fiddling, trying:

$sudo apt-get install linux-source

This seems to be getting me the 3.2 source instead of the 3.8 for unknown reasons, but that might be sufficient to get a drivers build directory that matches the drivers header directory.

Debian On-Screen Keyboard

As part of my BeagleBone system, portability would improve if I didn't have to plug in a keyboard. As it turns out, there are several linux-compatible on-screen keyboard utilities that I can get for Debian and in particular in my case LDXE. I tried a few out; the one I like best is the boring-looking "Matchbox Keyboard". Interestingly, I found that it comes with the Debian distribution from BeagleBone. I tried "Florence"which looks lovely, except that when I installed it something went wrong with the colors or something and all the special function keys were blank even though their functions worked.

Here are some links:

Results from doing a package search right on debian.org: https://packages.debian.org/search?keywords=matchbox-keyboard

BeagleBone Debian Compile Driver Module

This is a page for documenting links and discoveries while I try to figure out different options for getting my WaveShare RTC cape working with my BeagleBone Debian distribution.

Steps tried so far: 1) Download the pre-compiled Debian distro from WaveShare site and updating it with Tkinter to match the Debian distro that I got from BeagleBone. 2) Trying to compile the drivers that WaveShare supplies into my distro from BeagleBone. 3) Trying to compile the driver source code for the PCF8563 chip that is available online. 4) Buy a BeagleBoneBlack from Adafruit which comes loaded with Debian already and hope whatever distro that Adafruit supplies has driver module for the PCF8563

Results for approach 1) Trying the pre-compiled distro from Waveshare: The Debian Distro from the WaveShare site interfaced smoothly with the RTC cape. It was a complete SD card image, which I downloaded and installed on an SD card. It booted up and found the LCD screen and had LXDE with about the same desktop configuration as the Debian distro from the BeagleBone site. I was able to execute all of the steps I had previously learned to install the PCF8563 chip as a new device on the i2c bus, it was recognized by the driver and a new rtc device was installed in /dev, I was able to write the date to the rtc and read it back, and the steps from several sites for setting up a service to set the system time from the rtc during bootup all worked. This distro, like the BeagleBone distro, did not have Tkinter. I executed the steps to use apt-get to install Tkinter and they worked fine. I was able to run my Tkinter code. But I found that there is a huge problem in that the file manager freezes and crashes during any "drag and drop" operations!!!

From here, it seems like my options branch into: a) try to figure out if the pcf8563 driver in this distro is somehow a module that I can copy and install into the BeagleBone distro, or b) try to figure out how to fix the drag and drop crashing problem in the WaveShare distro. While looking for module files in the WaveShare distro, the module directory name showed that it seems to be numbered "Bone40" while the distro that I got from BeagleBone is "Bone70" so perhaps there were issues that got fixed between when WaveShare compiled their drivers and when I downloaded Debian from the BeagleBone site.

Some links to sort through later:

A link which might help me with updating the WaveShare distro to fix the drag and drop issue: https://www.debian.org/doc/manuals/debian-faq/ch-uptodate.en.html

Results from approach 2) Try to compile the driver files supplied by Waveshare: I am making a stab at trying to understand the instruction on the Waveshare site for compiling their modules. The document XXX_CAPE_Porting_Drivers.pdf says to do *something* (it's not clear) with the .dts file provided by the site in a zip file of .dts files. It might be that the use of the word "Coding" in the instructions is an incorrect translation from another language, since the instructions seem to be saying just to find the file and place it in a particular location. Also, apparently the instructions cover doing the same driver porting for an i2c driver which makes a little bit of sense since the PCF8563 is on the i2c bus for the BeagleBone, but I'm not sure if there aren't already i2c drivers in my Debian distribution, and if there are I'm not sure if they'd be compatible with whatever RTC driver WaveShare is providing or if Waveshare's RTC driver requires Waveshare's i2c driver only. The results seem to be .dtbo files which have to be placed into certain directories and then a text string which is similar but not exactly the same as the name of each of the .dtbo files gets echoed to some kind of capemanager device similar to how the chip gets installed as a new i2c device. Among other questions this raises, I have to wonder if this is a one-time operation or does it have to be performed on every bootup by some kind of service? There's a hint in section 16 of the document that says that their Angstrom distribution pretty much does this, although the directories discussed don't look like those that I put service scripts into while playing around with Debian. The Section 14 described in the card has a lot of discussion about something called a TF card, and seems to be rather Angstrom-specific, giving me despair that this entire process could be inapplicable to Debian.

http://www.waveshare.com/w/upload/2/20/XXX_CAPE_Porting_Drivers.pdf

.dts apparently stands for device tree source file. There's something called a .dtsi which is the device tree source include file. This is explained in the following very dense tutorial, most of which I still don't get after the acronym expansions:

http://elinux.org/Device_Tree

This seems to be a tutorial specifically addressing what Device Tree is in the context of BeagleBone. It talks about kernel 3.8 which I've seen is what both my official BeagleBone Debian distro is as well as the Waveshare Debian distro. It gets confusing about 1/4 of the way in, but it seems that I need to fully understand what is being discussed at this link if I ever hope to recompile the Waveshare drivers for the Bone70 kernel:

http://elinux.org/BeagleBone_and_the_3.8_Kernel

Interestingly, now that I have begun reading the above links, the driver loading instructions for the original but discontinued cape that I had hoped to get are now making a lot more sense. This shows a step not in the Waveshare instructions which is how to check the event logs for successful load of the device tree overlay. Also the links at the bottom of the page, which previously seemed random, now look like additional tutorials about Device Tree that could help me:

http://elinux.org/CircuitCo:RTC_Cape

Update Jan 31 2016: So far I have been able to compile the .dts files from Waveshare but it hasn't resulted in the pcf8563 chip being recognized or a new rtc being added for it under /dev. Here is the latest new information that I've dug up.

First of all, I've found a gorgeous tutorial on how to compile dts files for BeagleBone, once again on Adafruit. The tutorial is found here:

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview

A pdf of the same tutorial is here:

https://learn.adafruit.com/downloads/pdf/introduction-to-the-beaglebone-black-device-tree.pdf

The above tutorials seemed to help with compiling the dts files from Waveshare. This was despite concerns due to the dts directory from Waveshare zip file explicitly having "Angstrom" in its name. The dts file was compiled to a dtbo file which I copied to /lib/firmware as shown in the adafruit tutorial (but not shown in the Waveshare tutorial, for which none of the kernel directories listed match the ones in my Debian distro), and I was able to echo the module name to the "slots" file in /sys/devices/bone_capemgr.8 and then see that it had been added. However there was no new rtc in /dev. The messages from 'dmesg | tail' all looked good up to a point, it shows the overlay being found and applied, but it still doesn't show the RTC chip being recognized. I tried manually doing the steps to add the pcf8563 to i2c-1 and it instantiated the device the same as it has been but the device still seemed to be unrecognized by any driver.

In a simple world, it should be enough to try restarting the system, but I was pretty sure that would just roll back my overlay installation, and sure enough at the bottom of the Adafruit tutorial it says "We know that restarting the system will cause the overlays to unload" and gives instruction on adding something to a configuration file to cause them to be loaded on every bootup.

Looking at the results from dmesg after manually adding the pcf8563 made me wonder what the 'i2c i2c-1: new_device: Missing parameters' message could mean, particularly since it was followed by the cheerful looking 'i2c i2c-1: new_device: Instantiated device pcf8563 at 0x51' message. The google search for this came up with some good hints but nothing that has lead to a clear 'ah-ha' moment.

Here's a readme about i2c that seems to have four separate hints about what that message could mean, none of them clear. https://www.kernel.org/doc/Documentation/i2c/instantiating-devices

Here's a forum thread with a guy who was having trouble getting his ds1307 RTC to work. It seems like he was missing a module or something, but it's not entirely clear what his problem was or what the resolution was that he found. It's also a little sad that this issue was with a pi and not a BeagleBone. https://github.com/adafruit/adafruit-raspberrypi-linux/issues/2

Possibly a related forum thread on the problem. It seems that the problem was simply that the required modules were not loaded? http://forums.adafruit.com/viewtopic.php?f=50&t=31821

Since it seems like people most often solve problems when trying to interface the ds1307 RTC, I wanted to see what would happen if I did a google search for the ds1307 module. I got more hints at the links below:

Here's the Google search: https://www.google.com/search?q=ds1307+kernel+module

Here's a forum thread started by somebody that's following the Adafruit 1307 tutorial and having trouble getting the module to load. Somebody replies with a bunch of really specific instructions which are a lot like the instructions I saw on another thread, one of which is to get the package for i2c-tools. I'm wondering if this is something that would help me? Sadly, when I did 'apt-get update' and 'apt-get install i2c-tools', I got back 'i2c-tools is already the newest version' meaning I probably already have i2c-tools. https://www.raspberrypi.org/forums/viewtopic.php?p=273354

Here's another tutorial, completely unrelated to the Adafruit one, on adding the Adafruit ds1307 stamp to a BeagleBone. It's a very nicely done tutorial, and it also shows a step of downloading the i2c-tools package. It seems like the author is using a crazy version of linux ("Archlinux Allstar"?), and to do the download he uses a command I've never seen before which is "pacman". http://www.crompton.com/hamradio/BBB_realtime_clock/

So, here is the same Google Search but with the PCF8563. The returned links seem a lot less numerous and helpful. https://www.google.com/search?q=pcf8563+kernel+module

One of the links to the above search is one that I keep hitting which is a list of module files. It doesn't provide any hints about where to find them, but it shows an entire dependency tree that is intriguing. It shows a dependence on i2c-core, which modpobe seems to indicate that I have, but it also shows dependency on rtc-core which comes back from modeprobe as missing, and also rtc-lib which also seems to be missing. http://modules.libres.ch/browse/linux/v2.6.18/powerpc/rtc-pcf8563/

This forum thread has astonishingly complete step-by-step answers to problems interfacing a DS1307 chip to a Raspberry Pi, then for some reason the same treatment is given to somebody trying to interface a PCF8563. On the surface, none of this seems to help me find a kernel module for rtc-pcf8563, but there is so much good information in this link that maybe I'm just missing something in it. https://www.raspberrypi.org/forums/viewtopic.php?t=85683

This link filled me with hope, as it lists a module named "kernel-module-rtc-pcf8563". The fact that the page is all about Angstrom modules was ominous, and indeed on my Debian distro, when I did 'apt-get update' and 'apt-get install kernel-module-rtc-8563' it came back with 'E: Unable to locate package kernel-module-rtc-8563'
http://feeds.angstrom-distribution.org/feeds/v2012.05/ipk/eglibc/armv7a/machine/beaglebone/Packages

Having read the translation, it seems like there is no new information here, but for novelty's sake here is a page from China (also the source of the Waveshare Misc Cape) on interfacing a PCF8563 chip: https://translate.google.com/translate?hl=en&sl=ko&u=http://blog.daum.net/_blog/BlogTypeView.do%3Fblogid%3D0Ps5d%26articleno%3D49%26_bloghome_menu%3Drecenttext&prev=search

Results for approach 3) Trying to compile the driver source code into either the kernel or a kernel module: I have frequently encountered some source code for a driver module for the PCF8563 chip during my web searches. It seems to come from the manufacturer of the chip, which would be Phillips (which was subsequently bought by another company):

https://github.com/jeffegg/beaglebone/blob/master/drivers/rtc/rtc-pcf8563.c

also here: https://github.com/tekkamanninja/linux-beagleboard/blob/master/drivers/rtc/rtc-pcf8563.c

and also here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-pcf8563.c?id=57d54889cd00db2752994b389ba714138652e60c

Interestingly, there seems to be a slightly different version (which still contains a line returning version 0.4.3). It can be found here:

https://stuff.mit.edu/afs/sipb/contrib/linux/drivers/rtc/rtc-pcf8563.c

and here: http://lxr.free-electrons.com/source/drivers/rtc/rtc-pcf8563.c

The reason why I think this code might be the thing that I want to try to compile is that it seems to have a version number (0.4.3) that is the same as the one shown in log messages from the rtc-pcf8563.ko module for people that already have it in their linux distribution, like as seen at these links:

http://www.boonsanti.com/setting-a-real-time-clock-to-beaglebone-black-with-rtc-pcf8563/

(Note: this is the one where the blogger talks about "Chris Boot's Forked Kernel" and he's working on a Pi) http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/

https://groups.google.com/forum/#!topic/beagleboard/YytMAKTdYrE

https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=6994

Aside from that, all I have so far are some links that seem to have helpful general advice on how to compile driver modules. I need to read all of these before I give this approach a try:

A very friendly and hopefully basic tutorial on compiling stuff into Debian: http://www.aboutdebian.com/compile.htm

A basic linux faq about kernel modules. It shows modules in the location where I find them in the BeagleBone distro, but not where the PCF8563 files seem to be in the WaveShare distro (which possibly indicates that WaveShare compiled their drivers into the kernel instead of creating a module): http://www.cyberciti.biz/faq/add-remove-list-linux-kernel-modules/

A very sparse page of information about modules, which includes at the bottom a link to the "all modules" page which shows a rtc-pcf8563 module (although it's not clear if it's the same one that I need): https://wiki.debian.org/Modules

A fairly sparse HowTo on how to compile modules. This plus some other links might give me a starting point to trying my own compilation: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html

A beginner's article for understanding Make, Configure, and other generic steps in most compilations in Linux. Probably doesn't contain anything about drivers, but could help me get started: http://www.codecoffee.com/tipsforlinux/articles/27.html

Results for approach 4) Buy a BBB preloaded with Debian: Sadly, this didn't pan out as hoped, although there might be some advantages to pursuing this further. First of all, the BBB is half the price of a regular BB, it's only $45 which is basically less than a tank of gasoline. Secondly, it's supposedly faster.

However, it didn't recognize the pcf8563 chip when I plugged it in place of the BeagleBone and didn't seem to have the driver module. It did recognize the LCD7 screen, and came up with an LDXE desktop very similar to my current one except that it had four instead of 2 desktops. However, less than 15 minutes after I started using the BBB, it crashed and wouldn't reboot; apparently the OS in flash memory got corrupted. In the short time that I used it, I noticed that it took three times longer to boot than the BB I've been using, and when I tried to run Python it didn't work despite being found in the executable path. The BBB froze while I was trying to figure out why I wasn't getting the python prompt; trying to run Python might have been the cause for the bricking. I didn't get a chance to try to figure out if it had Tkinter or even what distribution they had shipped.

My initial impression is that having the the OS in flash memory on the BBB is unreliable. I began looking into how to just run the BBB off of the SD drive like I've been doing for the BB. It turns out that this is not very easy, since the BBB will always boot from flash memory if there is something there. Also, the BBB requires you to depress a tiny switch on the board to get it to boot from SD, which is astonishing. Here are some links that I could try to sort out later if I really want to try this:

http://elinux.org/Beagleboard:Updating_The_Software#Image_for_booting_From_microSD

A commenter in this thread seems to think that you only need to push the button the first time you boot from SD, which would be helpful if true: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/_mOlo6T-70E

Some of the info in this thread, however, seems to contradict the previous one. This link has a lot of info about the uboot utility which seems to be the heart of finding the answer to this question. https://www.element14.com/community/thread/28768/l/beagleboneblackunable-to-boot-u-boot-image-from-sd-card-how-to-do-this?displayFullThread=true

Probably I just need to go through the steps of downloading a new Debian image compatible with BBB and flashing it.

Update Feb 21, 2016: Since getting started on trying to compile the driver module from source code, I've gone down a few different paths. Specifically: 3a) Learning how to compile a simple driver module from the source headers. 3b) Trying to replicate the simple driver compilation with rtc-pcf8563.c, 3c) Learning that rtc-pcf8563.c is provided in the linux source tree, trying to download the source and compile it in place.

Step 3a) Learning how to compile a simple driver module using the source headers: There are several tutorials around the internet on how to compile a simple module called hello.ko which just prints some stuff to the event logs when started and stoppped. The following two links are occasionally unreachable for some reason but from Chrome sometimes a "cached version" is offered. These examples worked perfectly as written.

http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
http://www.cyberciti.biz/tips/compiling-linux-kernel-module.html
http://www.paulkiddie.com/2009/10/creating-a-hello-world-kernel-module-in-linux/
http://www.lai18.com/content/1641206.html
http://icarus-edward.blogspot.com/2006/09/howto-build-linux-kernel-module.html

The main problem with the above turtorials was that the kernel header package was not named kernel-headers-$(uname -r) but rather linux-headers-$(uname -r). I figured this out using apt-cache search with vaguer and vaguer search terms until I realized what the problem was. Then I used sudo apt-get install to download the source header package and it unzipped it and placed it under /usr/src. The makefile provided by the first link above just worked like a charm and produced a .ko file which could be installed and uninstalled.

Step 3b) Trying to replicate the simple driver compilation with rtc-pcf8563.c: So, I excitedly downloaded rtc-pcf8563.c, and put it in a directory with the makefile from the hello.ko example and changed the name of the target in the makefile. Unfortunately, the C code didn't compile; in particular it barfed on some kind of define named "THIS_MODULE".

At this point I embarked on a big link sausage trying to figure out if I could fix my problems by downloading the entire source. My problem was that when I was doing apt-cache searches, I could find the header package as linux-headers-$(uname -r) but there didn't seem to be a corresponding package for just the source code tree. So, here are some interesting links that probably would fix things for me except none of them were dumbed-down enough for me:

Build the entire kernel? That might work. OMG way too many steps. http://elinux.org/Building_BBB_Kernel

At about the sixth step I was unable to follow what was going on with this otherwise promising tutorial, but I did notice that it employed an apt-get source linux command to get the source. https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage

This link tantalizingly promises that you can build any driver with a simple make command if you install build-essentials. This doesn't seem like it could be true. http://askubuntu.com/questions/177329/how-do-i-install-a-driver-provided-as-source-code

Some more hints about how to use apt-get source. Apparently you can compile directly from apt-get? http://askubuntu.com/questions/28372/how-do-i-get-and-modify-the-source-code-of-packages-installed-through-apt-get

Step 3c) Learning that rtc-pcf8563.c is provided in the linux source tree, trying to download the source and compile this file in place. I mean, presumably the file can be compiled if it's part of the source. For some reason, the next night's searching turned up a magic link that contains step-by-step instructions that even a dummy like myself can follow:

Here's the magic tutorial! Sadly it's got some RPM stuff in it that doesn't apply to my Debian distro, and running make oldconfig led to an hour of banging through menus because I was too impatient to copy over my .config file and the default wasn't even close to right, and I shot myself in the foot in general by skipping a lot of steps and I wasn't even using the right source tree. But this is the closest I've gotten yet to getting a clean compile. It built the .o file for the module, but something called modpost didn't see fit to make it into a .ko file. More on this learning point in later links.
http://www.pixelbeat.org/docs/rebuild_kernel_module.html

Here's the forum thread that led me to the above link. After a lot of the OP getting basic questions from commenters, there are a couple of useful answers in this thread. One of them towards the bottom has a 'make M=' example that I see a lot but which failed to work for me, however maybe I typed something wrong when I tried it.
http://www.linuxquestions.org/questions/linux-kernel-70/rebuilding-a-single-kernel-module-595116/

A link that I've posted to myself before to study, here's somebody basically doing the exact same process of compiling a single driver module, except for a raspberry pi. He downloads build-essential with apt-get, then uses wget to get the source tree, then does a patch which is one of the opaque steps of kernel building for me still. He does the same setup step for .config that the guy from the first link does that I screwed up by skipping, then does a make oldconfig. He does another wget which seems to have to do with getting his module source, then does a make modules_prepare. Then he does a different make command that hasn't worked for me yet but mostly because I keep doing with wrong, which is make -C M=. So this is a good example to try to correlate with the other examples that I've tried now that I've tried them. Just to see if it would help, I tried doing a apt-get install build-essential but I think that it came back already installed or something.
http://blog.remibergsma.com/2013/05/08/adding-a-hardware-clock-rtc-to-the-raspberry-pi/

So, after finding the above information, I first tried to do a compilation while not being very patient. I tried to apt-get the linux source, and for some reason I got a tarball for kernel 3.2 (whereas my distro is 3.8.13-bone70, so kernel 3.8 which was a big change from 3.2). However, 3.2 had all of the same RTC driver directories that the bone70 linux header directories expected, so I thought that I'd give it a try. I didn't do the step of copying my .config file from my existing /boot directory, so make oldconfig was just a mess and I ended up just accepting all of the default choices that it kept offering when it turned out to be a lot. I'm not sure if make prepare and make modules_prepare worked, but I think that they might have. In the end I got it to build the rtc-pcf8563.o file but I couldn't make it do the .ko file. I did a pile of hunting for solutions to the error message that I was getting; now I have a bunch of interesting links that didn't help, and I later learned that my problem was something else altogether.

Next I tried downloading the Debian source directories from Waveshare. The tar file was named with kernel version 3.8.13, and the directory structure that it untar'd looked exactly like what I expected. The download came with an additional directory of config files, for either beagleboard, beaglebone, and something else. I checked the beaglebone config file that came in that directory with the one in my distro and it turned out to be wildly different, and also the config file that came with the Waveshare distro didn't have the pcf8563 enabled which was odd since this was supposed to be a kernel for use with the Waveshare board. The big disappointment is that make prepare bombed out completely. I did a pile more research on what was happening, which seemed to have something to do with the Waveshare distro being set up to use a different cross compiler than what was provided in my Debian distro. A couple of half-hearted attempts to switch over the cross compiler selection in the makefile quickly led to deciding to ditch the Waveshare source altogether.

Next I tried to get the 3.8.18-bone70 source tree. Most of the beaglebone Debian pages end up pointing to a github repository. The troubling thing about those links is that it seemed to be for a 4.1 kernel which I don't even know what that would be in relation to 3.8.18. I fiddled around in the github branch that the beaglebone/4.1 code was in, and eventually found a tag for 3.8.18-bone70, but I could not figure out how to download it with git. The site has a big "Get Zip File" button, so I downloaded that and used 7zip to just completely unzip and untar it (I can't remember why I couldn't untar it on my beaglebone) then transferred the entire 400MB directory to a local directory on my beaglebone. I copied the .config file from my boot directory and updated it to enable the pcf8563 driver. Amazingly, make oldconfig, make prepare, and make modules_prepare all went completely smoothly. The make for scripts/mod didn't seem to do anything, and I got the "MODPOST 0 modules" message but kept going.

make SUBDIRS=drivers/rtc ran to completion, alright! But it still didn't make a .ko file for the rtc-pcf8563 driver, boo! It did make two others, rtc-ds2404.ko and rtc-snvs.ko. I looked for these in the .config file, and found that instead of being set to '=y' in the config file, these two were set to '=m'! I set that for the rtc-pcf8563 driver, tried to do another make and didn't get anything, redid make oldconfig, make prepare, make modules_prepare, and make SUBDIRS=scripts/mod, then did make SUBDIRS=drivers/rtc and it made my rtc-pcf8563.ko file!!!!

Following a couple of the examples that I've been trying for ages to get working, I did a modprobe i2c-tools, but when I did modprobe rtc-pcf8563, it returned with rtc-pcf8563 not found. I tried copying the file to the same directory that the rtc-ds2404.ko and rtc-snvs.ko files were, but it still didn't work. I also tried insmod and I got back a message stating: "Error: could not insert module /rtc-pcf8563.lo: Invalid module format"!!!! So, I went back to google and learned a few more things. This seems to be a versioning mismatch, despite the care with which I tried to get the correct source tree. It also seemed to produce an error in dmesg that said "rtc_pcf8563: no symbol version for module_layout". I eventually learned that this has to do with a compilation error that I watched go by during the compilation, which was "Warning: Symbol version dump /usr/src//Modules.symvers is missing; modules will have no dependencies and modversions." Apparently this is because the source tree that I built against was previously used to build the whole kernel, which produces the Modules.symvers file.

Somebody online recommended using modprobe -f to just overcome this error; I eventually further learned that this requires either copying or linking my .ko file into the directory /lib/modules/, and also not stupidly using the .ko suffix when calling the file with modprobe. insmod doesn't seem to have a -f option although I didn't check the man page for some similar force parameter. Once I finally properly did a modprobe -f rtc-pcf8563, it returned with a new error, which was "ERROR: could not insert 'rtc_pcf8563': Exec format error." This error also produces more "rtc_pcf8563: no symbol version for module_layout" lines in dmesg.

It seems that usually people brute-force their way past this by recompiling the whole kernel, but a few links that I've found show how some steps for building Modules.symvers so I thought that I'd give that a try. However, a search of my directory tree revealed that the Debian distro image had come with a Modules.symvers file. I copied it to the top of the downloaded source tree, did the entire build process again, and did not get the warning messages. I copied the new .ko file to the proper location and repeated the steps of depmod -a and modprobe and it installed! Because I had earlier installed the pcf8563 chip onto the i2c bus, the chip was instantly recognized by the driver, /dev/rtc1 was created, and I was able to read the time from it! I then copied the .ko file to the other copy that I've been using of the Debian distro, and when I placed it in /lib/modules/ I was able to repeat the steps to install the chip onto the i2c bus, have it be recognized, and was able to read the time from the RTC.

So, in conclusion, the Debian image distributed by Waveshare is broken, I'm still too stupid to figure out how to use the Device Tree and the .dts files from Waveshare, the source file trees from Waveshare are completely broken, the driver for the PCF8563 that other people seemed to be able to use already comes with the source tree for my Debian distro but it hadn't been compiled and it is still barely clear to me how to download the source tree, once the source tree for my distro was downloaded and the .config file was properly modified, a specific set of make commands could be used to build the driver into a module which is, as hoped, portable to copies of the same distro.

BeagleBone Install Debian SD Image

Because I had to search for it again, here are the steps for downloading and installing a Debian image on an SD card for the BeagleBone.

Some links:

Here is the page from BeagleBone.org which explains all of the steps: http://beagleboard.org/getting-started

BeagleBone Debian Install Tkinter

This is the procedure that I've used twice now to update a fresh Debian distribution with Tkinter. The distro comes with Python 2.7 but not Tkinter.

Step 1: Put the BeagleBone on my home network with the CAT5 cable from the router. It gets a DHCP address on the network automatically from the router.

Step 2: Go to root user.

sudo su

Step 3: Update apt-get, which synchronizes what packages my distro has and doesn't have and establishes locations to download from.

apt-get update

Step 4: Download and install Tkinter. Despite what I read online about other users' issues with this step, it seemed to work fine for me.

apt-get install python-tk

Some related links:

The basic instructions, which include the above steps http://tkinter.unpythonic.net/wiki/How_to_install_Tkinter

About how to use apt-cache search which while not specifically needed to do this installation is generally helpful. Also, aptitude is mentioned: http://askubuntu.com/questions/160897/how-do-i-search-for-available-packages-from-the-command-line

More about apt-cache search, and also some more about how to use aptitude: http://www.cyberciti.biz/faq/searching-for-packages-in-debian-ubuntu-aptitude/

BeagleBone installing PCF8563 RTC

I ordered the Waveshare "Misc Cape" which uses the PCF8563 RTC chip with an I2C interface like all of them. Waveshare's online documentation is unhelpfully brief regarding how to install drivers for it. They offer a fully compiled Angstrom distribution with their drivers but since Debian is working out so well for me on my project I was hoping to try to find a way to install drivers for Debian. At the bottom of their wiki for this cape there are a bunch of links, some of which seem to be source code and other documentation, but it's not clear what it all is.

http://www.waveshare.com/wiki/MISC_CAPE

One of the links turns out to be to two SD card images, one of which is a fully compiled Debian image that has the drivers for the PCF8563 chip built in, however when I downloaded and tried it I found that although the RTC driver seemed to work well there were other issues with the distro that have to be overcome:

http://www.waveshare.com/wiki/MISC_CAPE_Image

There are other links on the same wiki page that I'm still trying to figure out. The "User Manual" link is just to a PDF of the wiki. The Schematic is helpful but really the cape is quite simple and the schematic is a single page. The Test Code link is to a zip file named XXX_CAPE_Angstrom_API.7Z which seems to contain a mix of C programs and compiled programs which don't have anything to do with the PCF8563 and furthermore seem to be for the Angstrom kernel. The section labelled "Kernel" seems to have several different source code trees for both Angstrom and Debian kernels, presumably with driver code but at the moment I still don't know how my way around kernel source code or how to compile kernels although it looks like I'm going to have to learn. The section labeled "Kernel_config" also seems to have to do with compilation so I will have to become smarter to even understand what it is. I have absolutely no idea what the link labelled "Cross-compilation toolchain" is even referring to. Under Source Code there are several links to zip files but some obviously have nothing to do with the RTC chip (like "wifi" and "mjpg-steamer") and the one link labelled "driver" is to a zip file that just has one c file with code that also doesn't seem to have anything to do with the RTC chip. Of the three links under "Documentations" the first one "Porting Drivers" actually mentions the RTC chip but the compilation instructions are like greek to me. The link for "Porting Kernel" mysteriously seems to be about building a Ubuntu kernel, and these instructions are also opaque to me at the moment.

Looking for a shortcut to figuring out the poorly documented materials on the Waveshare wiki, I started looking at the following tutorial, which showed how to interface a different chip that is on Adafruit's RTC stamp to BeagleBone.

https://learn.adafruit.com/downloads/pdf/adding-a-real-time-clock-to-beaglebone-black.pdf

Since I also bought one of those Adafruit RTC stamps, I may yet give following this tutorial as written a try, but I thought that I could adapt the steps shown to the PCF8563. I tried doing the i2cdetect command and it found the PCF8563 at its address of 0x51. I did the command to add it as a new device and that seemed to go okay. There was an rtc0 device in /dev that I was able to write a time to and read from. I went through all the rest of the steps to set up a service to read from the rtc at bootup but whenever I power cycled the BeagleBone it would come up with a default date which was March 1, 2013.

I realized that something was writing time to the rtc, and went through a bunch of research to discover that there is a hwclock.sh script that is being called by several different boot levels in Debian that seems to be setting this default time to rtc0. The hwclock.sh script is at /etc/init.d/; the directories /etc/rcS.d/, /etc/rc0.d/, and /etc/rc6.d/ all seem to have the same script also but these are really just sim links to the one in /etc/init.d/. The other directories are used to define init scripts called at different kernel boot levels. This information is all swirling around inside the following comment thread:

https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=16218

I tried modifying this hwclock script as advised in the thread but didn't have any luck. I began to realize from reading the script and the messages in /var/log that the rtc0 device was some kind of default device and not the PCF8563 chip on my Waveshare cape after all. I tried doing modprobe commands as shown in the link above and in some other links I found and it seems like the rtc-pcf8563 "module" is something that I need and don't have and which should run when I add the chip as a new device on the I2C bus. I found some .ko files on my Debian system under /lib/modules/3.8.13-bone70/kernel/drivers/rtc but none of them are rtc-pcf8563.ko or rtc-ds1307.ko either for that matter.

A frequent hit that I keep getting while googling for the problems I am having installing this cape is the following site in what seems to be Hebrew or something. Without using Google Translate, I can tell that he's going through all the same steps that I did, using i2cdetect, adding it as a new device, and creating a service to load the system time from it a bootup. However, when he uses dmesg to check his log files after adding the device, he sees the "chip found" message that I'm not getting. I need to look at this site more carefully to understand what OS and distro he is using; if there's a chance he's using Debian it might give me a clue:

http://www.boonsanti.com/setting-a-real-time-clock-to-beaglebone-black-with-rtc-pcf8563/

Here's a listing for a Debian distribution that shows an rtc-pcf8563.ko file in the right place, but clearly this isn't my distribution. I need to find out the chances are that I can just find one of these .ko files and copy it onto my system (probably not great):

https://packages.debian.org/squeeze/armel/linux-image-2.6.32-5-versatile/filelist

Along the way as I did this research, I've learned that there is something called "fake-hwclock" which maintains current time in nonvolatile memory and reloads it during bootup, but I don't have that on my system. Here's a link with some info:

http://unix.stackexchange.com/questions/187261/automatically-update-hwclock-at-boot

I learned that Debian has a very nice editor called "nano" that has keyword color support and is easy to use (though not as easy as vi of course)

To edit system files, I had to change from the default login of user 'debian' to root, but when I tried "su root" it asked for a password. Various sites said that this distro had no password for root, but just hitting return on the password prompt wasn't working. I learned from the following page that I need to do "sudo su" to become root on this system:

http://www.element14.com/community/thread/32106/l/beagleboardorg-releases-debian-for-beaglebone-black?displayFullThread=true

I think that my system is using systemd instead of init. Here is what looks like nice info on systemd:

https://denibertovic.com/posts/setting-up-systemd-on-debian-in-10-minutes/

There's a book called "BeagleBone For Secret Agents" that had a google books excerpt that helped me better understand that rtc0 was not my cape, that it's an rtc inside the processor that doesn't retain time when powered off. It showed messages from a process named omap_rtc that was loading the default time and I was able to find those same messages on my system showing it setting the default clock to March 1, 2013. Here's the link to the google books excerpt:

https://books.google.com/books?id=i2OZBAAAQBAJ&pg=PT130&lpg=PT130&dq=omap_rtc+setting+system+time&source=bl&ots=9hLmjeWaPe&sig=j3ScuHRzYYN2Un2ljn_0gbsglgs&hl=en&sa=X&ved=0ahUKEwie9MXq5anKAhUIPT4KHZ6XB60Q6AEIJjAB#v=onepage&q=omap_rtc%20setting%20system%20time&f=false

Here's a blog by a guy who had a problem very similar to mine. He had an RTC chip that there was no module for in the distribution of Raspian that he had. He found drivers and compiled them and verified that the resulting module detected his chip. I need to carefully study this link to understand all of his steps and maybe try the same thing for my kernel and chip:

http://blog.remibergsma.com/2013/05/08/adding-a-hardware-clock-rtc-to-the-raspberry-pi/

When I google for drivers for the PCF8563, I usually get the following link, which interestingly is from a BeagleBone site so it seems that compiling this for BeagleBone is something that is done, although there don't seem to be any instructions or compiled module files at this link:

https://github.com/jeffegg/beaglebone/blob/master/drivers/rtc/rtc-pcf8563.c

Here's a guy interfacing a PCF8563 to a raspberry pi, and for some reason his kernel has the driver module already there. He does a modprobe command on rtc-pcf8563 and it works, so he goes merrily along with the rest of his installation steps.

http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/

Some links to stuff that I found which didn't directly help but I'm saving just in case:

Here's a hackaday article on the PCF8563 which goes into accessing its registers and stuff without showing any kind of finished code. Interesting, but I hope I never have to use it: http://hackaday.com/2009/06/26/parts-i2c-real-time-clock-calendar-pcf8563/

Here's a raspberry pi forum where some people are digging into the source code to find out why the rtc interface for the PCF8563 doesn't work for the PI2. Not useful to me but crazy smart: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=100132

Here's setup documentation for an expansion board for the pi that uses the PCF8563. It shows the "chip found" message that I should be seeing in my logs but am not. I wish my RTC cape had this kind of documentation: https://ludwig.im/en/projects/raspberry-pi/raspberry-pi-arpi600

It turns out that Waveshare makes another RTC board with a PCF8563 for a different kind of stamp computer development system. This information wasn't helpful however because the documentation for this other RTC board included no drivers compatible with the BeagleBone: http://www.waveshare.com/pcf8563-rtc-board.htm

Debian set system time

To set the system time in Linux is very easy; the date command allows setting of the system date and time. This does not affect any time kept by a hardware clock, the hwclock command is needed for that. The BeagleBone does not come with a hardware clock, however, so the hwclock command fails out gracefully.

sudo date --set 1998-11-02
sudo date --set 21:08:00

Reference link:

https://wiki.debian.org/DateTime

BeagleBone RTC Cape

So, it turns out that the BeagleBone (or the BeagleBone Black for that matter) does not have a battery back-up for its clock, so it loses the time every time I turn it off. It is mentioned on some websites that you have to set up an NTP access to fire on bootup to keep the clock set to the current time, but of course my application is off the network. It turns out that a few people have made something called a Real Time Clock cape that has a button cell and a particular single-chip solution to act as the Beagle Board's hardware clock. Unfortunately, the nicest of these, originally sold by BeagleBoard Toys, is no longer being made.

Presently, a multipurpose board sold by Waveshare has an RTC chip and a battery. It can be bought from the company, or interestingly from Amazon.

It is also possible to either hook up the Adafruit RTC stamp to a cape protoboard as described in this article, or completely build the BeagleBoard Toys design on a protoboard.

This article shows what commands to use to set the time on the adafruit RTC stamp once the RTC cape using it is assembled.

This forum thread has more info about different RTC chips that can be used for this sort of project.

A python app with Tcl/Tk gui file selection on a BeagleBone with LCD7 touch screen

Trying to pull together a demo user interface for my GSE box, making use of the python code from the previous demo and the hardware that I have on hand which is a BeagleBone with the LCD7 touchscreen. Along the way, a whole lot of involuntary education is occurring, so I'm documenting the journey here.

The plan:
1. Get the BeagleBone powered and figure out how to get the touchscreen working
2. Figure out if the OS for the BeagleBone has python.
3. Study the python code from the demo and glue in tcl/tk file selection dialogs where appropriate to make it more user friendly.
4. Migrate everything over to the Raspberry Pi. Supposedly all the python will be nicely portable.

Notes for each step:

1. Get the BeagleBone powered and figure out how to get the touchscreen working:

Fortunately for me, this was all already working. The hardest part was making sure that I had the polarity of my power chord correct (center positive) and that I was using a supply capable of powering the screen (needed to be 2A). In the end, I am temporarily fudging it with my cut USB chord with power plug wired on that I made for testing the GSE circuit board. The first USB power block that I tried was only 1.2A and this was insufficient, but most dual power blocks supply 2A and one of those runs it just fine. The Beagle Board website actually has very helpful links to recommended power supplies from DigiKey (http://beagleboard.org/peripheral). The Beagle Board powered up fine over USB and I'm able to use my trusty PuTTY to log into it using the default password over the USB cable. With the 2A power to the LCD7, the board finds the screen automatically, and loads a desktop GUI without any fiddling required. It turns out that the microSD card that came with the BeagleBone has a Linux distribution called "Angstrom" that is fully integrated with a Gnome desktop. The only disappointment is that the touchscreen is barely able to control this GUI without a keyboard and mouse. It is possible to drag the mouse pointer around with a finger to the screen, click by pressing, but the resolution of the GUI is so high that it's difficult to position the mouse pointer precisely enough by touch, and there doesn't seem to be an on-screen keyboard (I got an on-screen keyboard in a later Angstrom distribution that I tried, but it's not like an iPhone where it pops up when needed and is optimized for mobile use).

2. Figure out if the OS for the BeagleBone has python.

Once I got a USB keyboard and mouse connected, starting a terminal window and typing "which python" answered the question of whether python was installed. Directly starting python by just typing "python" got me the python prompt. But then, shockingly, "import Tkinter" failed. I could import other standard libraries and execute other python commands, but no Tkinter, tkinter, or _tkinter. Googling has revealed that everybody else has this problem as well. A variety of solutions have been tried, apparently. These include: a) Doing package updates in Angstrom to get Tkinter, but it seems that a simple package update is not sufficient and "rebuilding python" is required! That sounded like way too much, but somebody on a forum thread suggested b) trying out Ubuntu instead. Sadly, I've learned that the BeagleBone distribution of Ubuntu does not come with a desktop interface installed by default like in Angstrom, and its python distribution doesn't come with Tkinter either. However, in the process I learned how to get disk images for both Angstrom and Ubuntu and load them to a microSD card from the safety of my Windows laptop. Notes follow:

b. Get Ubuntu:

I started by first trying to download a new distribution of Angstrom and booting the BB from it, and it worked great. The following link contained perfect handholding for how to get the image file, where to get 7Zip for unpacking it, and where to get a Windows app for writing it to an SD card:

http://beagleboard.org/getting-started#update

Interestingly, the SD card writer app is apparently distributed by Ubuntu. Here is Ubuntu's own page about the App (and other methods of writing SD card images that don't apply to my attempts to do it from Windows):

https://help.ubuntu.com/community/Installation/FromImgFiles

The new Angstrom distribution booted up to the desktop like the original Angstrom distribution that came with the Beagle Board, but still didn't have Tkinter installed.

I was able to repeat the same image installation steps from the above guide while using the Ubuntu image pointed to from here:

http://elinux.org/BeagleBoardUbuntu#BeagleBone_White.2FBlack.2FGreen

Trying it out, I got the familiar screenfuls of grubloader lines on the LCD7, which means that it found the screen. However, no GUI! I logged in using the default password for the distribution, did a "which python" and "python" and to my surprise, still no Tkinter! While I had learned how to get Ubuntu, it hadn't solved my problem, and it turns out that I have to install a gui manually. As far as I can tell, this also means doing the step which I've so far tried to avoid which is putting the BeagleBone on a network. This is something that can't do at work, ironically enough, because of our locked-down IP assignments, and I don't have a Wi-Fi cape for the Beagle Bone, which means the only place I have to plug it into is my router at home.

Here's probably the best link which explains which packages to download and install to get Tkinter in Ubuntu and mentions the command to do the rebuild (the first comment mentions it, but scroll down to the nicer example in the second comment). This thread in particular applies to my case because I noticed that my distribution of Ubuntu had python 2.7 like the OP of this thread:

http://stackoverflow.com/questions/11752174/how-to-get-tkinter-working-with-ubuntus-default-python-2-7-install

This is the link that describes needing to install tk-dev!

The above link points to this sort of unrelated thread which has a very nice reply from someone about the general process for building Python in Ubuntu:

http://stackoverflow.com/questions/6171210/building-python-and-more-on-missing-modules

So, I read a bunch of threads about how to get a GUI for Ubuntu. Most of them agree that for BeagleBone the best one to try is LXDE. Sadly, a lot of people out there trying to make this work are using a Beagle Bone Black which is not what I have and also has on-board flash memory for the OS which I don't have.

Here is a long forum thread with a lot of clues about downloading the LXDE package and getting it to install. The scripts described from the "tools" directory seem to be on the Beagle Bone Black and not on the Ubuntu distro that I have. There's also some warnings about problems with Gnome utilities, which wouldn't affect me trying to install LXDE but I have Gnome in the Angstrom distribution and you never know when a customer is going to try to open something:

https://groups.google.com/forum/#!msg/beagleboard/TtcD9vfOzT8/1stwCBZqNRAJ

This link is mostly about BBB but is hopefully still instructional for my case:

http://elinux.org/Beagleboard:Installing_LXDE

A third option, c, is to try the BeagleBone distribution of Debian from the following link. There might be more of a chance that it will come up with a GUI desktop; BeagleBone's Angstrom distribution which had a GUI comes from the same page, and the Ubuntu distribution actually didn't come from any of BeagleBone's pages. Although reading the comments it seems that the latest Debian image from the BeagleBone page is corrupted so going down this path my end up sucking.

http://beagleboard.org/latest-images

However, when I tried it, the Debian image downloaded and booted fine and went to a GUI. It's a lot faster than Angstrom and looks nicer but doesn't have a lot of applications. It seems to be LXDE. It still doesn't have Tkinter, producing the exact same error message when I try to import it. Supposedly Debian is derived from Ubuntu or vice versa. So I launched into some more online searches:

Keying off of the specifics of the message:

Some search results from the message: File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 42:

This thread which describes the exact message, plus the "Package python-tk has no installation candidate" message I get when trying to do the installation: http://ubuntuforums.org/showthread.php?t=1959073

A thread in which somebody solved the problem by installing the library using "Synaptic", and there's also some rage about why they wouldn't just include the library. Note that I don't seem to have Synaptic on my two working Beagle Bone distros: http://askubuntu.com/questions/513981/tkinter-on-ubuntu-14-04-seems-not-to-work

A page about How to install Tkinter, however it doesn't seem to mention needing tk-dev as another search seems to have turned up: http://tkinter.unpythonic.net/wiki/How_to_install_Tkinter

Some search results from: E: Package 'python-tk' has no installation candidate:

A thread that describes what I'm seeing exactly, but no apparent solutions. A link to a python man page about Tkinter, some suggestions to check the repository list (which is probably my issue since I'm not even on a network)http://ubuntuforums.org/showthread.php?t=361342

The python wiki page mentioned above, which includes such interesting categories as "Tkinter Folklore"https://wiki.python.org/moin/TkInter

An interesting thread with a newbie in which it is eventually resolved that he's not getting to the mirrorshttp://ubuntuforums.org/showthread.php?t=1629083

Searching for Sneakernet options for doing package updates:

A thread full of different ideas, like using Synaptic, an offline repository program, apt-mirror, using apt-get with some kind of verbose arguments, and other hints: http://askubuntu.com/questions/974/how-can-i-install-software-or-packages-without-internet-offline

A short thread where somebody gives a link to Ubuntu's packages web page: http://ubuntuforums.org/showthread.php?t=1488395

A hint which seems to be to run apt-get while navigated to the thumb drive, an interesting idea. Also mentions running dpkg: http://www.linuxquestions.org/questions/linux-newbie-8/install-new-packages-from-usb-drive-using-apt-get-4175417568/

Another instructional about using dpkg: http://www.pendrivelinux.com/how-to-install-deb-packages/

So, in the end, I brought the board home and plugged it into my FiOS router with the Debian OS installed; it got a DHCP address immediately and got on the network with no issues. I began following the instructions for doing package updates for Ubuntu using apt-get, and they worked very smoothly. I had to do the following:

sudo apt-get update

sudo apt-get install python-tk

And that seemed to fix it! From within the python prompt, I was able to import Tkinter and launch dialog boxes like I plan to do with my final program. Apparently, rebuilding python as described in the Ubuntu links was not required.

After getting that to work, I was curious to see if I could get it to work for Angstrom. Angstrom doesn't seem to use apt-get, it uses opkg. I did

opkg update

opkg list | grep tkinter

opkg install tkinter

(I have to check that the last line is exactly the one that I did). Anyhow, it didn't work. I also tried:

opkg install tk-dev

It downloaded and installed, but still no love from "import Tkinter". I was unable to "rebuild" python according to the instructions in the one link that explained it because Make failed with some error message that didn't make any sense, and I couldn't find a "configure" script in the python lib directory. It is probably likely that I haven't actually downloaded the python source directory.

Rather than address that problem directly, I decided to turn back to getting a GUI for the Ubuntu distribution, now that I'd overcome my fear of putting the Beagle Bone on my home network and had gotten through a cycle or two of downloading and installing packages. One of the many web searches I'd done had shown some much nicer-looking Tcl/Tk dialog boxes for a Ubuntu desktop which makes sense since Tkinter uses whatever API is native to the OS. After some searching through links like the following:

http://www.makeuseof.com/tag/10-top-linux-desktop-environments-available/

http://www.javacodegeeks.com/2014/02/5-most-awesome-desktop-environments-for-ubuntu.html

I decided that the desktop I saw must have been the "Unity" desktop which is the one that is most often used with Ubuntu anyhow. It looks like this:

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgokrjrPlbVvsolhVc4Gvl5Fx9-RealsRXfJbUyT-QS-s0v8WZEKjLhHAE_8H8fGGD8UgBqAmvyIiHdfTqQwt64RQRKcwEKLW_tHwI0cEk83i_IMjwegtL7qMzDX7hDgiSMC9wPChIeHEvB/s1600/ubuntu-precise-apps-screenshot.png

So to get Unity, there seems to be a circle of links describing how to install it on an SD card for Beagle Bone. Some of these are for BBB which I don't have, and some talk about "expanding" the disk partition on the SD which again sounds like a lot of work. I guess I should try these though:

http://elinux.org/Beagleboard:Ubuntu_On_BeagleBone_Black#Ubuntu_Precise_On_Micro_SD

http://elinux.org/Beagleboard:Desktops_On_Ubuntu/Debian#Ubuntu_Precise_On_A_microSD_With_Ubuntu_Desktop

I'm not sure yet what the difference is between Unity and Precise. Unity is supposedly the default desktop, while the links mention Precise, and they both look the same in Google image searches.

Here's an instructible about installing Ubuntu with LXDE, presumably the procedure for installing Unity would be similar. Since I apparently already have LXDE with my Debian install, my interest is in trying to experiment with something visually different:

http://www.instructables.com/id/BeagleBone-Ubuntu-OS-LXDE-GUI/