Waveshare 2.8 A (or 3.2 B) TFT LCD with Orange Pi Zero LTS

Recommended Posts

I don't want to talk about how long i beat my head against this but i have it working so i thought i would share. 


First, in the 5.4.y kernels, the fbtft_device module seems to be missing? So i am using 5.90 oragepizero ubuntu bionic next 4.19.57 as my image, kernel is upgraded to 4.19.62-sunxi via regular apt-get upgrade.


I have a genuine waveshare 2.8 A rpi lcd. Waveshare states repeatedly that it is compatible with the 3.2 B rpi lcd except for the screen size and number of buttons, so this should work for the 3.2 B lcd as well. 


This blog post was pretty helpful: https://kaspars.net/blog/spi-display-orange-pi-zero


But it leaves out the necessity of enabling the spi bus overlays. 


So, using armbian-config, go into system -> hardware -> and enable spi-spidev and (I think?) spi-add-cs1 (as recommended by some other posts i have seen). 


Then edit (as root) /boot/armbianEnv.txt and add these lines: 




edit /etc/modules-load.d/modules.conf and add these lines: 




create /etc/modprobe.d/fbtft.conf containing this line: 


options fbtft_device rotate=90 name=waveshare32b busnum=1 gpios=dc:3,reset:0 speed=32000000


Here's the kicker though. According to the wiki page for this lcd, the lcd cable select is connected to pin 24 and the touchscreen cs pin is on pin 26




But i only had a white screen until i removed the "CS=1" argument from the options line. 


I don't' get it. Maybe this means i can't use the touch screen, but I'm not sure i want it for my application. 


But if someone can explain what the logic is there, that would be great. 


My plan is to ultimately install retropie on it, and remix the "mini commodore pet" retropie enclosure to fit an opi zero instead of a raspberry pi. I've looked at retrorangepi and they don't really target this kind of configuration so that seems like the way to go. 

Share this post

Link to post
Share on other sites
1 minute ago, ej0rge said:

I don't want to talk about how long i beat my head against this but i have it working so i thought i would share. 


Beating your head is half the fun.   Glad you got it working and thank you for sharing your notes.

Share this post

Link to post
Share on other sites

Looking through the git logs i found this commit: 




Commit c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface") removed the gpio code from fbtft_device rendering it useless.


fbtft_device is a module that was used on the Raspberry Pi to dynamically add fbtft devices when the Pi didn't have Device Tree support. Just remove the module since it's the responsibility of Device Tree, ACPI or platform code to add devices.


Which explains why the 5.4.y kernels don't include fbtft_device, and clarifies that the only way to use one of these devices in the 5.4.y kernel is with a dtoverlay. 


The reference for that would seem to be here: 




Naturally, the rpi overlays will have to be, uh, adjusted, to use them on any platform that is not an rpi.  I can't claim to have a deep understanding of how the device trees work, i'm just pretty sure that something that specifies a broadcom platform aint gonna work on an allwinner, rockchip, etc. 


If i feel a need for masochism i might look into it again. Maybe get some more usd cards so i can keep my working 4.19.y setup static. 

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.