ej0rge

What the heck are you talking about? HDMI And DVI are both TMDS, the difference is that HDMI supports both RGB and YUV colorspaces and DVI supports only RGB. I am pretty sure the default on computers is RGB anyway. YUV would be for video players. Are you trying to say that the display supports only YUV signals?

Minor quibble -- You can get the gpio displays to work, but you need a dtoverlay and you will probably have to write it yourself - at a minimum you'll have to edit an existing one unless there is already one available for your exact configuration.

Interestingly, throwing that switch didn't allow me to boot from my sd card. I don't remember at this point what image was on the SD at the time.

I have the microsd emmc adapter, so i used that and another computer to write a manjaro image to the emmc.

When i first tried out my orange pi prime in october 2020 i thought i recalled that the wifi worked. With a current armbian image, the wifi can't authenticate. I tried several of the available kernel images. I'm sure that the wpa2 password is correct because I control the router and other devices connect all the time. If i plug in an ath9x usb wifi dongle, that is able to connect, so it would appear to be an issue with the onboard rtl8723bs driver.

Anybody?

I know for sure that booting from an sd card and then using dd to write the uncompressed image to the emmc device isn't what works. I'm talking about Armbian_22.02.1_Pinebook-pro_focal_current_5.15.25_xfce_desktop.img here. Because that essentially bricked my PBP. I have the little adapter to connect the emmc to a usd slot, and using balena etcher to write to that isn't it either. the uboot in that image prevents booting from sd automatically as well, and i didn't find any uboot documentation that made it clear how to manually boot from sd, though i did hook up a serial console. This is what it said. The LED never turned green, the display flashes once but displays no images or text.

That screen probably connects the touch panel through GPIO which is not near as big of a deal as getting the whole screen working through the gpio header. If you don't want the touch function, you can ignore it. It looks like the only way to push video to that screen is hdmi. Which should be fine. As for whether the connectors will line up? The Rock64 has the same footprint as the raspberry pi 3 and the connectors appear to be in the same places? I'd rate it a solid "maybe". https://files.pine64.org/doc/rock64/rock64 board dimension.pdf https://www.mouser.com/new/dfrobot/dfrobot-raspberry-pi-3-bplus/

You can get the spi displays to work, but it's not going to be as easy as it is on a raspberry pi. There are a bunch of old howtos for waveshare screens on orange pi boards and if you use a 4.x.y kernel they will still work but you will have to figure out the gpio numbers for the exact board you are using. If you want to use a kernel later than 5.17 or something you have to build a dtoverlay, which is a bit on the arcane side.

When i first started using octoprint on an allwinner board, nanopi m1 in this case, I had a lot of usb connectivity issues with both my printer and a usb camera installed. I eventually found a post somewhere suggesting that the issue was with the "ondemand" cpufreq governor, and that switching the governor to "userspace" or "performance" should fix it, and it did fix it for me. This was on a 4.17 kernel i think. I don't know if the same issue is expected to exist in later kernels.

Clearly getting closer. But i gotta point out, there is more information to be seen on the serial console. usb-to-ttl-serial dongles are cheap and plentiful. Regretfully it has been several months since i worked on this sort of thing and my memory is foggy.

Do you have a serial console? that is the best way to see what is happening during bootup. At first glance i think some detail may be missing from your dts but right now i don't remember enough of my own troubleshooting process. I will look into it again a little later today though. Double check the pinout - you didn't mention what board you are on and not all h3 headers are alike. Also i notice that the raspberry pi overlays for the 3.5 screens, of which there are 3 versions, have an "init" stanza that you might need to copy/paste all or part of. https://github.com/swkim01/waveshare-dtoverlays

I am very confused. Did you run "sudo apt --add-architecture armhf" and not just "apt --add-architecture"? Also it's libc6 not livc6. try "sudo apt-get install libhybris:armhf" I don't have the specific experience with libhybris but i do have multiarch working on my H5

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 waveshare_32b_28a_opipc2.dts

my guess as well