TFT01-2.2S with notro's fbtft module

[notro]

I think DC pin could be shared between displays, since its value is read only when the corresponding CS is low. Do you think it would possible?

The LCD controller reads the DC pin for each byte that is sent to determine whether it's a register command or data.
If you look at section 8.1. Command List in the ILI9341 datasheet, you can see the function of D/CX. First a command with D/CX=0 is sent, then the parameters with D/CX=1.

[Xumpy]

Ok I'm going to write some very interesting stuff you could do with this driver of notro... I should actually write a blog about this but I'm to lazy...

After some days of intense searching trough pages and pages of information I've managed to do this so far:

Working remote is a must have. If you have some death moments on the job you could set your teat's into the device.
Creating a remote solution for framebuffer devices is unfortunately only possible with fastdroid in andriod.

So we're going to hack fastdriod. Download fastdriod-vnc: http://code.google.com/p/fastdroid-vnc/downloads/list

Before compiling the code.
- Make a symbolic link: ln -s /usr/lib/arm-linux-gnueabihf/libjpeg.a /usr/lib/libjpeg.a
- open the file fbvncserver.c

Change

Code: Select all

/* framebuffer */
#ifdef ANDROID
# define FB_DEVICE "/dev/graphics/fb0"
#else
# define FB_DEVICE "/dev/fb0"
#endif

to, you know it:

Code: Select all

/* framebuffer */
#define FB_DEVICE "/dev/fb1"

Now we also have to disable the touch screen. Search where the function "init_touch" is called and place it into comments.

Code: Select all

if (TOUCH_DEVICE[0]) {
                pr_info("Initializing touch device %s ...\n", TOUCH_DEVICE);
                //init_touch();
        }

Save and compile the project and execute
make

Start vnc with the command: ./fastdroid-vnc
VNC will automaticly start and you can connect with it with a simple vnc viewer. Tunnel port 5901 all you want so you can connect from anywhere you want.

Now to continue with RetroArch.

I've managed to get retroarch workin by manually building version 0.9.9 and making these changes in the file "0.9.9/RetroArch-0.9.9/gfx/sdl_gfx.c"

Add above all includes

Code: Select all

#include "SDL_getenv.h"

In the function sdl_gfx_init before SDL_InitSubSystem(SDL_INIT_VIDEO); add

Code: Select all

   putenv("SDL_FBDEV=/dev/fb1");
   putenv("SDL_VIDEODRIVER=fbcon");

   SDL_Init(SDL_INIT_VIDEO);

"Make" and "sudo make install" and adjust the /etc/retroarch.conf file to your needs. (screen width, height, fullscreen, ...)

Unfortunately this does not work with the trunk of RetroArch. Don't know why but it does work with version 0.0.9.

When you start a game like "sudo retroarch -L /home/pi/RetroPie/emulatorcores/fceu-next/fceumm-code/fceumm_libretro.so castle.nes" <= Woot CastleVania

You will see in your vnc that it's booting. (and hopefully also on your screen)

Now I've noticed that it's very, verrry slow. Is this a problem with the framebuffer device or does this have something to do with RetroArch. I can't imagine RetroArch being this slow on a raspberry pi.

If it's RetroArch then I'm off topic. Any help is appreciated but I think I need to ask my question again in a RetroArch forum.

Anyhow, any help is greatly appreciated

Regards

Xump

[Xumpy]

Lol, If you edit the /etc/retroarch file and adjust the line

Code: Select all

# video_smooth = true

to

Code: Select all

video_smooth = false

It works!!! Woot, I finally got some emulators running on my tiny screen.

[Keeze]

Hi notro,

Finaly got the time to build my Squeezeboxplayer. The display shows album-art, station, station art, artist and song. Sound is produced by a USB soundcard. Every time the screen updates the soundcard puts out a short crack. Is this a known issie and can I do something to prevent this behaviour?

Cheers,
Kees

[notro]

Finaly got the time to build my Squeezeboxplayer. The display shows album-art, station, station art, artist and song. Sound is produced by a USB soundcard. Every time the screen updates the soundcard puts out a short crack. Is this a known issie and can I do something to prevent this behaviour?

There is one issue about this, but I don't know if it has been solved: https://github.com/notro/rpi-firmware/issues/2
Do you use the rpi-update kernel? This is based on rpi-3.6.y, which is now stale.
You can try 3.10 in my next branch: sudo REPO_URI=https://github.com/notro/rpi-firmware BRANCH=next rpi-update
The next master branch release will be 3.10.
How do you know that the screen update is the problem?

[Keeze]

There is one issue about this, but I don't know if it has been solved: https://github.com/notro/rpi-firmware/issues/2
Do you use the rpi-update kernel? This is based on rpi-3.6.y, which is now stale.
You can try 3.10 in my next branch: sudo REPO_URI=https://github.com/notro/rpi-firmware BRANCH=next rpi-update
The next master branch release will be 3.10.
How do you know that the screen update is the problem?

I tried several programs (python an C) and the moment I write to the screen I get the crack. I even got a C-program that writes more to the screen, which results in a longer crack. I use the 2013-05-25-wheezy-raspbian-2013-07-07-fbtft - kernel.

Backing up my SD-card an about to try the Next upgrade.

let you know if it solves the problem.

Cheers!

Edit

Loading fbtft using dma works, no more weird noises! The only problem is that when I reboot fbtft is loaded without using dma. How can I make that fbtft is always loaded, using dma?

Edit 2

Output of modinfo fbtft directly after boot:

Code: Select all

[email protected] /lib $ modinfo fbtft
filename:       /lib/modules/3.10.19+/kernel/drivers/video/fbtft/fbtft.ko
license:        GPL
srcversion:     7A9D361BFE2AE096B1FD2FC
depends:        fb_sys_fops,syscopyarea,sysfillrect,sysimgblt
intree:         Y
vermagic:       3.10.19+ preempt mod_unload modversions ARMv6
parm:           debug:override device debug level (ulong)
parm:           dma:Use DMA buffer (bool)

Loading the driver itself with:

Code: Select all

fbtft_device name=tm022hdh26 gpios=reset:23,led:24,dc:25 rotate=270

Does not load using DMA

Code: Select all

[  659.193428] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi0.0 at 32 MHz

When I then unload al the drivers (including fbtft) and load again

Code: Select all

modprobe fbtft dma
fbtft_device name=tm022hdh26 gpios=reset:23,led:24,dc:25 rotate=270

dmesg tells me it is using dma.

Code: Select all

[ 1257.686574] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB DMA buffer memory, fps=20, spi0.0 at 32 MHz

Weird?

[notro]

> How can I make that fbtft is always loaded, using dma?

fbtft_device depends on fbtft, so fbtft is automatically loaded when fbtft_device is loaded.

Loading fbtft specifically in /etc/modules with the dma option is one solution

Code: Select all

fbtft dma
fbtft_device name=....

Another solution is to use the modprobe conf files: http://linux.die.net/man/5/modprobe.conf

[Keeze]

First solution works like a charm!
Thanks for your support!

Cheers
Kees

[indyone]

Hi all,

I have bought the same lcd and i'm trying to making work with my raspberry (model a).
I'm using the Notro's 2013-05-25-wheezy-raspbian-2013-07-07-fbtft.zip image and followed the Xumpy's wiring instructions in the 1st post (with the correct CS pin) and i got the exact same result (that white flickering screen on startx)

So i rpi-update with notro's repo, rebooted and run:

Code: Select all

sudo modprobe fbtft_device custom name=fb_ili9341 speed=32000000 buswidth=8  gpios=reset:23,led:24,dc:25

dmesg shows:

Code: Select all

[   84.750835] fbtft_device:  SPI devices registered:
[   84.750871] fbtft_device:      spidev spi0.0 500kHz 8 bits mode=0x00
[   84.750885] fbtft_device:      spidev spi0.1 500kHz 8 bits mode=0x00
[   84.750893] fbtft_device:  'fb' Platform devices registered:
[   84.750915] fbtft_device:      bcm2708_fb id=-1 pdata? no
[   84.750978] fbtft_device: Deleting spi0.0
[   84.753768] fbtft_device:  GPIOS used by 'fb_ili9341':
[   84.753812] fbtft_device:    'reset' = GPIO23
[   84.753823] fbtft_device:    'led' = GPIO24
[   84.753832] fbtft_device:    'dc' = GPIO25
[   84.753840] fbtft_device:  SPI devices registered:
[   84.753853] fbtft_device:      spidev spi0.1 500kHz 8 bits mode=0x00
[   84.753865] fbtft_device:      fb_ili9341 spi0.0 32000kHz 8 bits mode=0x00
[   85.099274] graphics fb1: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi0.0 at 32 MHz

but unfortunately when running FRAMEBUFFER=/dev/fb1 startx the lcd stays blank.

I also tried to compile the latest fbtft from git using the Notro's tutorial but i get the error as in issue #38 (https://github.com/notro/fbtft/issues/38) which is because i did a rpi-update i suppose. Well, i'm a bit confused on how to continue and make my lcd work.

Thanks

[Keeze]

Well, i'm a bit confused on how to continue and make my lcd work.

Hi indyone,

I couldn't get it to work with the custom name either.

Code: Select all

fbtft_device name=tm022hdh26 gpios=reset:23,led:24,dc:25

worked for me (same tft)...
Succes

[indyone]

Exactly what i tried and indeed worked. The "custom" doesn't seem to work... it does not initialize the lcd.
Working solutions are Xumpy's (http://www.raspberrypi.org/phpBB3/viewt ... 11#p406511) and the one you said Keeze. Anyway thanks and keep up the good work Notro

[poglazoff]

@notro: Is there a way to get in touch with you? Email?

If it can't be put in a forum post, you can PM me.

Hi notro!

I'm trying to make the same display (TFT01-2.2S) work but something goes wrong.
In fact, everything is ok at start, I load module and even can write something:

Code: Select all

echo "Hello" > /dev/tty1

works, and I see Hello on display.
But every time module "hangs" after about 10 minutes, always with the same reason:

Code: Select all

[  132.390000] fbtft_device:  SPI devices registered:
[  132.390000] fbtft_device:      spidev spi1.0 1000kHz 8 bits mode=0x00
[  132.400000] fbtft_device:      spidev spi1.1 1000kHz 8 bits mode=0x00
[  132.400000] fbtft_device:      spidev spi1.2 1000kHz 8 bits mode=0x00
[  132.410000] fbtft_device:      spi-sc16is7x2 spi1.3 1000kHz 8 bits mode=0x00
[  132.420000] fbtft_device:      spidev spi1.4 1000kHz 8 bits mode=0x00
[  132.420000] fbtft_device:      spidev spi1.5 1000kHz 8 bits mode=0x00
[  132.430000] fbtft_device:  'fb' Platform devices registered:
[  132.440000] spi spi1.6: gpio index 3, gpio_cs 91
[  132.500000] fbtft_device:  GPIOS used by 'fb_ili9341':
[  132.500000] fbtft_device:    'reset' = GPIO51
[  132.510000] fbtft_device:    'dc' = GPIO53
[  132.510000] fbtft_device:  SPI devices registered:
[  132.510000] fbtft_device:      spidev spi1.0 1000kHz 8 bits mode=0x00
[  132.520000] fbtft_device:      spidev spi1.1 1000kHz 8 bits mode=0x00
[  132.530000] fbtft_device:      spidev spi1.2 1000kHz 8 bits mode=0x00
[  132.530000] fbtft_device:      spi-sc16is7x2 spi1.3 1000kHz 8 bits mode=0x00
[  132.540000] fbtft_device:      spidev spi1.4 1000kHz 8 bits mode=0x00
[  132.550000] fbtft_device:      spidev spi1.5 1000kHz 8 bits mode=0x00
[  132.560000] fbtft_device:      fb_ili9341 spi1.6 20000kHz 8 bits mode=0x00
[  133.100000] Console: switching to colour frame buffer device 30x20
[  133.110000] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi1.6 at 20 MHz
[  602.080000] 
[  602.080000] ======================================================
[  602.080000] [ INFO: possible circular locking dependency detected ]
[  602.080000] 3.12.0-rc3-imxv5-x0.3 #3 Not tainted
[  602.080000] -------------------------------------------------------
[  602.080000] kworker/0:1/15 is trying to acquire lock:
[  602.080000]  (&fb_info->lock){+.+.+.}, at: [<c033febc>] lock_fb_info+0x18/0x3c
[  602.080000] 
[  602.080000] but task is already holding lock:
[  602.080000]  (console_lock){+.+.+.}, at: [<c0372770>] console_callback+0xc/0x12c
[  602.080000] 
[  602.080000] which lock already depends on the new lock.
[  602.080000] 
[  602.080000] 
[  602.080000] the existing dependency chain (in reverse order) is:
[  602.080000] 
[  602.080000] -> #1 (console_lock){+.+.+.}:
[  602.080000]        [<c0062bd0>] lock_acquire+0x9c/0x104
[  602.080000]        [<c004c834>] console_lock+0x4c/0x60
[  602.080000]        [<c034156c>] register_framebuffer+0x178/0x264
[  602.080000]        [<bf017a28>] fbtft_register_framebuffer+0x1b8/0x2e4 [fbtft]
[  602.080000]        [<bf0193ac>] fbtft_probe_common+0x144/0x2d4 [fbtft]
[  602.080000]        [<c03ccc38>] spi_drv_probe+0x18/0x1c
[  602.080000]        [<c0382180>] driver_probe_device+0x104/0x220
[  602.080000]        [<c0382330>] __driver_attach+0x94/0x98
[  602.080000]        [<c0380768>] bus_for_each_dev+0x58/0x88
[  602.080000]        [<c0381854>] bus_add_driver+0xd8/0x26c
[  602.080000]        [<c0382954>] driver_register+0x78/0xf4
[  602.080000]        [<bf03300c>] 0xbf03300c
[  602.080000]        [<c00088ac>] do_one_initcall+0xe8/0x154
[  602.080000]        [<c006cb14>] load_module+0x1a20/0x1f24
[  602.080000]        [<c006d0f0>] SyS_init_module+0xd8/0xec
[  602.080000]        [<c000eee0>] ret_fast_syscall+0x0/0x44
[  602.080000] 
[  602.080000] -> #0 (&fb_info->lock){+.+.+.}:
[  602.080000]        [<c0062164>] __lock_acquire+0x1534/0x1a64
[  602.080000]        [<c0062bd0>] lock_acquire+0x9c/0x104
[  602.080000]        [<c0605204>] mutex_lock_nested+0x48/0x2d0
[  602.080000]        [<c033febc>] lock_fb_info+0x18/0x3c
[  602.080000]        [<c034a4c0>] fbcon_blank+0x240/0x27c
[  602.080000]        [<c036f99c>] do_blank_screen+0x1b4/0x270
[  602.080000]        [<c03727cc>] console_callback+0x68/0x12c
[  602.080000]        [<c0032f80>] process_one_work+0x1c0/0x4a4
[  602.080000]        [<c003363c>] worker_thread+0x13c/0x384
[  602.080000]        [<c003972c>] kthread+0xa4/0xb0
[  602.080000]        [<c000efa0>] ret_from_fork+0x14/0x34
[  602.080000] 
[  602.080000] other info that might help us debug this:
[  602.080000] 
[  602.080000]  Possible unsafe locking scenario:
[  602.080000] 
[  602.080000]        CPU0                    CPU1
[  602.080000]        ----                    ----
[  602.080000]   lock(console_lock);
[  602.080000]                                lock(&fb_info->lock);
[  602.080000]                                lock(console_lock);
[  602.080000]   lock(&fb_info->lock);
[  602.080000] 
[  602.080000]  *** DEADLOCK ***
[  602.080000] 
[  602.080000] 3 locks held by kworker/0:1/15:
[  602.080000]  #0:  (events){.+.+.+}, at: [<c0032ef4>] process_one_work+0x134/0x4a4
[  602.080000]  #1:  (console_work){+.+...}, at: [<c0032ef4>] process_one_work+0x134/0x4a4
[  602.080000]  #2:  (console_lock){+.+.+.}, at: [<c0372770>] console_callback+0xc/0x12c
[  602.080000] 
[  602.080000] stack backtrace:
[  602.080000] CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 3.12.0-rc3-imxv5-x0.3 #3
[  602.080000] Workqueue: events console_callback
[  602.080000] [<c00144c8>] (unwind_backtrace+0x0/0xf0) from [<c0011ce4>] (show_stack+0x10/0x14)
[  602.080000] [<c0011ce4>] (show_stack+0x10/0x14) from [<c05fc0ec>] (print_circular_bug+0x268/0x2bc)
[  602.080000] [<c05fc0ec>] (print_circular_bug+0x268/0x2bc) from [<c0062164>] (__lock_acquire+0x1534/0x1a64)
[  602.080000] [<c0062164>] (__lock_acquire+0x1534/0x1a64) from [<c0062bd0>] (lock_acquire+0x9c/0x104)
[  602.080000] [<c0062bd0>] (lock_acquire+0x9c/0x104) from [<c0605204>] (mutex_lock_nested+0x48/0x2d0)
[  602.080000] [<c0605204>] (mutex_lock_nested+0x48/0x2d0) from [<c033febc>] (lock_fb_info+0x18/0x3c)
[  602.080000] [<c033febc>] (lock_fb_info+0x18/0x3c) from [<c034a4c0>] (fbcon_blank+0x240/0x27c)
[  602.080000] [<c034a4c0>] (fbcon_blank+0x240/0x27c) from [<c036f99c>] (do_blank_screen+0x1b4/0x270)
[  602.080000] [<c036f99c>] (do_blank_screen+0x1b4/0x270) from [<c03727cc>] (console_callback+0x68/0x12c)
[  602.080000] [<c03727cc>] (console_callback+0x68/0x12c) from [<c0032f80>] (process_one_work+0x1c0/0x4a4)
[  602.080000] [<c0032f80>] (process_one_work+0x1c0/0x4a4) from [<c003363c>] (worker_thread+0x13c/0x384)
[  602.080000] [<c003363c>] (worker_thread+0x13c/0x384) from [<c003972c>] (kthread+0xa4/0xb0)
[  602.080000] [<c003972c>] (kthread+0xa4/0xb0) from [<c000efa0>] (ret_from_fork+0x14/0x34)
[email protected]:~# 
 

After this screen goes black and even modules reloading doesn't help, only reboot.
It looks like it doesn't depends on kind of LCD but mostly on interaction between fb and console drivers.
What is the reason and what can I do to make display work longer?

UPD: this bug not in fbtft. Anyway, notro helped me with to workaround this bug. His answer is here: https://github.com/notro/fbtft/issues/56

[Keeze]

Hi Notro,

What is the status of the firmware on your GITpage? Recently I installed the next-branch, but I see that your master branch is more recent? Which versions of the kernel is in the master branch and does it support fbtft loading with DMA support....

Next is the growing and growing images on raspberrypi.org. Even the Wheezy image contains to much rubbish and is over 700MB right now and NOOBS is way to much. Although I can upgrade both with your kernel, I like to know if there is a slim image which Ícan use? (like the Hexxeh image, which is just over 200MB). Do you have any advise? I don't mind installing things manualy. I don't even need X...

Cheers,
Kees

[notro]

What is the status of the firmware on your GITpage? Recently I installed the next-branch, but I see that your master branch is more recent? Which versions of the kernel is in the master branch and does it support fbtft loading with DMA support....

notro/[email protected]{master,next} uses the same kernel source branches as raspberrypi/[email protected]{master,next}.
master is now rpi-3.10.y and next is rpi-3.12.y. I don't know what the minor revision is in the latest release.
I only update the firmware when there is changes to fbtft or important fixes to the kernel source.
In theory, master and next should be updated at the same time, but I see that next was forgotten this time.
Both have dma support, but I can't remember trying it on 3.12.

Next is the growing and growing images on raspberrypi.org. Even the Wheezy image contains to much rubbish and is over 700MB right now and NOOBS is way to much. Although I can upgrade both with your kernel, I like to know if there is a slim image which Ícan use? (like the Hexxeh image, which is just over 200MB). Do you have any advise? I don't mind installing things manualy. I don't even need X...

Sorry, I haven't looked into that. I only use Raspian myself.

[desmondttm123]

hi guys, does anyone have a connection diagram for the tft?

my tft's pinout is

SD0<MISO>
LED
SDI<MOSI>
D/C
RESET
CD
GND
VCC

in the example given, it didn't match up with https://github.com/notro/fbtft/wiki#wik ... sing-fbtft... does anyone have a working example? thanks!

[wouterel]

hi guys, does anyone have a connection diagram for the tft?

my tft's pinout is

SD0<MISO>
LED
SDI<MOSI>
D/C
RESET
CD
GND
VCC

in the example given, it didn't match up with https://github.com/notro/fbtft/wiki#wik ... sing-fbtft... does anyone have a working example? thanks!

Since you seem to have a different device than the one this thread is about, perhaps it would be better to start a new thread. And then, to get useful answers, you'll need to give us more info than just the names of the pins. A link to what you bought? A datasheet? Especially since the pin names you mentioned seem to lack either a clock or a CS/CE which confuses me.

[desmondttm123]

sorry , it was a typo... it is CS not CD.....everything is pretty much similar...just the d/c bit that i am unsure

[wouterel]

sorry , it was a typo... it is CS not CD.....everything is pretty much similar...just the d/c bit that i am unsure

Still there does not seem to be a pin for the SPI clock, which is usually labeled CLK, SCLK or SCK. To me, that sounds like a problem. The D/C can be connected to a GPIO pin (most examples use GPIO24). The driver will know what to do with it .
Some examples can be found here: https://github.com/notro/fbtft/wiki/LCD-Modules

[desmondttm123]

hi, i figured out that my display is similar to the adafruit one, the adarfuit old 2.2" tft.

https://github.com/notro/fbtft/wiki/LCD ... dafruit-22

when i ran
sudo modprobe fbtft_device name=adafruit22
FRAMEBUFFER=/dev/fb1 startx

the screen went white and my pc's screen went black. however no display is seen on the tft...does anyone have a solution to this? thanks!

[desmondttm123]

Woot I did it!!! I added following code to the fbtft_device.c

CODE: SELECT ALL
{
.name = "TFT01_22S",
.spi = &(struct spi_board_info) {
.modalias = "fb_ili9341",
.max_speed_hz = 32000000,
.mode = SPI_MODE_0,
.platform_data = &(struct fbtft_platform_data) {
.display = {
.buswidth = 8,
.backlight = 1,
},
.bgr = true,
.gpios = (const struct fbtft_gpio []) {
{ "reset", 23 },
{ "led", 24 },
{ "dc", 25 },
{},
},
}
}
},


Now when I load this driver with "modprobe fbtft_device name=TFT01_22S" the screen stayed black but my log said that the driver was loaded correctly.

When I started x "FRAMEBUFFER=/dev/fb1 startx" I immediately got myself an image.

Thnx for this great driver notro. Your the man.

Regards

Xump

hi, how do i access the .c file? also when i try and run FRAMEBUFFER=/dev/fb1 starts, there was just flickering images. the output on ssh terminal is

Current version of pixman: 0.29.3
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Sat Mar 1 02:58:30 2014
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
FATAL: Module g2d_23 not found

Also,what drivers are being used? and how do i check for them ? thanks in advance!!

[notro]

If you provided a link to a product page, it would be much easier to help you out.
Do you know which LCD controller the display uses?

[desmondttm123]

hi sorry, the link is
http://www.ebay.co.uk/itm/321279978467? ... 1439.l2649

i used the adarfuit wiring btw

cheers!!

[notro]

It seem to be very similar to this: https://github.com/notro/fbtft/wiki/Mor ... tft01-22sp
The blog post has a wiring table. The pin names differs a bit: BL for LED, RS for RESET, VIN for VCC.

The product page you linked to is a bit confusing, as the title says ILI9340C, but the description says ILI9341. If one doesn't work, try the other.

[wouterel]

hi sorry, the link is
http://www.ebay.co.uk/itm/321279978467? ... 1439.l2649

i used the adarfuit wiring btw

cheers!!

Heh... that looks EXACTLY like mine. The driver options I use to get mine to work are (note buswidth and bgr!):
sudo modprobe fbtft_device custom name=fb_ili9341 speed=32000000 buswidth=8 gpios=reset:23,led:24,dc:25 rotate=270 bgr=1

(obviously the rotate depends on how you like your display to be oriented)
with the following connections:
P1-19 = MOSI, connect to MOSI on tft
P1-21 = MISO, connect to MISO on tft
P1-23 = SCLK, connect to SCK on tft
P1-24 = CE0, connect to CS on tft
P1-22 = GPIO25, connect to D/C on tft
P1-16 = GPIO23, connect to RESET on tft
P1-17 = 3.3V, connect to VCC on tft
P1-25 = GND, connect to GND on tft
P1-18 = GPIO24, not used by me at the moment since I didn't want to drive the backlight from the 3.3V rail. instead I just connect the LED pin on the tft via a 100 OHM resistor to one of the 5V pins.

good luck ,
Wouter

[desmondttm123]

Hi!!! Awesome!!!! What so are you using???

Cheers