Showing posts with label Debian. Show all posts
Showing posts with label Debian. Show all posts
Saturday, November 17, 2018
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
Thursday, February 2, 2017
Raspberry Pi Thumb Drive Not Mounting
After reassembling our Raspberry Pi 3 system, thumb drives plugged into the USB port are recognized and the dialog box appears that asks if you want to open it in a file browser, but when the browser window opens it fails with a dialog box that says "The specified directory /media/pi/[name of drive] is not valid." The troubling thing is that it used to work fine before.
The answer, after trying dozens of approaches, turned out to be that the permissions on the /media/pi directory weren't set right. Finding this answer was made tricky because I was comparing the directory permissions to those on another pi that didn't have the problem, and the directory permissions matched. I learned however that the other system had an Access Control List set on the directory that gave additional permissions to the pi user. Setting up the original pi to have an access control list to match the working one fixed the problem of the thumb drive not being mounted correctly when plugged in, but then for some reason whenever an eject was done from the file browser the eject widget on the task bar would show an error that the drive had been removed without being ejected. That problem was fixed by updating the lxpanel package on the old pi; it turns out that the eject widget is part of the lxpanel and not a stand-alone app.
Troubleshooting notes taken during the course of figuring all this out follow:
Another tutorial about USB drive mounting. Doesn't cover the automounter but has an amazing assortment of tips and tricks that I haven't seen elsewhere:
https://pimylifeup.com/raspberry-pi-mount-usb-drive/
Trying to enable the wifi:
Just turning on the hotspot on my phone, the hotspot wasn't found when scanning. This set of instructions involves tethering the phone to the Pi over USB before making the connection to the hotspot. Why? I don't know! But it didn't work; the Pi never found the phone, possibly due to whatever problem is occuring with the USB in the first place.
http://www.daveconroy.com/how-to-tether-your-raspberry-pi-with-your-iphone-5/
Returning to working on why automount is failing, looking in the message logs, there are strange error messages such as: "error opening /media/pi/9005-048F/BDMV/index.bdmv"
So, I downloaded usbmount, and a thumb drive is now mounted and opens in file browser when plugged in.
But it can't be ejected without a dialog asking for the password for the user account (there isn't one, which means that this dialog can't be answered! A couple of search results for the dialog came up with suggestions to change some policy settings:
askubuntu.com/questions/552503/stop-asking-for-authentication-to-mount-usb-stick
Now the eject buttons for the drive in the file browser seem to unmount the drive, but a message appears from tbe eject app saying that the drive was removed wirhout being ejected.
(along the way, found this interesting thread about somebody having problems booting from a usb hd, solved by adding a config parameter for a wait before first access to an external drive:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=109589 )
Things that are different between the working and nonworking images:
File permissions for working system:
/media: drwxr-xr-x root:root
/media/pi: drwxr-x---+ root:root
/media/pi/SETTINGS: drwxr-xr-x root:root
File permissions for the nonworking system:
/media drwxr-xr-x root:root
/media/pi: drwxr-x--- root:root
ls /media/pi: Permission Denied
The SETTINGS directory is apparently the NOOBS config files.
http://raspberrypi.stackexchange.com/questions/60609/settings-drive-accidentally-renamed/60683
Looking at all files under /etc, SETTINGS is mentioned in the mtab file, which is the list of all presently mounted file systems.
the (+) on the file permissions for the working system means that it's an access control list?
https://ubuntuforums.org/showthread.php?t=2206434
https://wiki.archlinux.org/index.php/Access_Control_Lists
Again, in the following example /media/pi has a (+). His drive doesn't automount though and he never gets an answer to his question
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=135178B
Results from getfacl /media/pi in the working system:
#file: media/pi
#owner: root
#group: root
user::rwx
user:pi:r-x
group::--
mask::r-x
other:---
Added an ACL to /media/pi using the example in this page (this page is filled with extremely easy-to-follow instructions BTW):
http://www.htpcguides.com/properly-mount-usb-storage-raspberry-pi/
Now I can access /media/pi as user pi, and when I plug the thumb drive in, it comes up in the browser without error!!! Also, the drive is not greyed out in the eject widget!!!
But there's still something not right that works using the new NOOBS configuration! When I eject it using the eject button in the browser, the eject widget still says "...was removed without ejecting Please use menu to eject before removal" This does not happen in the working system.
Apparently the button in the file manager is separate from the button in the eject widget. There are many, many posts online from people who have problems using the button in the file manager but they are almost all people who don't have the "eject" package installed. I triple checked and it is installed on both of my systems.
I did a bunch of googling of how to configure the file browser.
I learned that it's called "File Manager" and it has a menu option for "Preferences" which has settings for how to respond to a USB volume being plugged in!!!!! Strangely there doesn't seem to be settings in preferences for how to respond to requesting and eject? I don't understand why that wouldn't be there. However, I discovered that the File Manager program has a name; it's named PCManFM. Amazingly it was developed in Taiwan, released under GNU public license, and is the default file browser in LDXE which Raspbian is a flavor of.
Searching my working unit, I find a virtual pile of applicable .conf files under /etc! These are not necessarily in the locations hinted at by the 2010 blog post, so some tweaking has apparently occured
Of those, libfm.conf doesn't have anything particularly interesting except for a flag for "use_trash" which means that if I ever need to turn that on or off I now know where to do it. The contents of the other three .conf files vary with respect to each other, with the default and LDXE-pi pcmanfm.conf containing three scant configuration lines in a [volume] block of parameters, none of which seem to include anything about unmounting or what code gets run for mounting! The LDXE pcmanfm.conf oddly doesn't contain a [volume] section. All three have parameters different from each other that seem mostly to do with the look and feel.
Having learned all that, I keep finding hints that the configuration for pcmanfm is in .desktop files, which I don't know much about but have to learn now I guess.
Sadly, I don't seem to have ~/.local/share/file-manager/actions/umount.desktop. Actually my ~/.local/share directory doesn't have a file-manager directory, just applications, desktop-directories, gvfs-metadata, and Trash, none of which even contain anything interesting.
This is all very well and good, but I checked /var/log/syslog on both the working and now-only-slightly-not-working system and they show nearly identical log messages when a drive is ejected from pcmanfm. Both systems have the following messages from udisksd:
Also, that is the message on both systems whether the drive is ejected from pcmanfm or the ejector widget.
So, perhaps the problem that's causing the ejector desktop widget to throw an error message when a drive is ejected from pcmanfm isn't in pcmanfm after all, but in the ejector widget instead.
Could this problem be solvable by adjusting the ejector's configuration? The first step is to find the ascii config files that govern the configuration.
Interestingly, the actual setup seems to be under ~/.config/lxpanel/LXDE-pi/panels. The file which establishes the ejector is ~/.config/lxpanel/LXDE-pi/panels/panel, and at the end there is just a section as follows:
So, on the working system at least, the Config for "ejecter" is empty. It is interesting that it is spelled "ejecter" though. Googling for more information about it reveals github repositories for ejecter.c. This seems to indicate that, bad news, this is a compiled part of the kernel. Interestingly though the checkin notes in these repositories seem to show that the file might have been updated recently to specifically address the error messages that I'm seeing. It could be that thanks to the horrible old NOOBS that we were shipped that the problem might be just that the problem kernel is old enough not to have recent updates to ejecter.c!
Reading through the code on the above repositories, I can see that it contains the text from the dialog messages that show up whenever something is ejected either "wrong" or "right" on my troublemaking distro. But there just don't seem to be arguments. It is an internally complicated, but seemingly stand-alone and toasterlike tool. There are calls in the code to a DEBUG routine which probably does stuff if the appropriate compile flags are set, this isn't going to help me. All I've got to pin my hopes to now is that there might be a way to upgrade the app on my crappy system with the version of the app on my good system. But how?
So now I need to ask, if ejecter is a stand-alone package that can be downloaded using apt-get, is there a way for me to update one of my copies of ejecter? Can I find out what version is running on each of my systems first?
Based on all of the above, I was able to itereate through getting the installed versions of the lxpanel on both the old and the new pi, then update lxpanel on the old pi, and the error message from the eject plug-in no longer appears when the thumb drive is ejected from the browser!!!
On the new system:
On the old system:
The above results show that the old system has an older version of lxpanel (0.7.2-1+rpi4 versus 0.7.2-1+rpi12) and furthermore apt-list shows that there is an upgrade waiting (0.7.2-1+rpi16)!
Performed the upgrade using:
checked for any signs of errors in the update, and rebooted. The system came back up, and lxpanel didn't look any different, but now I am able to insert the thumb drive, open it in a file browser, then eject it without getting any alerts from the eject widget in lxpanel. Checking the installed version using apt list --installed shows that the new version is 0.7.2-1+rpi16. Mission accomplished!
Now that that's done, here are a few links to unrelated but interesting learning that I encountered along the way:
The answer, after trying dozens of approaches, turned out to be that the permissions on the /media/pi directory weren't set right. Finding this answer was made tricky because I was comparing the directory permissions to those on another pi that didn't have the problem, and the directory permissions matched. I learned however that the other system had an Access Control List set on the directory that gave additional permissions to the pi user. Setting up the original pi to have an access control list to match the working one fixed the problem of the thumb drive not being mounted correctly when plugged in, but then for some reason whenever an eject was done from the file browser the eject widget on the task bar would show an error that the drive had been removed without being ejected. That problem was fixed by updating the lxpanel package on the old pi; it turns out that the eject widget is part of the lxpanel and not a stand-alone app.
Troubleshooting notes taken during the course of figuring all this out follow:
This result from googling the error message is somebody who eventually figured out that his system was missing usbmount. I could try installing usbmount, but it doesn't seem like this would be my problem because USB drives used to mount on my system (unless something somehow got messed up when I cloned the SD card): http://unix.stackexchange.com/questions/325962/the-specified-directory-media-fa-faf9-c03-is-not-valid-error-when-trying-to
By following these instructions, I am able to mount the drive into a new location, access it, and unmount it. I found that the strange serial number in the error message appeared in the list of devices by id, and that a /dev/sda1 device had been created, so all of the assumptions in these instructions about what I would find were true: http://www.raspberrypi-spy.co.uk/2014/05/how-to-mount-a-usb-flash-disk-on-the-raspberry-pi/
Here's another set of instructions on mounting a thumb drive that look good but I haven't really looked at them yet because the first one worked so well: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=35695
Another tutorial about USB drive mounting. Doesn't cover the automounter but has an amazing assortment of tips and tricks that I haven't seen elsewhere:
https://pimylifeup.com/raspberry-pi-mount-usb-drive/
Trying to enable the wifi:
"It should just work" meaning there's a graphical tool from the menu bar (which I can't find): https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=138137
Gorgeous step by step instructions on enabling the wifi from the command line, which worked right up to the point of configuring the wifi password in a plain text file. The problem is that our guest network requires authentication via a web page with a form. But I was able to scan for local networks at least using these steps:
https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md
http://www.makeuseof.com/tag/setup-wi-fi-bluetooth-raspberry-pi-3/
So trying to login this type of network is basically impossible in Pi: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=152447
The problem is so bad that all of the serious suggestions on this page are ridiculous: raspberrypi.stackexchange.com/questions/34008/connect-to-public-wifi-hotspot
Here's somebody who actually finds an answer, but later on somebody points out that I can just use the portable hot spot from my phone: unix.stackexchange.com/questions/118289/how-do-i-authenticate-to-a-wireless-providers-open-network-without-using-a-br
Just turning on the hotspot on my phone, the hotspot wasn't found when scanning. This set of instructions involves tethering the phone to the Pi over USB before making the connection to the hotspot. Why? I don't know! But it didn't work; the Pi never found the phone, possibly due to whatever problem is occuring with the USB in the first place.
http://www.daveconroy.com/how-to-tether-your-raspberry-pi-with-your-iphone-5/
Returning to working on why automount is failing, looking in the message logs, there are strange error messages such as: "error opening /media/pi/9005-048F/BDMV/index.bdmv"
Somebody reports that these are file types for blu-ray disks? https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=154836
This thread's resolution seems to suggest that it's a power starvation issue (if so this is bad news for my system): https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=124532
About the 'action 17' errors also seen in the log (apparently unrelated stuff):
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=155803
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=152405
So, I downloaded usbmount, and a thumb drive is now mounted and opens in file browser when plugged in.
But it can't be ejected without a dialog asking for the password for the user account (there isn't one, which means that this dialog can't be answered! A couple of search results for the dialog came up with suggestions to change some policy settings:
askubuntu.com/questions/552503/stop-asking-for-authentication-to-mount-usb-stick
Now the eject buttons for the drive in the file browser seem to unmount the drive, but a message appears from tbe eject app saying that the drive was removed wirhout being ejected.
(along the way, found this interesting thread about somebody having problems booting from a usb hd, solved by adding a config parameter for a wait before first access to an external drive:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=109589 )
Things that are different between the working and nonworking images:
File permissions for working system:
/media: drwxr-xr-x root:root
/media/pi: drwxr-x---+ root:root
/media/pi/SETTINGS: drwxr-xr-x root:root
File permissions for the nonworking system:
/media drwxr-xr-x root:root
/media/pi: drwxr-x--- root:root
ls /media/pi: Permission Denied
The SETTINGS directory is apparently the NOOBS config files.
http://raspberrypi.stackexchange.com/questions/60609/settings-drive-accidentally-renamed/60683
Looking at all files under /etc, SETTINGS is mentioned in the mtab file, which is the list of all presently mounted file systems.
the (+) on the file permissions for the working system means that it's an access control list?
https://ubuntuforums.org/showthread.php?t=2206434
https://wiki.archlinux.org/index.php/Access_Control_Lists
Again, in the following example /media/pi has a (+). His drive doesn't automount though and he never gets an answer to his question
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=135178B
Results from getfacl /media/pi in the working system:
#file: media/pi
#owner: root
#group: root
user::rwx
user:pi:r-x
group::--
mask::r-x
other:---
Added an ACL to /media/pi using the example in this page (this page is filled with extremely easy-to-follow instructions BTW):
http://www.htpcguides.com/properly-mount-usb-storage-raspberry-pi/
Now I can access /media/pi as user pi, and when I plug the thumb drive in, it comes up in the browser without error!!! Also, the drive is not greyed out in the eject widget!!!
But there's still something not right that works using the new NOOBS configuration! When I eject it using the eject button in the browser, the eject widget still says "...was removed without ejecting Please use menu to eject before removal" This does not happen in the working system.
Apparently the button in the file manager is separate from the button in the eject widget. There are many, many posts online from people who have problems using the button in the file manager but they are almost all people who don't have the "eject" package installed. I triple checked and it is installed on both of my systems.
Here's are some of those people who simply had to run sudo apt-get install eject. How jealous these links make me!
http://raspberrypi.stackexchange.com/questions/14843/how-to-eject-usb-device-on-raspberry-pi-not-just-unmount
http://kj-til.blogspot.com/2013/11/eject-usb-drive-error-and-fix.html
https://www.raspberrypi.org/forums/viewtopic.php?t=18364
Here's a guy who wants to have the eject buttons in the file browser be removed or disabled. It seems like this would be pertinent to helping me find out how to change their behavior, but sadly nobody answers this forum question! Also this would be pertinent because the file browser is including eject buttons for the main SD card which makes no sense and probably would be bad if somebody hits them: http://askubuntu.com/questions/862592/remove-or-disable-eject-button-in-files-file-manager-for-second-internal-hdd
I did a bunch of googling of how to configure the file browser.
I learned that it's called "File Manager" and it has a menu option for "Preferences" which has settings for how to respond to a USB volume being plugged in!!!!! Strangely there doesn't seem to be settings in preferences for how to respond to requesting and eject? I don't understand why that wouldn't be there. However, I discovered that the File Manager program has a name; it's named PCManFM. Amazingly it was developed in Taiwan, released under GNU public license, and is the default file browser in LDXE which Raspbian is a flavor of.
This wiki article on pcmanfm goes out of its way to mention that pcmanfm handles thumb drives (the keyword is "volumes") but does not point to any specifics about how it is configured. Also the original page seems to have been hacked so this link is to an archived version: https://webcache.googleusercontent.com/search?q=cache:2Sk4YDcqHgEJ:https://wiki.lxde.org/en/PCManFM+&cd=2&hl=en&ct=clnk&gl=us
Here is an overview of what pcmanfm is, with a hint that it handles automounting but it doesn't say anything here about unmounting. It mentions that there is a daemon mode for detecting new removable media, and specifically mentions my USB automounting problem with a link to a different article: https://wiki.archlinux.org/index.php/PCManFM
The link from the pcmanfm link about USB drive authorization problems. This actually is about the policy settings that were discussed in a different answer that I found during my disastrous experiment with installing usbmount; this wiki page is for something called "polkit" which seems to be a tool for modifying the policies that I was manually editing to get usbmount to allow an unmount without a password: https://wiki.archlinux.org/index.php/Polkit#Mounting_storage_without_password
This github README mentions that Volume management is done with glib, which relies on gvfs. Also that there is an --enable-udisks configure option, but doesn't go into detail about how those are setup.https://github.com/lxde/libfm
This blog post from a pcmanfm developer in 2010 gives the hint that the configuration file is named libfm.conf, and there are also relevant configuration parameters in ~/.config/libfm/libfm.conf. Worryingly, a commenter asks downthread if there will be an "unmount safely option," so maybe one didn't get implemented in 2010? https://webcache.googleusercontent.com/search?q=cache:5ufMWNwOmn0J:https://blog.lxde.org/2010/07/04/direct-udisks-support-for-libfm-and-pcmanfm-is-finished/+&cd=2&hl=en&ct=clnk&gl=us
Searching my working unit, I find a virtual pile of applicable .conf files under /etc! These are not necessarily in the locations hinted at by the 2010 blog post, so some tweaking has apparently occured
/etc/xdg/libfm/libfm.conf
/etc/xdg/pcmanfm/default/pcmanfm.conf
/etc/xdg/pcmanfm/LDXE/pcmanfm.conf
/etc/xdg/pcmanfm/LDXE-pi/pcmanfm.conf
Of those, libfm.conf doesn't have anything particularly interesting except for a flag for "use_trash" which means that if I ever need to turn that on or off I now know where to do it. The contents of the other three .conf files vary with respect to each other, with the default and LDXE-pi pcmanfm.conf containing three scant configuration lines in a [volume] block of parameters, none of which seem to include anything about unmounting or what code gets run for mounting! The LDXE pcmanfm.conf oddly doesn't contain a [volume] section. All three have parameters different from each other that seem mostly to do with the look and feel.
This git repository lists the --enable-udisks option as a parameter for building it (sad) but says that it is defaulted to yes (happy)!!! https://github.com/raspberrypi/libfm-1.2.3/blob/master/configure
This man page for udisks indicates that detach and eject are both options, with parameters that are not listed in this page: https://udisks.freedesktop.org/docs/1.0.5/udisks.1.html
This github code indicates that there is a utility named udisks-eject; perhaps this is what is called by pcmanfm on my working system (Update, it's unlikely). If so I wonder how to find the option that specifies it? https://github.com/patrikf/udisks-eject/blob/master/udisks-eject
Unrelatedly, here is an interesting developer's discussion on what context menus to put on the eject options for Nautilus, a similar file browser to pcmanfm. They're talking about the same thing so there's probably interesting stuff to learn here, but it's mostly argument about GUI philosophies.https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/28835
Having learned all that, I keep finding hints that the configuration for pcmanfm is in .desktop files, which I don't know much about but have to learn now I guess.
This guy researched how to customize the pcmanfm option. This is getting soooo close! He's trying to set it up to use udisksctl which I've also seen in other links. He is advised to put something in ~/.local/share/file-manager/actions/umount.desktop http://askubuntu.com/questions/633027/eject-usb-drive-action-for-pcmanfm
Sadly, I don't seem to have ~/.local/share/file-manager/actions/umount.desktop. Actually my ~/.local/share directory doesn't have a file-manager directory, just applications, desktop-directories, gvfs-metadata, and Trash, none of which even contain anything interesting.
This page, which I actually found a while ago, mentions config files in ~/.config! It mentions a .config/pcmanfm directory, which I have! I have a LXDE-pi directory instead of the lubuntu directory mentioned in the post but that all makes sense! And there's pcmanfm.conf! Its contents are a little different from the one in /etc/xdg/pcmanfm/LXDE-pi though. There's some wind size, then interestingly the local one has a parameter close_on_unmount=1! This parameter isn't in any of the three pcmanfm.conf files under /etc/xdg. I wonder where it came from? https://ubuntuforums.org/showthread.php?t=2214272
OMG this link referred to from the previous link has so much relevant information! https://ubuntuforums.org/showthread.php?t=2214389&p=12973843#post12973843
But wait! This post under the pi forums has somebody adding a behavior to pcmanfm by creating a ~/.local/share/file-manager/actions out of thin air and then putting stuff into it. Well, since my working system doesn't have a ~/.local/share/file-manager directory, I know that this can't be how it is doing it, but this still seems like a really potentially useful trick: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=146711
This is all very well and good, but I checked /var/log/syslog on both the working and now-only-slightly-not-working system and they show nearly identical log messages when a drive is ejected from pcmanfm. Both systems have the following messages from udisksd:
udisksd[task number]: Cleaning up mount point /media/pi/(device 8:1 is not mounted)
udisksd[task number]: Unmounted /dev/sda1 on behalf of uid 1000
Also, that is the message on both systems whether the drive is ejected from pcmanfm or the ejector widget.
So, perhaps the problem that's causing the ejector desktop widget to throw an error message when a drive is ejected from pcmanfm isn't in pcmanfm after all, but in the ejector widget instead.
Could this problem be solvable by adjusting the ejector's configuration? The first step is to find the ascii config files that govern the configuration.
This page doesn't talk about the configuration files, it's about an exercise in setting up the configuration of a generic LXDE desktop to look like the Raspbian desktop, but it's delightfully geeky. www.zdnet.com/article/how-to-customise-your-linux-desktop-lxde/
This page however does go into great specifics on where to find the setup files under /etc/xdg/lxsession/LXDE-pi and ~/.config/lxsession/LXDE-pi.www.raspberrypi-spy.co.uk/2014/05/how-to-autostart-apps-in-rasbian-lxde-desktop/
Interestingly, the actual setup seems to be under ~/.config/lxpanel/LXDE-pi/panels. The file which establishes the ejector is ~/.config/lxpanel/LXDE-pi/panels/panel, and at the end there is just a section as follows:
Plugin {type=ejecter}
Config {
}
So, on the working system at least, the Config for "ejecter" is empty. It is interesting that it is spelled "ejecter" though. Googling for more information about it reveals github repositories for ejecter.c. This seems to indicate that, bad news, this is a compiled part of the kernel. Interestingly though the checkin notes in these repositories seem to show that the file might have been updated recently to specifically address the error messages that I'm seeing. It could be that thanks to the horrible old NOOBS that we were shipped that the problem might be just that the problem kernel is old enough not to have recent updates to ejecter.c!
https://github.com/raspberrypi/lxpanel/commits/master/plugins/ejecter
https://github.com/raspberrypi/lxpanel/blob/master/plugins/ejecter/ejecter.c
Reading through the code on the above repositories, I can see that it contains the text from the dialog messages that show up whenever something is ejected either "wrong" or "right" on my troublemaking distro. But there just don't seem to be arguments. It is an internally complicated, but seemingly stand-alone and toasterlike tool. There are calls in the code to a DEBUG routine which probably does stuff if the appropriate compile flags are set, this isn't going to help me. All I've got to pin my hopes to now is that there might be a way to upgrade the app on my crappy system with the version of the app on my good system. But how?
This thread is just some neckbeards helping a noob bang on an only slightly related problem, but lots of minor clues like ways to figure out version numbers of installed packages (debsums? dpkg's -S flag? apt-file?) and the locations of the desktop setup files: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=148101&sid=7830622a975fc16cd8e9db8ec742aceb
Here's a github repo that shows ejecter.c being under the lxpanel app: https://github.com/raspberrypi/lxpanel/blob/master/plugins/ejecter/ejecter.c
Some background on lxpanel and its configuration files, but nothing that specifically mentions ejecter: https://wiki.lxde.org/en/LXPanel#Main_Config_File
A pretty nice introductory tutorial about lxpanel which describes how the applets work (again without specifically mentioning ejecter). It does say something to the effect of "The configuration is stored in ascii files, but it's not a good idea to muck around with them directly." Which is probably a good idea but I can't stop myself. http://pclosmag.com/html/Issues/201010/page07.html
Another description of lxpanel that mentions "volume control" with no further details like if it's built-in or separate. Maybe I have to update all of lxpanel to update ejecter? This was from a search of "lxpanel" on this site, where a search of "ejector" produced no results: https://packages.debian.org/jessie/lxpanel
Alright, now we're getting close: Here's a guy who had a problem in lubuntu running ejecter specifically, and to troubleshoot it he was able to run it from a command line! His problem was that it crashed though, and it's not clear if this was due to a bug or because you can't run it from a command line. The forum thread ends with the discovery that there is a bug report out on ejecter and it is recommended that it not be used! Not sure why there wouldn't be better google hits if this actually happened. https://forum.lxde.org/viewtopic.php?f=8&t=31726
Ok this is interesting: A guy asks if there's an app in ubuntu that will unmount USB drives, and somebody describes in perfect detail how to add ejecter as an "indicator" that can be started at login by adding a config file to ~/.config/autostart. This is the clearest implication that ejecter is a complete and stand-alone executable, and furthermore the responder also show it being downloaded using apt-get! (Note: somebody else replied with a link to a list of file browsers that can be run under ubuntu. It was inapplicable to the original question but actually still interesting): http://askubuntu.com/questions/145087/lubuntu-panel-applet-or-indicator-to-display-mounted-volumes
So now I need to ask, if ejecter is a stand-alone package that can be downloaded using apt-get, is there a way for me to update one of my copies of ejecter? Can I find out what version is running on each of my systems first?
This link has many answers! Apparently I can use sudo apt-get --only-upgrade install [package name]. Some say that just sudo apt-get install is necessary to update. The Synaptic Package Manager has a "mark for upgrade" option but it is not clear if this will upgrade a single package or the entire distro. Apparently sudo apt-cache policy [package name] will get the list of all version numbers, and then it's possible to specify a particular version number when doing sudo apt-get install!!! Someone reported that the syntax for only-upgrade is apt-get --only-upgrade true install [package]. And then there are examples of using dpkg -s to find if something is installed, complete with a gloriously terse one-liner. http://askubuntu.com/questions/44122/how-to-upgrade-a-single-package-using-apt-get
Wow! Hints for how to list available versions! There's a package called rmadison that does it, and apparently the "policy" argumement might apply to apt-cache not apt-get: http://askubuntu.com/questions/447/how-can-i-see-all-versions-of-a-package-that-are-available-in-the-archive
More of the above hints. Also the question is asked how to tell what version is installed but the answer is that unless a -v argument was coded in there's no way to tell: http://askubuntu.com/questions/428772/how-to-install-specific-version-of-some-package/428778
This link, however seems to indicate that aptitude or dpkg will work just fine to get a list of the version numbers of installed packages: http://askubuntu.com/questions/17823/how-to-list-all-installed-packages
Not directly pertinent but still very interesting, this forum thread contains a discussion of how to use the list of version numbers of installed packages to make an exact clone of an installation: http://askubuntu.com/questions/9135/how-to-backup-settings-and-list-of-installed-packages
An unrelated other example of using apt-cache policy to get version numbers: https://www.raspberrypi.org/forums/viewtopic.php?t=136412&p=907548
Based on all of the above, I was able to itereate through getting the installed versions of the lxpanel on both the old and the new pi, then update lxpanel on the old pi, and the error message from the eject plug-in no longer appears when the thumb drive is ejected from the browser!!!
On the new system:
$ lxpanel -v
lxpanel 0.7.2
$apt list --installed | grep lxpanel
lxpanel/stable.now 0.7.2-1+rpi12 armhf [installed]
lxpanel-data/stable.now 0.7.2-1+rpi12 all [installed.automatic]
$apt-cache madison lxpanel
lxpanel | 0.7.2-1+rpi12 | http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
lxpanel | 0.7.2-1 | http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages
$apt-cache policy lxpanel
lxpanel:
Installed: 0.7.2-1+rpi12
Candidate: 0.7.2-1+rpi12
Version table:
*** 0.7.2-1+rpi12 0
500 http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
100 /var/lib/dpkg/status
0.7.2-1 0
500 http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages
On the old system:
$ lxpanel -v
lxpanel 0.7.2
$apt-cache madison lxpanel
lxpanel | 0.7.2-1+rpi16 | http://archive.raspberrypi.org/debian/ jessie/ui armhf Packages
lxpanel | 0.7.2-1 | http://mirrordirector.raspbian.org/raspian/ jessie/main armhf Packages
$apt list --installed | grep lxpanel
lxpanel/now 0.7.2-1+rpi4 armhf [installed,upgradable to: 0.7.2-1+rpi16]
lxpanel-data/now 0.7.2-1+rpi4 all [installed,upgradable to: 0.7.2-1+rpi16]
The above results show that the old system has an older version of lxpanel (0.7.2-1+rpi4 versus 0.7.2-1+rpi12) and furthermore apt-list shows that there is an upgrade waiting (0.7.2-1+rpi16)!
Performed the upgrade using:
sudo apt-get --only-upgrade install lxpanel
checked for any signs of errors in the update, and rebooted. The system came back up, and lxpanel didn't look any different, but now I am able to insert the thumb drive, open it in a file browser, then eject it without getting any alerts from the eject widget in lxpanel. Checking the installed version using apt list --installed shows that the new version is 0.7.2-1+rpi16. Mission accomplished!
Now that that's done, here are a few links to unrelated but interesting learning that I encountered along the way:
Here's how to add a command to an lxpanel menu: https://forum.lxde.org/viewtopic.php?t=31110
Here's how to add a CD eject button (not even remotely close to what I am trying to do, but interesting) to a desktop widget:https://forum.lxde.org/viewtopic.php?f=8&t=36444
Here's another one on adding commands to an lxpanel menu: http://unix.stackexchange.com/questions/177386/how-can-i-add-applications-to-the-lxpanel-application-launch-bar-via-cli
How to write C code to build a new plugin for lxpanel! https://wiki.lxde.org/en/How_to_write_plugins_for_LXPanel:_pre-0.7_version
The wiki for lxpanel itself: https://wiki.lxde.org/en/LXPanel
Some discussions of commands for safely ejecting and unmounting a USB drive. Interesting stuff about the lsblk command and udisksctrl: http://unix.stackexchange.com/questions/178638/eject-safely-remove-vs-umount
Some man pages for the the udisks command line tool: http://manpages.ubuntu.com/manpages/trusty/en/man1/udisks.1.html
http://linuxreviews.org/man/udisks/
https://udisks.freedesktop.org/docs/1.0.5/udisks.1.html
Some C code for something called udisks-eject. Is this somebody's wet dream or actually a standard feature? https://github.com/patrikf/udisks-eject/blob/master/udisks-eject
Friday, September 30, 2016
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
Monday, April 11, 2016
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
Tuesday, February 16, 2016
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.
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
Update Tkinter just because
start python, verify tkinter installed to make sure that the last installs worked.
get my kernel version:
attempt to get the source tree headers:
Try searching the cache for anything that might be what I'm looking for:
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:
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"
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:
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.
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.
Saturday, January 23, 2016
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:
Here are some links:
Results from doing a package search right on debian.org: https://packages.debian.org/search?keywords=matchbox-keyboard
Friday, January 22, 2016
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:
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.
.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:
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:
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:
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:
A pdf of the same tutorial is here:
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.
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:
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):
Interestingly, there seems to be a slightly different version (which still contains a line returning version 0.4.3). It can be found here:
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:
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:
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:
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.
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:
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:
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.
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 -CM= . 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
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/
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/
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:
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.
Step 3: Update apt-get, which synchronizes what packages my distro has and doesn't have and establishes locations to download from.
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.
Some related links:
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/
Friday, January 15, 2016
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.
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:
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.
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:
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:
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):
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:
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:
I think that my system is using systemd instead of init. Here is what looks like nice info on systemd:
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:
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:
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:
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.
Some links to stuff that I found which didn't directly help but I'm saving just in case:
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
Tuesday, January 12, 2016
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.
Reference link:
sudo date --set 1998-11-02
sudo date --set 21:08:00
Reference link:
https://wiki.debian.org/DateTime
Subscribe to:
Posts (Atom)