Adding Scaled values to the ADC driver within the IIO Subsystem

For the 3.8 tree for BBB, the bone-helper module tries to assist and provide voltage values scaled to 1.8V as limited by the AVDD in the BBB.

However, this is a clumsy hack.
I looked around IIO and other drivers and found that the subsystem supported scaled voltage values. The bone-helper was a workaround to fix the ADC drivers and get scaled values.

I used the IIO Simple driver document to trace and see how scaled values are implemented. And added the required code to the ADC driver.

Preliminary tests show that it runs correctly. :)

Previously there would only be /sys/bus/iio/device/iio:device0/in_voltageX_raw.
Now we see in_voltageX_scale as well :)

I still need to test /dev/iio soon. I haven't touched the adc driver from userspace c applications yet. hopefully they'll work as the sysfs interface works.

I have tried to test the touchscreen with evtest. However, I haven't actually set up the hardware required for it. Connecting ground did register triggers in evtest so I'm hoping it hasn't broken.

I'll look into seeing if I can keep bone-helper so that I don't disturb a bunch of people and capes by this update.
And /dev entries as well..


ZubairLK

p.s.

The patch looks like this.
The last one on
https://github.com/ZubairLK/kernel/tree/3.8-adc-fixes/patches/adc

From 26aa738a0394e39889b4515dde5e2baf99118141 Mon Sep 17 00:00:00 2001
From: ZubairLK <zubairlk@zubairlk-HP-G62-Notebook-PC.(none)>
Date: Sat, 29 Jun 2013 19:05:54 +0100
Subject: [PATCH] Added iio_voltageX_scale

The bone-helper driver tried to display the voltage in the range 1800mV
which represents the actual ADC range of the BBB. This feature is available
in the IIO system. in_voltageX_raw points to unscaled raw values
which give the output of the ADC register directly.

in_voltageX_scale is supposed to give scaled voltages. This was
missing in the TI driver and has been added.
---
 drivers/iio/adc/ti_am335x_adc.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index f78d2c1..c030078 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -26,6 +26,7 @@
 #include <linux/of_device.h>
 #include <linux/iio/machine.h>
 #include <linux/iio/driver.h>
+#include <linux/math64.h>

 #include <linux/mfd/ti_am335x_tscadc.h>
 #include <linux/platform_data/ti_am335x_adc.h>
@@ -119,7 +120,8 @@ static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
         chan->type = IIO_VOLTAGE;
         chan->indexed = 1;
         chan->channel = adc_dev->channel_line[i];
-        chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+        chan->info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT
+                                | IIO_CHAN_INFO_SCALE_SEPARATE_BIT;
         chan->datasheet_name = chan_name_ain[chan->channel];
         chan->scan_type.sign = 'u';
         chan->scan_type.realbits = 12;
@@ -189,7 +191,19 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
             *val = read;
         }
     }
-
+       
+        switch (mask){
+            case IIO_CHAN_INFO_RAW : /*Do nothing. Above code works fine.*/
+                   break;       
+            case IIO_CHAN_INFO_SCALE : {
+                    /*12 Bit adc. Scale value for 1800mV AVDD. Ideally
+                    AVDD should come from DT.*/
+                    *val = div_u64( (u64)(*val) * 1800 , 4096);
+                    break;
+            }               
+            default: break;
+        }  
+   
     if (found == false)
         return -EBUSY;
     return IIO_VAL_INT;
--
1.7.9.5

Working with arago patchset

This time I will try to document things properly as I go .

I'm going to forward port the improvements in the arago tree.


After going through all the commits I have to say. Thats a lot of work..

I could just ignore the mfd-next patch and take these changes for BBB 3.8 tree.

However that would defeat the purpose later on. Upstreaming patches and making our tree closer to the mainline. mfd-next is what will be the ADC driver later on. Because those patches have been upstreamed. Like it or not.

So I'll have to layer all these changes on top of that. And then upstream them hopefully..



http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=98260cf92c52e7e4eef3b64b7dcf43d3f14ea969
Registers children TSC and ADC only if available. This change is already incorporated.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2c67698139cceee19d2205ad34d11c74e758b307
AFE Pen Ctrl and TouchScreen transistors enabling is not

required when only ADC mode is being used, so check for availability of

TSC driver before accessing control register.

Update: Have applied this patch on my 3.8 tree.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2ce225a521671644ddc4d7b472fac139bb64f9c4
Tries to number channels from 1 instead of 0. Not a particularly useful change.
Also. Driver format has changed quite a bit compared to what I have..

Update: Ignored this one.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=663aa2e74f36a5a8000224b37a74c11ee729550d
Important Patch.
Message "Previously we tried to read data form ADC even before ADC sequencer finished sampling. This led to wrong samples.  We now wait on ADC status register idle bit to be set."

Update: have applied this patch to the 3.8 tree. Led to the correction of the first sample.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=09597d7a244a8e6f5ea79da3c5dced3a5ea620c4
Important. Sets the ground for interrupt handling on the TSC side.
At the moment IRQ is taken only by TSC. This starts changes to shared structure.

"Touchscreen and ADC share the same IRQ line from parent MFD core. Previously only Touchscreen was interrupt based. With continuous mode support added in ADC driver, now driver requires interrupt to process the ADC samples, so enable shared IRQ flag bit for touchscreen."

Update: Have applied this patch to the 3.8 tree.


Update: We(Me, Koen, Greg KH) decided to freeze development on the 3.8 tree and move to 3.11.

I have added another fix which removes the need for bone-helper. The 3.8 tree had the bone-helper driver to help with ADC detection and scale values to 1.8v.
There were bugs in the underlying driver as well which caused erroneous values and the need to sample twice.

The ADC driver for the 3.8 tree will hopefully be replaced by this new patchset I have soon. I am still testing and refining the patchset.
But I have successfully scaled the voltage values within the IIO subsystem model. And fixed the need for sampling twice. The tests I have run yet are simple connecting the adc to ground or 1.8v or 1.5v. And checking via sysfs.
The more thorough test for /dev/iio via a userspace application is needed.
And the interaction between the touchscreen and ADC drivers is to be tested and seen if it works.

The patches below and the ones above will be applied to the 3.11 tree after re-basing the ones from mfd-next by Sebastian as well.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b332370651a7d64d3c6ed8780d939fc18163e141
Most important patch I guess. Adds continuous mode and IRQ.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=478af139295b451c59eeba8f851654964321cbfe
Imp "ADC reports few wrong/erroneous data on read in continuous mode. Providing an appropriate delay so that ADC has sufficient time to sequence data present on the input channel. "

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=585b034972eb667cce3bf9f3bc5bb46f1f21bced
Imp. "The ADC driver did not check for FIFO1 underflow and overrun conditions. Add support to handle these conditions. TSC/ADC module does not recover from this state by itself, a module reset is required."

The driver has diverged a lot from what is in mfd-next. Poll handler. Irq. continuous mode.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b9a063a1654653348161de8d3d411d8ce2f56856
not implemented.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=adb9fa13a403f0f6f4e0d57a0bfcfd1a91e0edea
not implemented

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=1be244a840f9a162e3c832d7c1686100a6096a7c
not implemented

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=333f3460f855abd02c7e7eefcb692740ecd9c662
Simple one. Can be applied easily. Clock 3MHz check.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a62dbd7027667d99254f0f38f9364e4edcd56ddc
Seems similar to what is there. But error handling corrections.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=0f2a3e7288e91d42f9a527f193b1df61d5afff5c
FIFO 0 for tsc only. not implemented. quite different structure..

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2e8d35ab98789ee8b0d0d56c2a5d72940ffb2670
Not implemented. Quite different.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2ab9b41a1ac235c81f20bfebec69d4eb7021b275
Very different structure. Some TSC fifo issue.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=931e7f0032c5113f82f7b59b29406d2e9eab1c48
Step enable bits etc. Not implemented for continuous mode.

Russ dills bugfixes from now onwards. These are small bug fixes.
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7ce1a9f88aea036034e5e7dc65480694e7e0913d
IRQ stuff again.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=8607406b53cc6bd65cd48ed17d34ae2455271aa2
IRQ stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7fb9db4270711a434a8dd322ad1e3a6e7f798b91
IRQ stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=bd967ca8af48bd56076fad77ac77a010f3efd21c
IRQ Stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=da42b4c279d6241cab87bff5ea6d83c02651ef7e
IRQ Stuff

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=7295475758e73aa72a92cdc720186698cec8d033
FIFO clear on next work.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=de871da92081b17d6f286b5774ce24a938065f0b
Some error handling

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=2404a847db796cd17a9189d7ac2b73fe22446ebf
Some fifo check.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=337c3895437961b85bf507cfe2e2847a7851b4f2
tiny Fix


http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a819c4feafe9eac8d2e756954ab4e111c5b83732
Reverses a previous commit for delay that is not needed.

http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=18ce4a630452348b8308b922491130e8ce1e9134
Some power stuff. small.

Working with a patchset upstreamed via mfd-next

Ok. So I started from scratch on the ADC drivers.

My current aims are to start from 0 ADC patches in the 3.8 tree we have.

Then go up to the patches in mfd-next which incorporate a number of changes.
https://lkml.org/lkml/2013/6/12/371

But I couldn't just apply those patches directly could I. Tweaks and changes were needed.

List of changes.

Subject: [PATCH 05/21] input: ti_am33x_tsc: Add DT support
Guy missed out two steps to configure change to coordinate readout. But he removes the function later on so his tree doesn't break..
I wanted to keep that function later.

Did not apply number 6,8,11,14 which removes platfrom data support
Did not apply 15 and 16 which only renames DT bindings. But that would be unwise as it would mean changing DT patches.

Tweaked 9 as the patch changed the name to am3359 in places. Keeping it tsadc would be wise as that would keep DT unaffected.
Tweaked 20 a bit.

After a debugging session, I found out that IIO had improved from 3.8 to mfd-next. So those improvements had to be backported.
One was a bitmask. The other was interesting. While getting DT from childs a function would be called again in sub-functions. The data structure was tweaked to not require this. But I went back to calling the function twice instead.

IIO improvement backported. tscadc_dev->dev->of_node is being used in the 3.8 IIO. Not pdev->dev_of_node. which

Also. IIO was restructured a bit. A
node = of_get_child_by_name(pdev->dev.of_node, "adc"); was added in adc probe.

"EDIT. Dont make this mistake again. Be extra vigilant. Or you'll be debugging oops errors forever..

+        node = of_get_child_by_name(node, "adc");

And watch oops errors. They may have changed while you assume you are getting the same error.."

 Basically this function was called twice in 3.8. Till mfd-next (3.10 i think) the data structure had changed. Such that the nested call already had the ds and didn't need

12,17,18,19,20 caused hunk fix problems. git am wouldn't like them
So I used patch then diff to correct stuff.

Because of all my work in the ADC patches. There was one minor inconvenience in the other patches in the tree.
 the surrounding code had changed for a patch that was adding to the DT.
So I tweaked the DT stuff a bit as well.

patches/da8xx-fb/0022-ARM-dts-AM33XX-Add-am335x-evm-lcdc-panel-timings.patch:18:
was ti,adc-channels = <8>;
now
ti,adc-channels = <4 5 6 7>;

Channel access had changed. So I had to change DT stuff slightly to the above in our relevant BB patches too.


Now for debugging the ADC more and the arago improvements. which are much more in number! And much better for ADC!

But I guess if I layer patches on top of this I could easily re-base them for upstreaming. Yea :)

ZubairLK

Brick + Recovery + TFTP

Managed to brick my BBB within two days of receiving it.
Fix up the eMMC using http://www.crashcourse.ca/wiki/index.php/BBB_software_update_process.

The trickiest part was that I didn't realize that the script was working in the background and I just had to wait. I thought I'd see messages pop up on the serial console but nothing came up. And wasted a day thinking why isnt it working. vvu on #beagle-gsoc told me to simply wait. Lol.

A simple ps -a cleared the matter :) 

I wanted to set up uboot so that my uImage boots via tftp.

Lots of guides here and there. http://eewiki.net/display/linuxonarm/BeagleBone+Black and http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel

A bit scattered though. And 3.8 kernel changes quite a few things.

http://elinux.org/BeagleBone_and_the_3.8_Kernel is a comprehensive overview of changes.

Anyways. My uEnv if anyone interested.

"
optargs=quiet drm.debug=7

ipaddr=192.168.0.250
serverip=192.168.0.1
#run tftpboot 0x80200000 uImage
#uenvcmd=run loaduimage run loadfdt run mmcargs bootz 0x802800000 - 0x80F80000

bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait

uenvcmd=echo "Booting from Network";tftpboot 0x80200000 uImage; tftpboot 0x815f0000 dtb; bootm 0x80200000 - 0x815f0000
"


One thing to note that someone helped me out in IRC.
3.8 is a DT based kernel. So its not just the uImage file to load.

If you are loading just a uImage file. Then you have to load the uImage-dtb file which can be compiled. Which is basically the DT appended to the kernel.

Otherwise you can load two files. uImage + DT. The DT file is the device tree that replaced the old board file system. It took a while to digest things.

https://www.youtube.com/watch?v=MOhVdknBOkw Links to a presentation by Koen on it as well.

ZubairLK

Beaglebone first steps

The beaglebone black is here. Its much easier to get up and running than the XM.

Just connect the usb cable. More info here
http://beagleboard.org/Getting%20Started

I wanted to access internet on it. This can be done via the usb cable itself. No need to connect ethernet even! Magic :)

http://travis-lab.blogspot.co.uk/2012/02/getting-on-beaglebone-on-internet-using.html

Add a sudo for ubuntu. And check the comments for an additional step for ubuntu as well.

Then I like some vnc every once in a while. So follow
http://digitaldiner.blogspot.co.uk/2013/05/quick-hint-for-beaglebone-black-user.html

Voila!

Now for some kernel hacking magic!

I've noticed some stuff. The helper script is the way to access the ADC.

http://hipstercircuits.com/reading-analog-adc-values-on-beaglebone-black/

That isn't cool and has to be patched immediately! I'm looking into it.

Zubair

Thoughts on ADC patches floating around the globe

I'll hopefully get my hands on the beagle tomorrow. Until then, I'm pondering and over thinking about the ADC drivers, kernel trees and patches.

In retrospect, I think it actually helped that I'm mulling over the kernel etc for such a long duration. I have learned a lot and read around alot instead of playing with the beagle!

The GSoC application proposal i submitted gave me the first three weeks to set up a dev host (done), recreate the problem with adc drivers, patch the adc drivers.
An additional goal later on was to forward port driver improvements from the TI Arago tree which is based on 3.2 http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary.

Instead of finding problems and fixing them, I am thinking I should directly jump ahead and forward port all improvements of the 3.2 tree.

I could write code myself. But I think that'll take a significantly larger amount of time. The work is done and out there in patches here and there. Its just scattered.

I have browsed around a lot and found three places where useful patches exist.

1. One kernel/3.8 branch koen is maintaining. https://github.com/beagleboard/kernel/tree/3.8

2. Linux next just received a patchset https://lkml.org/lkml/2013/6/12/361

3. Arago tree. (link earlier above)

The lkml work is recent and is a mixture of various previous patches from the arago tree and some of the authors own work.

But to be honest, I'm inclined towards the Arago tree for completely stable work. At the moment, I intend to take the 3.8 tree by Koen. Remove the ADC patchset existing at the moment. Which will bring the ADC files to a blank point where the 3.8.13 stable kernel is. I traced the same point in the 3.2 Arago tree. Which is pretty far behind. Then go through all the changes one by one. Generating a patchset.
Then I'll go over Koen's existing patchset. And see if there is any improvement in that which can be added as well. Then go over the recent lkml list patchset and see if there is an improvement there.

Edit: This is called rebasing! Just occurred to me from a comment by Patil Rachna on a patchset and Googled around to confirm. I guess Greg could work up some git magic to do all this :). But where would my GSoC work come :P

Edit again. It isn't exactly rebasing. The gap between the kernels is huge.

I don't know how big a task this is. I'll get started this weekend.
I'll know how big a task this is by actually starting and doing it.

Cheers
Zubair

Update. ADC + Touchscreen interaction

Hi,

IRC meeting on #beagle-gsoc went well. Just some introductions. And I asked a question to which I should've known the answer.

Anyways. I was confused about the interaction of the drivers of the 8-channel ADC and the touchscreen input driver. I had missed a file which was the actual ADC driver. I was only looking at the ADC IIO file and the touchscreen input driver files. Both the ADC IIO and the touchscreen use the same ADC source file which is found in a different folder. I missed that and [Russ] pointed it out to me I think.

I should have noticed the common header..

Links below are for the mainline kernel..

For the IIO driver, you find it in drivers/iio/adc/ti_am335x_adc.c
For the touchscreen driver you find it in drivers/input/touchscreen/ti_am335x_tsc.c
For the base file both use, I found it in drivers/mfd/ti_am335x_tscadc.c

Depending on the kernel tree you browse. You might find some of these files in the staging folder. (staging folder is the place where linux kernel developers put drivers and stuff that isn't fully refined enough to be incorporated in the main master branch)

At the moment I am going through stuff in the Useful links post.
I'm playing around git. Its a really powerful tool with an equally steep learning curve.

My beaglebone black should be on its way.

http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide has a really great overview of the ADC and touchscreen driver and how to get them to work.

Greg KH (my mentor for the project and a great guy) has a repository with some great tutorials https://github.com/gregkh on kernel development.


I have gone through the tutorial. Now, I will play around and get my head ok with the beagleboard kernel patches repository https://github.com/beagleboard/kernel maintained by Koen (co-mentor for the project and another great guy).

I have a feeling that a significant part of my work will be forward porting the developments of the ADC driver in the 3.2 kernel tree by TI to the 3.8 kernel tree for the beaglebone. This done correctly should cover quite a few mile-stones of the GSoC project I proposed.

I will have a 3.8 mainline kernel tree patched using the beagleboard repository.
And I will have a clone of the kernel tree maintained by TI.

Maneuvering through the repositories using git is going to have a steep learning curve. But I'm starting to get a handle on things.

GSoC 2013 officially starts on MONDAY!

Cheers
Zubair

Uselful links

I'm loosing track of good links. So I'll keep updating this post with the ones I find along with comments.

One important thing I have realized: This isn't a project where I google around, find a blogpost. And implement all the steps in it :)

The documentation is to be found in LDD3, stack overflow questions, mailing lists and, most importantly, the kernel tree itself.




Repository of patches applied to mainline kernel to make it function on the beaglebone. My work will sum up a few patches to be added to this.
https://github.com/beagleboard/kernel/tree/3.8

Set of tutorials on linux device driver development.
http://oldpapyrus.wordpress.com/tag/write-linux-device-drivers-kernel-3-0-2-6/

IIO Subsystem documentation
http://www.ohwr.org/projects/zio/wiki/Iio Interesting wiki page giving overview.

Kernel tree maintained by TI for the AM335x processors
http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary

Some drivers. (Note not the main branch..)

Touchscreen driver
http://arago-project.org/git/projects/?p=linux-am33x.git;a=history;f=drivers/input/touchscreen/ti_tsc.c;h=8b3459812fef27c3f1a7801b9bf9b3bf195e34c8;hb=v3.2-staging

ADC driver
http://arago-project.org/git/projects/?p=linux-am33x.git;a=tree;f=drivers/staging;h=7c862de9e9b05ac4577665a4ed5a554d88f27acd;hb=v3.2-staging

Touchscreen/ADC driver clash patch. Part of the project is investigating the clash between touchscreen drivers and ADC drivers. The following link is a discussion on a patch solving a similar issue for another ADC.
https://patchwork.kernel.org/patch/1851101/

I skimmed the tech ref manual of the processor. The touch screen controller is a mode of the 8 channel ADC itself. As I looked at the driver sources, I found that the touchscreen driver doesn't look like its based on the IIO subsystem. The ADC driver is. The discussion in thehttp://ez.analog.com/community/search.jspa?peopleEnabled=true&userID=&containerType=&container=&q=sysfs+iio link above indicates that this is an issue in the design of the subsystem itself. It hasn't yet been designed to acknowledge that part of the ADC channels can be under use by a touch screen controller.
I will look into it as time goes on.

Analog devices wiki page on IIO
http://wiki.analog.com/software/linux/docs/iio/iio
Their ADC drivers can be a good source of example. Although, the SPI/I2C interface creates a bother. I should look at processor ADC drivers to see if I find a great one. The TI mainline one is more refined as well..

Analog community forums are slightly hidden but a good source on IIO recent questions..
http://ez.analog.com/community/search.jspa?peopleEnabled=true&userID=&containerType=&container=&q=sysfs+iio

ADC heaven for the beaglebone! Gives a great overview of the driver..
http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide

This guy is great with the beaglebone :)
http://hipstercircuits.com/
http://hipstercircuits.com/reading-analog-adc-values-on-beaglebone-black/ 

Temp sensor using ADC on beaglebone
http://bwgz57.wordpress.com/2012/04/01/beaglebone-how-hot-is-it/

Interesting driver guide
http://www.cedt.iisc.ernet.in/people/haresh/emsys/device_driver_brief_tutorial.pdf
 

I'll update this list as time goes on. Pretty sure I missed out on a few links already.. But I need to focus more on the content in the links itself rather than documenting the links.. :)

Getting to the latest kernel tree of the beagleboard

This is a tricky one.

"The BeagleBone currently relies on a number of out-of-tree kernel patches in order to boot. These patches are maintained by Koen Kooi (CircuitCo) and come from many sources, including TI employees and various mailing lists." from the Beagleboard GSoC ideas page.

A cursory look at https://github.com/beagleboard/kernel will show you a patch script file you need to run. A closer look inside it shows that it builds the 3.2 kernel version. I knew that the current version under development was 3.8 so I figured out that something is fishy.



Turns out the 3.8 tree is being developed in a branch (i think. still not comfortable with git). Selecting the 3.8 branch from the branches will show the current kernel being maintained by Koen.

Edit: Epiphany. I'm guessing the 3.2 branch is stable with respect to various drivers! That is why the master points to the 3.2 kernel tree.

For the 3.8 tree, using git clone on the main link

git clone https://github.com/beagleboard/kernel

will give you the current head which points to 3.2 version. Then you have to

git checkout origin/3.8 -b 3.8

in the same folder. This will change the head to point it to the 3.8 branch.

Then you will need to run ./patch.sh which will generate a working kernel tree for you.

I'm updating the log as I go. I'm pretty certain git will work its magic and I'm about to see a functioning kernel tree in my directory.

All this should be basic stuff for gurus and developers comfortable with git.
I'm writing from a novice perspective..


Cheers
Zubair

p.s. One thing I have realized is that date stamps are very important. Old blog posts can only be treated as reference material. The open source community has a fast pace.

Workstation setup

I have set up a clean install of Ubuntu 12.04 LTS with 150gb in the home directory and 50gb for /

I was thinking I might need a better setup to browse the kernel sources.

Tried to set up the latest LXR (linux cross reference) but got stuck in weird scripts and bugs.

Set up the old version using http://thangamaniarun.wordpress.com/2010/07/09/howto-setup-lxr-on-linux-ubuntu-10-04/

Realized LXR can't be the main tool. Just sometimes to browse the original kernel tree and trace data structures and functions.

Trying to work using LXR for anything else would get messy. LXR is a great tool. But my current work is focused on the ADC drivers. I don't need to browse everything all the time. And the online lxr is pretty great as well.. http://lxr.free-electrons.com/

Set up open embedded using http://www.angstrom-distribution.org/building-angstrom. I should really ask koen to write a line there to install a dozen relevant packages (required for bitbake) before those instructions can be followed.

I think this covers it all but I'm not sure. Taken from https://pixhawk.ethz.ch/tutorials/omap/openembedded_bitbake_installation

sudo apt-get install subversion cvs git-core \
build-essential help2man diffstat texi2html texinfo \
libncurses5-dev gawk python-dev python-psyco python-pysqlite2 \
 gnome-doc-utils gettext automake flex bitbake

Realized working on the kernel under OE will be a significant pain. Googled around. Found these

http://www.linuxtogo.org/gowiki/CompilingYourOwnCode

http://ao2.it/en/blog/2010/05/27/neat-compilerun-cycle-git-and-openembedded

http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded

I'll use the toolchain from OE. And set up a separate kernel tree to work with. 

To my current knowledge, work in the OE tree would be adding a line or two for a few additional patches later on. But right now. I have no use of OE. I need a base stable kernel tree with the patches for the beagleboard kernel that I can branch of using git and work on the ADC driver..

"Edit update: Found http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/

Which illustrates a very useful work-flow.. I'll look into it."

What next?

Learn git. The more time I spend on git now, the better I'll be able to work later on..

I'll be following tutorials online like https://github.com/gregkh/kernel-tutorial . And setting up a kernel tree now.

Cheers

Zubair

Hello World

Hi,

My name is Zubair Lutfullah Kakakhel and I will be working on the Beaglebone black for the Google Summer of Code 2013 project. (GSoC website link).

This blog will act as a log/journal as I work on the project.

Project overview

The IIO ADC driver for the Beaglebone does not add /sysfs entries and the /dev/iio:deviceX entries are slightly broken.

This project will involve patchwork for the ADC drivers.

An hwmon driver will be developed for power measurement using the 7th ADC channel connected to the shunt register.

Community members report touch screen drivers clashing with the free ADC channels. This will be investigated and patched.

The kernel tree maintained by TI for the AM335x has quite a few updates to the ADC driver which haven't been merged into the main kernel tree.
These updates will be forward ported to the tree used by the beaglebone black.

PWM driver has a hack for adding sysfs entries. Clean sysfs support for the PWM driver api will be written.

These drivers,fixes and associated test applications will greatly help new comers and userspace application programmers to easily access the ADC on the beaglebone.

My background

I am currently doing an MSc. in Embedded Systems at the University of Leeds, UK.

I have worked on the Beagleboard-XM for around two years during my undergraduate and afterwards during my job.

I have completed a Bachelors in Electrical Engineering from National University of Sciences and Technology, Pakistan.



On the personal side, I'm a geek and I know it. :)
I like traveling and photography these days.


Cheers,
Zubair