JORGETECH

Any hopes for mainlining with Armbian/Linux? Now it could be accepted since it's a cleaner DT overlay.

After some tinkering I disabled the "spi-add-cs1" and "spi-spidev" overlays since they were conflicting with the touchscreen overlay. That still did not fix the problem unfortunately. Here are the relevant outputs of dmesg: dmesg | grep tft [ 8.850107] fbtft: module is from the staging directory, the quality is unknown, you have been warned. dmesg | grep spi [ 8.739055] ads7846: probe of spi1.1 failed with error -22 [ 8.759803] [drm] Initialized ili9486 1.0.0 20200118 for spi1.0 on minor 2 [ 8.762151] ili9486 spi1.0: [drm] fb1: ili9486drmfb frame buffer device So the touchscreen could have an initialization error, but I'm not too worried about that right now. The odd thing is that the DRM subsystem seems to correctly identify the TFT framebuffer device, but when I try to use it with apps like "fbi" and "con2fbmap" I still get a white screen.

I'm using an Orange Pi PC, I added the init stanza for my screen and change the "PA1 PA0 PA3" pins to "PA1 PA2 PC7" since those are the "TP_IRQ", "RST" and "LCD_RS" pins on my screen. I'm still getting a white screen but there is now an additional framebuffer device "/dev/fb1" which I don't remember being there before, so I'm getting somewhere.

Ok, I fixed the compilation problem by adding "/plugin/;" under "/dts-v1/;". But the screen is still white, maybe my screen has different pinout?

Hi, I was trying to adapt a similar DT overlay for a waveshare 3.5 TFT touchscreen clone, but when I try to add the overlay it gives me the next errors: Compiling the overlay tft35a-overlay.dts:6.13-20.4: ERROR (phandle_references): /fragment@0: Reference to non-existent node or label "spi1" tft35a-overlay.dts:22.13-32.4: ERROR (phandle_references): /fragment@1: Reference to non-existent node or label "pio" tft35a-overlay.dts:34.13-68.4: ERROR (phandle_references): /fragment@2: Reference to non-existent node or label "spi1" tft35a-overlay.dts:41.21-55.6: ERROR (phandle_references): /fragment@2/__overlay__/tft35a@0: Reference to non-existent node or label "pio" tft35a-overlay.dts:41.21-55.6: ERROR (phandle_references): /fragment@2/__overlay__/tft35a@0: Reference to non-existent node or label "pio" tft35a-overlay.dts:57.27-66.6: ERROR (phandle_references): /fragment@2/__overlay__/tft35a-ts@1: Reference to non-existent node or label "pio" tft35a-overlay.dts:57.27-66.6: ERROR (phandle_references): /fragment@2/__overlay__/tft35a-ts@1: Reference to non-existent node or label "pio" ERROR: Input tree has errors, aborting (use -f to force output) Error compiling the overlay I'm not sure what is wrong in the dts file since the "sunxi-h3-h5.dtsi" in the kernel version I'm using (5.10-rc3) has those names defined. The dts file I'm trying to compile is attached to the post. tft35a-overlay.dts

If I'm reading this correctly the acceleration is only disabled for Ubuntu bionic and focal, so compiling a groovy image (20.10) should enable acceleration? I didn't remember Armbian still had no groovy available. What other values are available besides "none"? Reading the manpage for "modesetting" reveals that setting the "AccelMethod" to "glamor" should enable acceleration.

This is exactly the same fix I applied on my Orange Pi Lite 2 and I've been having an stable desktop, the panfrost driver needs more work though. I recommend adding the Oibaf PPA to the system (in case Ubuntu is being used) to get the latest Mesa version.

I forgot about that, thanks for the info!

It makes sense for it to be a clock driver issue, setting a fixed frequency for the GPU makes it more stable for me. There are also some weird problems with HDMI when VGA to HDMI adapters are used, I wonder if it's somehow related to this (I doubt it since it would most probably be an HDMI PHY or Display Engine problem).

The screen flickering may be related to this issue I had.

RCA video output is currently not supported in mainline kernel (for supported hardware features read the table in this page), there was an experimental implementation for H3 boards but it's very outdated and it no longer works. RCA video works on Android images because they use the "legacy" Allwinner kernel (may have security flaws and other issues).

Glad to see it fixed so fast!

Ubuntu changed the location of the mini.iso file for the minimal Ubuntu (Server?) installer in their file servers (since the 20.04 release), it's now located here: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/mini.iso The docs should be changed since it could be confusing for new users/developers.

Do you need special VAAPI or VDPAU packages for decoding/encoding or has that been upstreamed? Sunxi-linux wiki mentions libvdpau-cedrus but that package is not available on Armbian. I have yet to try video decoding but as far as I'm aware LibreELEC has cedrus fully working, does that use VDPAU?

I manually added this to the already existing patch (just under the display engine definition, be sure to modify the diff notation if you try it yourself): +&gpu { + mali-supply = <&reg_dcdcc>; + status = "okay"; +}; + With this little modification in place, I compiled the kernel and u-boot packages again. Now I have the relevant entries that Werner has and glxinfo reports panfrost is in use. I'll test more after adjusting the devfreq parameters. EDIT: If I'm not mistaken, LibreELEC already has a patch that does the same thing but the one in Armbian needs to be adjusted (until the code is mainlined, obviously).