I'm working with a Beaglebone A3 running the Arago distro of Linux loading via TFTP & NFS-mounted root FS on my Ubuntu 11.10 machine. Blake Carpenter posted info on the "internal" e2e although from the outside I cannot access it. For those that can, I think this is the link:
https://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/int_sitara_am335x/f/425/p/172327/629962.aspx#629962
My original request to Blake was as follows:
I'm looking for info on how to access/configure A/D inputs from Linux...So far, I haven't been able to find anything on how to access the A/Ds from within Arago. Although searching the Internet, I did find this:
http://www.gigamegablog.com/2012/01/22/beaglebone-coding-101-using-the-serial-and-analog-pins/
This is a guy showing how to wire up a Beaglebone for A/D access. And in this link, he shows that to access the A/Ds, there should be a folder named as follows:
/sys/devices/platform/tsc/ain2826
However looking in the file system of my Arago installation, I don't have a /tsc folder. And I haven't been able to find an /ain2826 folder in what I do have. Assuming the link I found is accurate, it appears accessing the A/Ds isn't terribly difficult as long as the drivers are in place to do it. But they don't appear to be...
Here's the response he sent me back:
I believe your issue is that you are looking at documentation based on the Angstrom distribution for beaglebone rather than the Arago distribution. The Angstrom distribution is a community based distribution and there are some patches they apply on top of the TI kernel. In particular the following patches likely have something to do with the ADC:
0006-beaglebone-disable-tsadc.patch
0007-tscadc-Add-general-purpose-mode-untested-with-touchs.patch
0008-tscadc-Add-board-file-mfd-support-fix-warning.patch
0009-AM335X-init-tsc-bone-style-for-new-boards.patch
0010-tscadc-make-stepconfig-channel-configurable.patch
0011-tscadc-Trigger-through-sysfs.patch
0013-tscadc-switch-to-polling-instead-of-interrupts.patch
0014-beaglebone-fix-ADC-init.patch
These patches were pulled from the list of patches applied on top of the TI kernel in the recipe at http://arago-project.org/git/?p=meta-ti.git;a=blob;f=recipes-kernel/linux/linux-ti33x-psp_3.2.bb;h=79a315a1a18db23ece195d5827b64c39f35331cb;hb=0d0e2c1e274e1885d8b5cb07421449e9d0016c2c
You can find these patches online at:
The /sys directory is not a "real" directory in the file system. It is generated by the kernel and kernel drivers. As you said, once the drivers are in place the directory should be created in /sys
Chase
This morning, I tried to get these patches installed into the Linux source and then rebuild a new kernel with these patches. And I'm not getting much success. Here's how far I got:
1. Downloaded the patches indicated below into the following directory:
~/ti-sdk-am335x-evm-05.03.00.00/board-support/linux-3.0+3.1-rc8-psp04.06.00.02.sdk-psp04.06.00.02.sdk/patches
2. Ran the ~/ti-sdk-am335x-evm-05.03.00.00/linux-devkit/environment-setup script as sourced to configure my shell for cross-compiling ARM code, not native x86 code.
3. I navigated the shell to the Linux source code directory ~/ti-sdk-am335x-evm-05.03.00.00/board-support/linux-3.0+3.1-rc8-psp04.06.00.02.sdk-psp04.06.00.02.sdk and ran the patch command as follows:
$ patch -i patches/recipes-kernel_linux_linux-ti33x-psp-3.2_0006-beaglebone-disable-tsadc.patch --dry-run -p1
I wanted to do a dry run and not actually commit anything in case there were problems. Had everything gone fine in the dry run, I would simply rerun the patch command without the --dry-run argument. But instead of a successful patch dry run, I got this:
patching file arch/arm/mach-omap2/board-am335xevm.c
Hunk #1 FAILED at 248.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/mach-omap2/board-am335xevm.c.rej
So is this an indication that this patch won't work on my Arago disto or do I need to apply earlier patches listed on the website supplied by Chase?
Note, I am relatively new to Linux, so speak to me like a novice not like an expert Linux guru so don't assume a lot of existing knowledge about Linux. I'm an RTOS firmware developer doing investigation into moving my company's next generation of hardware over to a Linux architecture and the more I learn about Linux, the more I realize how much I don't know.
While being dead in the water on this issue, I decided I would at least try to build the kernel with the source code as it was installed on my machine by the setup scripts. And I had trouble with that. Although that can probably be tracked as a separate thread since I highly suspect this is a newbie problem.