activate spi drivers for cfa-10036/cfa-1037

sanandak

New member
Hi - I bought a cfa-10036/37 board and carrier board combo - impressive boards, by the way!

I have been able to compile new linux images and boot them from SD card, etc.

I wanted to use the spi drivers in the API library, but the device needed
/dev/spidev32766.nnnn

is not available.

How do I activate that device? (I did activate them in the linux-menuconfig step, but no luck)

Thanks!
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Support

Administrator
Hi - I bought a cfa-10036/37 board and carrier board combo - impressive boards, by the way!

I have been able to compile new linux images and boot them from SD card, etc.

I wanted to use the spi drivers in the API library, but the device needed
/dev/spidev32766.nnnn

is not available.

How do I activate that device? (I did activate them in the linux-menuconfig step, but no luck)

Thanks!
Thanks for the compliment on the boards. :) If you overwrite (from your buildroot folder) output/build/linux-?/arch/arm/boot/dts/imx28-cfa10037.dts with the one linked below, and delete the .stamp_target_installed .stamp_built and .stamp_images_installed and then do "make linux" you should be set and ready to go:

https://raw.github.com/crystalfontz...913fd618/arch/arm/boot/dts/imx28-cfa10037.dts
 

sanandak

New member
Thanks for the compliment on the boards. :) If you overwrite (from your buildroot folder) output/build/linux-?/arch/arm/boot/dts/imx28-cfa10037.dts with the one linked below, and delete the .stamp_target_installed .stamp_built and .stamp_images_installed and then do "make linux" you should be set and ready to go:

https://raw.github.com/crystalfontz...913fd618/arch/arm/boot/dts/imx28-cfa10037.dts
Thanks for the dts file. I copied it and remake linux as you suggest, but still don't see /dev/spi*

Here is what I *do* get: (sysfs). I have attached my linux .config files (output/build/linux-xx/.config)

Thanks for your help!
S

# find / -name "spi*"
/sys/bus/spi
/sys/bus/spi/drivers/spidev
/sys/bus/platform/devices/spi2.6
/sys/bus/platform/devices/spi3.7
/sys/bus/platform/drivers/spi_gpio
/sys/bus/platform/drivers/spi_gpio/spi2.6
/sys/bus/platform/drivers/spi_gpio/spi3.7
/sys/devices/spi2.6
/sys/devices/spi2.6/spi_master
/sys/devices/spi2.6/spi_master/spi32766
/sys/devices/spi3.7
/sys/devices/spi3.7/spi_master
/sys/devices/spi3.7/spi_master/spi32765
/sys/class/spi_master
/sys/class/spi_master/spi32765
/sys/class/spi_master/spi32766
/sys/class/spidev
/sys/module/spidev
# uname -a
Linux crystalfontz 3.9.0-rc1 #1 Wed Feb 26 22:18:07 EST 2014 armv5tejl GNU/Linux
#
 

Attachments

CF Support

Administrator
After some struggling (my development machine is getting persnickety today) I committed what I believe to be the kernel branch that was used for these demonstrations.

If you change the kernel git version to 03f8247fb and remove from the build cfa-10055, it should go well, and build with the spidev included in the /dev/ tree.
 

sanandak

New member
Thanks a lot! That works.

Next question (sorry to keep pinging you but that's what you get for replying!! :))

- I looked at the SPI signals (on SSP3 - P2_24, P2_25, and P2_27 for the clock, mosi and cs) and I can change the clock speed to a higher speed (I tested
up to 12MHz). However, the time between bytes is constant at 0.3ms. I think that is because this is a userspace device where each byte is clocked out
individually. Any chance of being able to send out/receive a buffer of bytes without that delay? With the delay, the effective throughput is only 300 bytes/s...

Thanks!
Sridhar




For anybody else following this, you need to edit the file $CFAROOT/configs/crystalfontz_cfa10036_defconfig
where CFAROOT=<your cfa_10036_buildroot directory>

and change the following:
BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION="03f8247fb"

then run
> cd $CFAROOT
> make crystalfontz_cfa10036_defconfig
> make linux-menuconfig
> make
> sudo python board/crystalfontz/cfa-10036/mk_cfa_sd.py -e output/images/barebox-env -b output/images/cfa10036_barebox_ivt.sb -r output/images/rootfs.tar /dev/mmcblk0

to write the new linux kernel and file system to sd card. (check your system for the correct raw sd card device)



After some struggling (my development machine is getting persnickety today) I committed what I believe to be the kernel branch that was used for these demonstrations.

If you change the kernel git version to 03f8247fb and remove from the build cfa-10055, it should go well, and build with the spidev included in the /dev/ tree.
 

CF Support

Administrator
It sounds like your writes are being buffered. Because it's userspace, your mileage may vary, but try flushing the buffers after every write and see if the performance improves for you. If you like, you can attach your code that does the work and we can take a look and (maybe) give you some ideas on how to improve it.
 

sanandak

New member
I'm using the example spi.c program from cfa-10036-documentation (from github)
examples/spi/spi.c,
which uses the spi_write_chunk function call from the cfa API...

Sincereley,
Sridhar

It sounds like your writes are being buffered. Because it's userspace, your mileage may vary, but try flushing the buffers after every write and see if the performance improves for you. If you like, you can attach your code that does the work and we can take a look and (maybe) give you some ideas on how to improve it.
 

CF Support

Administrator
Ahh, the intern's code. :)

I'm going to assume that you haven't touched:

SPIDEV *s = spi_init(1, 8, 125000);

The third parameter, per the include, is the speed. I can't test it right now, but have you mucked with that third argument?
 

sanandak

New member
Now it make's sense - that code is... interesting! :)

Yes, I did change that up to 1.25M and then 12.5.. and the clock changes speed nicely - it is the space between bytes that stays the same.

Thanks,
S

Ahh, the intern's code. :)

I'm going to assume that you haven't touched:

SPIDEV *s = spi_init(1, 8, 125000);

The third parameter, per the include, is the speed. I can't test it right now, but have you mucked with that third argument?
 

sanandak

New member
I compiled the "standard" linux spidev_test program that uses SPI_IOC_MESSAGE ioctl() call to write a buffer of data...
However, that program runs (without error)

...but also without any activity or output on the spi lines, alas.

Looking at the new dts file, I see that the spi uses spi-gpio (bitbanging). Pointers on how to use a hardware spi?

This board does *almost* everything I need - just need faster SPI!

Thanks!
S

Now it make's sense - that code is... interesting! :)

Yes, I did change that up to 1.25M and then 12.5.. and the clock changes speed nicely - it is the space between bytes that stays the same.

Thanks,
S
 

sanandak

New member
status of spi on cfa10036/37

After spending some time with this:
- the kernel version 03f8247fb puts spi3 on /dev/spidev32766.1
- that driver works in half-duplex mode (using write() and possibly read() but not tested - it wasn't clear from the DTS file which is the MISO line)
- in that mode it works up to 15MHz (my logic analyzer had trouble past that, but I think it works up to 30MHz)
- in that mode there is a short gap between bytes but nothing remarkable, which is great news.
- the /CS line (chip select) does NOT toggle

The ioctl() call SPI_IOC_MESSAGE does not work - this is the only way to do full duplex.

So a few steps forward, but not fully there.

Because I need 2 SPI channels, I would like to be able to use both spi2 and spi3 - or preferably, only spi2 (which has multiple chip-select lines).

Any help appreciated - the interplay between the DTS files and the kernel drivers is still mysterious to me - I'm working on it but would appreciate pointers.

Finally - in addition to the SPI I want to have UART serial TX/RX - anybody done that already (other than the console)

Thanks!
S
 
Top