ej0rge reacted to Werner in Pinebook Pro install instructions?
Should, yes, but doesn't. RK3399 has an internal fixed boot priority which is something like SPI - eMMC - microSD - NVMe. This cannot be altered.
Armbian works around this by installing a boot loader to eMMC which points back to microSD and if that fails continue to boot from whatever is available instead.
If there is a boot loader on the eMMC that does not do that you have a hard time. That is why pbp installed an internal switch to disconnect eMMC from power to allow microSD to boot.
ej0rge reacted to MODI21JIN in any clues for the creation of a dtoverlay for fbtft on 5.4.y?
ej0rge reacted to Wowbagger in any clues for the creation of a dtoverlay for fbtft on 5.4.y?
Best source of documentation IMHO is from the armbian source. These references should provide the needed description to make a usable device tree. They are mirrored here:
SPI Controller Generic Binding This binding is for display panels using an Ilitek ILI9341 controller in SPImode.
Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046SPI driven touch screen controllers.
The other tidbit of info is the structure of a gpio cell property. AFAIK the numeric values for <&pio 0 2 1> refers to pin group 0 = A, pin offset 2 (A2), and pull-up flag.
Also, it is required to configure and activate the device trees. Configuration, like param_spidev_spi_bus=0, is still a mystery to me. armbian-config doesn't automatically add these items to /boot/armbianEnv.txt so this can be a major source of frustration.
My example /boot/armbianEnv.txt:
verbosity=7 dtdebug=7 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun50i-h5 overlays=spi-spidev param_spidev_spi_bus=0 user_overlays=sun50i-h5-ili9341 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u rootdev=UUID=8d9edae5-2ab9-4c42-933e-ee4235da815f rootfstype=ext4 I created sun50i-h5-ili9341 using the referenced documentation as a guide.
ej0rge reacted to olehs in any clues for the creation of a dtoverlay for fbtft on 5.4.y?
Try this one https://gist.github.com/olehs/1cd3e5ddf45066380df68a70d6f8462a
You only need spi-add-cs1 overlay enabled
ej0rge reacted to XANi in any clues for the creation of a dtoverlay for fbtft on 5.4.y?
With small changes it also works with Orange Pi Plus 2e, pin names are the same and only thing that needs to be changed is find/replace spi1 to spi0
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.