Linux device drivers for Rapberry Pi on-board I/O

I posted a couple times in the other I2C thread as well. I'm really interested in I2C for a work project. I just finished university (computer science). I've got little to no experience with developing drivers - the closest would be my work with HC11 (in C & assembly).

Anyway, now that I've introduced myself. When my Pi arrives, I'd be more than willing to help test/debug drivers (I'm not sure how much help I'll be in the core development). Also, I might take a stab at writing a Java JNI wrapper around the C driver so I can use I2C within an existing project.

I'll follow this thread and depending when I get my Pi and the progress made on the driver I'll let you know and hopefully lend a hand in someway.

Simon

RAThomas said:

selsinork, do you have some I2C device to test talking with the Pi?  I'm thinking either a really simple device where it's own data "protocol" won't obscure the driver's behavior or one with existing higher level support would be best.  Even without a test device, one might still be able to test that the BSC master can talk using an o-scope.

Yes I do..  I have some temperature sensors, fan controllers, gpio expanders. Most of which appear to have existing linux drivers. So I'm hoping most of them can work without much else being done apart from the i2c driver itself.

I've been rebuilding the kernel with all of the I2C & SPI bits enabled and with their debugging options turned on over the last day or so, checking that I can boot my new kernel etc. So I'm mostly at the point where I can test stuff if you've got anything ready.

Is the I2C bus already pulled up on the Pi or does one need to terminate it to do testing?

Yes, there's onboard 1k8 pullups on the schematic

Other trivia:  The 2835 has 3 BSCs (0-2) where BSC2 is dedicated to the HDMI port and out of our hands.  I'm focused on making BSC0 work, but since they appear to be identical but for the register mapping, it should work for BSC1 too (assuming it works at all!).

I read somewhere in the datasheet that we're not allowed to touch the one dedicated to the hdmi. I assume that's claimed by the GPU somehow.

@selsinork

There are some bugs in the kernel at the moment, one in particular is very annoying. It looks like a buffer overrun: https://github.com/raspberrypi/firmware/issues/9

Question is whether or not we need to have those kernel bugs ironed out before we can begin development with the Pi.

texy said:

Am I missing something, or do they want to charge 24 Euro's to shipo it to the UK?

That's some "default" setting for the shop software (oscommerce). We thought it was making this mistake for just a few countries where nobody lives. That was a mistake. If anybody else gets such a weird shipping quote, please contact us, we'll have it fixed.

Lars T. Hansen said:

@selsinork

There are some bugs in the kernel at the moment, one in particular is very annoying. It looks like a buffer overrun: https://github.com/raspberrypi/firmware/issues/9

I've seen something like that at least once, while pulling a file from a webserver onto a USB key, but I can't duplicate it right now. I was reading that issue last night and wondering about the power supply stuff in the comments. It's possible it's relevant as I've given up on the usb phone charger idea for now and I'm currently using a proper lab power supply that can supply 100W over some rather thicker cable directly to the gpio header. Basically giving me 0.01v drop across the cable instead of 0.5v with the crappy micro usb cable I was using

I'll go retry loading things up with lots of network and usb drive traffic to see if I can trigger it again.

Question is whether or not we need to have those kernel bugs ironed out before we can begin development with the Pi.

I'm not sure it's absolutely necessary, I've managed a good few kernel builds on mine yesterday with the kernel source tree on an nfs share without issue. Obviously this is more cpu bound than thrashing the usb, but I've always found kernel builds good at catching dodgy hardware in the past.
It'd obviously be good to get to the bottom of that bug though as keeping large source trees on a fast nfs server helps quite a lot and having to restart a long build after it dies at 95% would get a bit annoying.

Any news on the I2C driver? I have a Raspberry Pi and I have I2C slave devices for testing. I could even write the driver by myself, because I did some commercial driver development for another embedded Linux system, but I would like to avoid duplicate work But if you have something for testing, I can debug it.

Frank Buss said:

Any news on the I2C driver? I have a Raspberry Pi and I have I2C slave devices for testing. I could even write the driver by myself, because I did some commercial driver development for another embedded Linux system, but I would like to avoid duplicate work But if you have something for testing, I can debug it.

selsinork has a Pi, and i has not a Pi. The idea was that he is doing development on a I²C host adapter driver, and i will do peer-review of the source code, because i does not has a Pi, yet. When i get my Pi i will begin to do full-time development of the driver (from 21. may 2012), before that only part time.

So Frank Buss you will need to get an answer from selsinork. Speaking for myself: I will happily let you do the driver development, because i also has an I²C hardware project.

unfortunately I've been sidetracked onto non R-Pi related stuff this last week or so.

I've not really progressed much further than getting an initial github repo created, and doing some really trivial stuff like editing the Makefile and Kconfig.

So Frank, feel free to help. My only request would be that you put your work in a regularly updated public git repo, even if incomplete or not functional. That way others can help out with peer review, suggestions, code or testing.

selsinork said:

unfortunately I've been sidetracked onto non R-Pi related stuff this last week or so.

I've not really progressed much further than getting an initial github repo created, and doing some really trivial stuff like editing the Makefile and Kconfig.

So Frank, feel free to help. My only request would be that you put your work in a regularly updated public git repo, even if incomplete or not functional. That way others can help out with peer review, suggestions, code or testing.

+1selsinork

Frank Buss so you will do the development of the I²C host adapter driver now?

I saw that coming Ok, I'll try it. I'll have some time for it on Monday. A public github repository sounds good.

The first version will use the Linux bitbanging interface, which should be fairly easy. There is already an I2C driver which does this for the BCM5365. Should be sufficient for many applications.

Maybe next weekend I'll have some more time for writing a driver for the Broadcom I2C hardware module, for less CPU usage.

Frank Buss said:

I saw that coming Ok, I'll try it. I'll have some time for it on Monday. A public github repository sounds good.

The first version will use the Linux bitbanging interface, which should be fairly easy. There is already an I2C driver which does this for the BCM5365. Should be sufficient for many applications.

Maybe next weekend I'll have some more time for writing a driver for the Broadcom I2C hardware module, for less CPU usage.

In my opinion you should not dublicate work.

Your first version already exists in the kernel tree! : Line 2 of i2c-gpio.c has this text "Bitbanging I2C bus driver using the GPIO API", and it is here: http://lxr.linux.no/#linux+v3......2c/busses/

Also you has some of the code done for you already in: i2c-core.c and i2c-core.h, which you can find here: http://lxr.linux.no/#linux+v3......rivers/i2c

Lars T. Hansen said:

In my opinion you should not dublicate work.
Your first version already exists in the kernel tree! : Line 2 of i2c-gpio.c has this text "Bitbanging I2C bus driver using the GPIO API", and it is here: http://lxr.linux.no/#linux+v3......2c/busses/

Also you has some of the code done for you already in: i2c-core.c and i2c-core.h, which you can find here: http://lxr.linux.no/#linux+v3......rivers/i2c

Right, I don't want to write my own I2C bit banging interface, but I want to use the kernel functions. Still some work to configure it in the platform definition files and to connect it to the GPIO functions of the RPi.

I've enabled the I2C GPIO support for both I2C interfaces, at the pin header and at the camera connector. I don't know if the third I2C interface at the HDMI connector is already handled by the GPU, so I didn't enabled this. This is the configuration (have to check the differences which resulted in changing some settings with "make menuconfig", and then I'll change arch/arm/configs/bcmrpi_cutdown_defconfig )

http://pastebin.com/RnZWuCg5

It compiles and the kernel doesn't crash, but it fails at the gpio_request call in drivers/i2c/busses/i2c-gpio.c with this error:

i2c-gpio: probe of i2c-gpio.0 failed with error -22
i2c-gpio: probe of i2c-gpio.1 failed with error -22

I'll take a look at it this evening, but maybe someone has an idea? The forked repository:

https://github.com/FrankBuss/linux

I am a novice at Linux device stuff, but in case it helps, on a different system:

"error -22" means that you tried to add a GPIO that either doesn't exist or can't be made a GPIO. Change the GPIO pin definition.

according to http://wiki.openwrt.org/toh/d-.....nk/dir-600

Also there is a thread here where a relative Linux novice gets help developing a Linux I2C driver, which I can't follow myself, but it may provide some insights:

http://www.linkedin.com/groups.....S.61984097

By the way, I'm not sure if I'm looking in the right place to see your github patch, is the file you're working on called "bcm2708.c" ? For the R-Pi it should be BCM2835, I think? Are you doing a bit-banged GPIO type I2C, or using the SoC's internal I2C modules and talking through the "Broadcom Serial Controller" registers described p.28 of http://www.raspberrypi.org/wp-.....herals.pdf ?

jbeale said:

By the way, I'm not sure if I'm looking in the right place to see your github patch, is the file you're working on called "bcm2708.c" ? For the R-Pi it should be BCM2835, I think? Are you doing a bit-banged GPIO type I2C, or using the SoC's internal I2C modules and talking through the "Broadcom Serial Controller" registers described p.28 of http://www.raspberrypi.org/wp-.....herals.pdf ?

AFAIK, When you are compiling a kernel for Pi you compile for bcm2708, because bcm2708 has a subset of the peripherals of the bcm2835.

@Frank Buss

You had not said yes to some I2C stuff:

That is, you have.

1. 
   
   # CONFIG_I2C_CHARDEV is not set
   
   


2. 
   
   # CONFIG_I2C_MUX is not set
   
   


3. # CONFIG_I2C_DEBUG_ALGO is not set


4. # CONFIG_I2C_DEBUG_BUS is not set


5. I2C_DEBUG_CHIP does not seems to exist

Have a look at :

http://how-to.wikia.com/wiki/H.....rivers/i2c

@other newbie kernel hackers

Enable kernel debugging to get more useful information

http://www.linuxtopia.org/onli.....09s07.html

The driver is working now! The problem was the initialization order: The I2C-GPIO driver was initialized before the Broadcom GPIO driver. I"ve changed the GPIO driver initialization order to arch_initcall, which should be the right moment, because the GPIO pins should be available before any other drivers are initialized. jbeale: currently I"m using the Linux bitbanging driver, I plan to implement a driver for the hardware module on the microcontroller on weekend.

The new .config file: http://pastebin.com/cHDdMjXv

Thanks Lars, CONFIG_I2C_CHARDEV results in the two devices /dev/i2c-0 and /dev/i2c-1 for the I2C on the GPIO pin headers and on the camera port, automaticly generated by udev. I don"t know what CONFIG_I2C_MUX does, so I did not enable it, and usually you don"t need the debug settings. Tested with my IO-Expander and the linux-i2c-test.c on the page, works great:



Next step will be to integrate the changes of .config in bcmrpi_cutdown_defconfig. A simple diff doesn"t work, because looks like the "menuconfig" changed the file a lot, any ideas? I"m not sure when I just set the new defines to Y, if all dependencies are followed.

Another problem is the reservation of the GPIO pins. Of course, on http://elinux.org/RPi_Low-leve.....eripherals the pins are labeled as SDA0 and SCL0, but you could use it as general purpose IO pins (GPIO0 and GPIO1 for the GPIO driver). But when the I2C driver allocates the pins, you can"t use it anymore with the GPIO driver. Three ideas:

1. users who needs it as GPIO pins have to compile the kernel without the settings

2. compiled as a module, so it can be removed and added on runtime

3. not enabled in the kernel per default and users who needs I2C have to compile a new kernel with the settings

I would prefer 1, because it is the easiest way for most users, and you have enough other GPIOs. Powerusers who needs more pins could use a different kernel configuration.

This is great work! I think many people have been waiting for this development- it opens up a wide array of possible devices for interfacing. I'm looking forward to the hardware I2C driver as well.  I think the great majority of users (if they do any GPIO at all) will want I2C capability, instead of the maximum number of I/O pins, so built-into the kernel sounds good to me. Besides, if you do need lots of I/O, you might as well use an I2C expander chip as in your demo.

Controlling clocks.

Some of you have already noticed that the Gertboard software accesses locations which are NOT in the BCM2835 manual which I wrote. If you look at code it controls the clocks for the SPI and the PWM (and GPIO drive strength).

In fact there are a few hundred registers dealing with clocks, reset and power. Most of those register should never be touched directly. Instead there are routines in the GPU which take care of writing them with just the right patterns in just the right order.

Do it wrong and your chip can blow up. The probability is low but it is definitely possible!

So those registers where all omitted from the data sheet. Unfortunately we omitted too many registers. So clock-control registers which are required for some peripherals are also missing. I have had no time to work trough the hundreds of registers and select the 'safe' ones. Besides that I have to talk to somebody higher up what and how much information I can release. (I already took the liberty to release the GPIO drive strength without consultation). On top of that I am working hard on the latest release of my Gertboard.

So please bear with me and I will see what i can be do in the next two weeks.

Gert,

what clock are you talking about?

In my experiments, the I2C and SPI modules run off the "core clock" at 250MHz as documented.

If you want 10MHz SPI, divide by 25 and you're in business. If your device can handle up to 20MHz, you divide by 13 or 14 and get 19.2 or 17.8Mhz. When would that hurt?

Frank Buss said:

The driver is working now! The problem was the initialization order: The I2C-GPIO driver was initialized before the Broadcom GPIO driver. I"ve changed the GPIO driver initialization order to arch_initcall, which should be the right moment, because the GPIO pins should be available before any other drivers are initialized. jbeale: currently I"m using the Linux bitbanging driver, I plan to implement a driver for the hardware module on the microcontroller on weekend.

The new .config file: http://pastebin.com/cHDdMjXv

Next step will be to integrate the changes of .config in bcmrpi_cutdown_defconfig. A simple diff doesn"t work, because looks like the "menuconfig" changed the file a lot, any ideas? I"m not sure when I just set the new defines to Y, if all dependencies are followed.

Another problem is the reservation of the GPIO pins. Of course, on http://elinux.org/RPi_Low-leve.....eripherals the pins are labeled as SDA0 and SCL0, but you could use it as general purpose IO pins (GPIO0 and GPIO1 for the GPIO driver). But when the I2C driver allocates the pins, you can"t use it anymore with the GPIO driver. Three ideas:

1. users who needs it as GPIO pins have to compile the kernel without the settings

2. compiled as a module, so it can be removed and added on runtime

3. not enabled in the kernel per default and users who needs I2C have to compile a new kernel with the settings

I would prefer 1, because it is the easiest way for most users, and you have enough other GPIOs. Powerusers who needs more pins could use a different kernel configuration.

Great to hear progress on I2C. I've asked a similar question about pin allocation for the SPI driver. http://www.raspberrypi.org/for.....-3/#p73509

I suggested passing in config arguments at boot time which enable which drivers/pin configs are used. I think this is what beagleboards do -- in fact I think they probe the I2C bus at boot to decide.

I also started discussing pinctrl/pinmux from the kernel which deals with this sort of thing, and can be exposed to userspace through appropriate /sys/.... or somewhere in device tree.

Thoughts?

Just changing the clock to a peripheral will not hurt. So those registers I can specify and everybody can use them. There are a few more bits then just the divide-the-core-clock in there, but none which are fatal. Just make sure you do not accidentally use the wrong offset and write to a different register!

Don't forget that the core clock is not always the same frequency as the GPU can change the clock speed (down) to save power.

Frank Buss said:

The driver is working now! The problem was the initialization order: The I2C-GPIO driver was initialized before the Broadcom GPIO driver. I"ve

Frank, great to see a working driver!  I hope you'll stay involved and help with getting one using the BSC running too.

I just can't quite forgive you for the blue leds in the clip though

Thanks for your efforts, I shall test it just as soon as my kernel compile finishes !

Frank, great work.

No luck for me here with the .config file

Pi boots, but no sign of /dev/i2c entries.

Frank,  driver is working nicely with a simple lm75 clone.  Thanks!