ej0rge got a reaction from stut in any clues for the creation of a dtoverlay for fbtft on 5.4.y?
I have the waveshare 2.8 A tft and touch panel working on the Orange Pi PC2 with one long dtoverlay.
Some of my inspiration came from here:
Like i said one dtoverlay, both fbtft and the touch panel, no other overlays needed.
I admit i am a neophyte and it might be possible to trim this one slightly and use it in combination with the CS1 dtoverlay but it wasn't clear to me how that would work.
I am using a 6 inch hand-made cable to connect my waveshare 2.8 A but it is wired straight through on only the needed wires for touch and tft.
As I've said before it should work just the same with a 3.2 B.
May work on PC Prime as-is, should work on other orange pi boards with minor changes (compatible arch and the assignment of pin 26 varies from board to board).
For orange pi zero, zero plus (H3 and H5), maybe some others, instances of PA21 should be changed to PA10. Check your pinouts to be sure.
The spi speed of 1.6mhz for the tft is a safe example, I have run up to 4mhz without issues and might be able to go higher but i am leaving the safe default in place for this post.
one caveat: as i said i don't have a use for the touch panel in my application. I tested it by catting /dev/input/mouse1 and running a fingernail over the touch panel. I got output. yay. More tweaks might be needed, but the driver is fundamentally working and all the overrides are included in the dts
ej0rge got a reaction from stut in Is there a 32-bit version of armbian or that is compatible with widevine?
I don't have specific experience with widevine but debian-derived distributions including armbian are capable of hosting multiple ABIs.
Your s912 is aarm64 but is backward compatible with armhf. Your 32-bit arm binary is armhf. Similar to how an amd64 system is backward compatible with an i386 system.
You start with dpkg --add-architecture armhf
then apt-get update
Then you install 32-bit versions of everything you need for your 32-bit netflix, etc with "apt-get install foo:armhf" and so on.
I've only done this on a small scale, but if you get lucky and everything you need is in the distribution, it's pretty painless. the "ldd" command will tell you what libraries a dynamically linked binary needs to have around.
more info here: https://wiki.debian.org/Multiarch/HOWTO
ej0rge got a reaction from lanefu in Waveshare 2.8 A (or 3.2 B) TFT LCD with Orange Pi Zero LTS
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.